настройка ACL для прокси в AD

[Денис]

Продолжение истории с проксированием AD через OpenLDAP,

Попытался теперь настроить ACL, чтобы в OpenLDAP попадала только одна OU, а все остальные объекты AD были не видны:

Код: [Выделить]

dn: olcDatabase={2}ldap,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to dn.children="OU=OTF-IS-Groups,OU=OTF,OU=BLAHBLAH,DC=corp,DC=blahblah,DC=com"
    filter="(&(objectClass=organizationalUnit)(!(objectClass=computer))(distinguishedName=OU=OTF-IS-Testit,OU=OTF-IS-Groups,OU=OTF,OU=BLAHBLAH,DC=corp,DC=blahblah,DC=com))"
    attrs=distinguishedName,ou
    by users read
    by * none
-
replace: olcAccess
olcAccess: {1}to * by * none


но после запроса

Код: [Выделить]

ldapsearch -H ldap://someldap.blahblah.com/ -x -D "cn=openldap,dc=corp,dc=blahblah,dc=com" -W "(objectClass=*)"

все равно вижу весь AD

это может быть из-за того, что я выполняю ldapserch от сервисного DN cn=openldap,dc=corp,dc=blahblah,dc=com - olcRootDN, RootPW которого прописаны в конфиге olcDatabase={2}ldap?
или я где-то в конфиге ACL ошибся?

[egor]

Как мне кажется, тут сразу несколько факторов.

Во-первых, да, на rootdn действие ACL не распространяется.

Во-вторых, директива replace при changetype: modify заменяет все значения атрибута, так что у вас в итоге должен остаться последний olcAccess  (проверьте в итоговой конфигурации). Тут, скорее всего, подойдёт replace + add.

В-третьих, в man-странице slapd-ldap в разделе "Контроль доступа" честно написано, что контроль доступа у данного backend фиктивный, и нормальный контроль доступа нужно настраивать в целевом каталоге, в Вашем случае, в AD.

Егор

[Денис]

Во-первых, да, на rootdn действие ACL не распространяется.

Понял, спасибо.
Тогда еще несколько вопросов - вот получается у меня теперь 2 базы в OpenLDAP - {1}mdb - созданная при установке OpenLDAP, и {2}ldap, созданная при настройке back_ldap.
В какой из них создать пользователей, которые могут видеть только то, что акузапо в ACL базы {2}ldap?
С одной стороны - логично выглядит - что их надо создавать в базе {2}ldap, но не будут ли эти пользователи пересекаться с пользователями AD?
А могут ли пользователи AD ходить в OpenLDAP со своими учетками? Попробовал - не выходит. Это может быть из-за того, что я запускаю ldapsearch к OpenLDAP с учеткой AD но с simple binding, а в AD - digest-md5? 

Во-вторых, директива replace при changetype: modify заменяет все значения атрибута, так что у вас в итоге должен остаться последний olcAccess  (проверьте в итоговой конфигурации). Тут, скорее всего, подойдёт replace + add.

Вроде все отработало - в итоговой конфигурации обе записи присутствуют. Там если указывать именно olcAccess: {NN} - оно заменяет именно тот атрибут, который нужно

В-третьих, в man-странице slapd-ldap в разделе "Контроль доступа" честно написано, что контроль доступа у данного backend фиктивный, и нормальный контроль доступа нужно настраивать в целевом каталоге, в Вашем случае, в AD.

Это понятно, читал, спасибо. Мне в общем и не нужно, чтобы OpenLDAP решал несвойственные ему задачи. Нужно только чтобы keycloak, некоторые интерфейсы которого торчат в инет, видел не весь AD а его часть, необходимую для работы приложения. Соответственно, в качестве сервера LDAP (провайдера аутентификации и ролей/групп пользователей) для keycloak будет выступать не весь AD, а только его часть, которая экспозится OpenLDAPом через ACL. Но с AD/LDAP я лет 15 не работал, поэтому вот прорываюсь с боем

[egor]

Здравствуйте!

Давайте начнём с самого актуального: Ваше приложение (keycloak) выполняет свои функции с Вашими нынешними настройками OpenLDAP, если не принимать в расчёт ACL? Как я понял после беглого поиска, keycloak предназначено нужно для аутентификации/авторизации пользователей, эта функция работает? Если нет, может и не стоит мучиться с ограничением доступа.

Если Вас интересуют только учётки из определённой ветки AD, то можно указать её в качестве suffix в настройках olcDatabase: ldap:

Код: [Выделить]

olcSuffix: OU=OTF-IS-Testit,OU=OTF-IS-Groups,OU=OTF,OU=BLAHBLAH,DC=corp,DC=blahblah,DC=com
Наконец, какие-то настройки фильтрации наверняка можно указать в самом приложении (keycloak). Никогда с ним не сталкивался, но по аналогии с другими LDAP-клиентами, практически всегда можно указать настройку типа filter. К тому же, раз там есть привязка к LDAP (LDAP-клиент), то можно привязать его напрямую к AD и настроить потоньше через параметры конфигурации LDAP-клиента.

P.S. Я сам уже много лет как отошёл от администрирования. Раньше под рукой всегда была куча инструментов и стендов, сейчас же мои советы больше похожи на гадание на кофейной гуще =) . Так что не судите строго.

Егор

[Денис]

Добрый день, Егор

Давайте начнём с самого актуального: Ваше приложение (keycloak) выполняет свои функции с Вашими нынешними настройками OpenLDAP, если не принимать в расчёт ACL? Как я понял после беглого поиска, keycloak предназначено нужно для аутентификации/авторизации пользователей, эта функция работает? Если нет, может и не стоит мучиться с ограничением доступа.

Simple аутентификация для Openldap точно работает

Если Вас интересуют только учётки из определённой ветки AD, то можно указать её в качестве suffix в настройках olcDatabase: ldap:

Код: [Выделить]

olcSuffix: OU=OTF-IS-Testit,OU=OTF-IS-Groups,OU=OTF,OU=BLAHBLAH,DC=corp,DC=blahblah,DC=com

Нужно именно несколько веток AD, кроме того надо не все атрибуты пользователя показывать, так что этот вариант скорее всего не подойдет

Наконец, какие-то настройки фильтрации наверняка можно указать в самом приложении (keycloak). Никогда с ним не сталкивался, но по аналогии с другими LDAP-клиентами, практически всегда можно указать настройку типа filter. К тому же, раз там есть привязка к LDAP (LDAP-клиент), то можно привязать его напрямую к AD и настроить потоньше через параметры конфигурации LDAP-клиента.

В том то и дело, что напрямую к AD - не хочется, т.к. некоторые интерфейсы keycloak торчат в инет, и если поломают keycloak - нарушителю становится доступна вся структура AD. А в случае с OpenLDAP - нарушителю придется поломать еще и OpenLDAP, чтобы добраться до AD.

P.S. Да я и не сужу Ваши советы реально помогают

[egor]

Simple аутентификация для Openldap точно работает

в keycloak пользователь с учёткой из AD может пройти аутентификацию с паролем из AD?

[Денис]

короче я дебил, все эти приседания с DIGEST-MD5 не нужны, аутентификация работает simple просто неправильно писал binddn

да, в keycloak может биндиться к OpenLDAP с учеткой из AD и в текущей конфигурации видит весь AD

но с фильтрацией пока не получается. ночью еще попробую поиграться