Форум проекта Pro-LDAP.ru
Администрирование OpenLDAP => Конфигурация через cn=config => Тема начата: Денис от 04 Июль 2023, 17:33:57
-
Продолжение истории с проксированием 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 ошибся?
-
Как мне кажется, тут сразу несколько факторов.
Во-первых, да, на rootdn действие ACL не распространяется.
Во-вторых, директива replace при changetype: modify заменяет все значения атрибута, так что у вас в итоге должен остаться последний olcAccess (проверьте в итоговой конфигурации). Тут, скорее всего, подойдёт replace + add.
В-третьих, в man-странице slapd-ldap (https://pro-ldap.ru/tr/man/slapd-ldap.5.html) в разделе "Контроль доступа" честно написано, что контроль доступа у данного 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 (https://pro-ldap.ru/tr/man/slapd-ldap.5.html) в разделе "Контроль доступа" честно написано, что контроль доступа у данного backend фиктивный, и нормальный контроль доступа нужно настраивать в целевом каталоге, в Вашем случае, в AD.
Это понятно, читал, спасибо. Мне в общем и не нужно, чтобы OpenLDAP решал несвойственные ему задачи. Нужно только чтобы keycloak, некоторые интерфейсы которого торчат в инет, видел не весь AD а его часть, необходимую для работы приложения. Соответственно, в качестве сервера LDAP (провайдера аутентификации и ролей/групп пользователей) для keycloak будет выступать не весь AD, а только его часть, которая экспозится OpenLDAPом через ACL. Но с AD/LDAP я лет 15 не работал, поэтому вот прорываюсь с боем :)
-
Здравствуйте!
Давайте начнём с самого актуального: Ваше приложение (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. Да я и не сужу :) Ваши советы реально помогают :)
-
Simple аутентификация для Openldap точно работает
в keycloak пользователь с учёткой из AD может пройти аутентификацию с паролем из AD?
-
короче я дебил, все эти приседания с DIGEST-MD5 не нужны, аутентификация работает simple :) просто неправильно писал binddn :)
да, в keycloak может биндиться к OpenLDAP с учеткой из AD и в текущей конфигурации видит весь AD
но с фильтрацией пока не получается. ночью еще попробую поиграться