Установите ACL в OpenLDAP, чтобы пользователь мог найти свою собственную запись в отфильтрованном поддереве
У меня есть каталог пользователей в openldap сервер под базовым DN ou = users, dc = mydomain . Записи пользователей: uid = user1, ou = users, dc = mydomain
Мои текущие ACL:
{5 } в * самостоятельно записать dn = "cn = admin, dc = mydomain" записать * none
{4} в dn.subtree = "ou = users, dc = mydomain" путем самостоятельного чтения
{3} на dn.exact = "dc = mydomain" attrs = запись по пользователям поиск по * none
{2} в dn.base = "" на * чтение
{1} в dn.subtree = "dc = something, dc = mydomain" от dn = "uid = something, ou = users, dc = mydomain" запись с помощью * чтения
{0} для attrs = userPassword, shadowLastChange путем самостоятельной записи с использованием анонимной аутентификации с помощью dn = "cn = admin, dc = mydomain" записи с помощью * none
Они позволяют пользователю запрашивать и находить свою собственную запись. Но если аутентифицированный пользователь user1 ищет базовое DN с установленным фильтром (uid = user1) , записей не найдено. Другими словами: ldapsearch -H ldap: // myserver -b "ou = users, dc = mydomain" -D "uid = user1, ou = users, dc = mydomain" -x -W ничего не возвращает while ldapsearch -H ldap: // myserver -b "uid = user1, ou = users, dc = mydomain" -D "uid = user1, ou = users, dc = mydomain" -x -W возвращает запись для user1 .
Как мне настроить ACL, чтобы пользователь мог найти свою собственную запись (и только свою) с помощью фильтрованного поиска по базовому DN?
Определение списков ACL OpenLDAP является сложной задачей.
В большинстве случаев проблемы ACL вызваны порядком обработки самих ACL и
их who-clauses (by ...) и что ACL неявно оканчиваются на by * none
остановка потока управления.
Вы используете динамическую конфигурацию с cn = config , и это использует Расширение X-ORDERED в схеме для сохранения порядка некоторых атрибутов. значения, такие как olcAccess .
Итак, порядок, в котором обрабатываются ваши ACL:
{0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=mydomain" write by * none
{1}to dn.subtree="dc=something,dc=mydomain" by dn="uid=someone,ou=users,dc=mydomain" write by * read
{2}to dn.base="" by * read
{3}to dn.exact="dc=mydomain" attrs=entry by users search by * none
{4}to dn.subtree="ou=users,dc=mydomain" by self read
{5}to * by self write by dn="cn=admin,dc=mydomain" write by * none
Итак, давайте подробно рассмотрим ваши ACL:
{0} to attrs = userPassword, shadowLastChange by self написать с анонимной авторизацией по dn = "cn = admin, dc = mydomain" написать по * none
Это правило, вероятно, взято из некоторой конфигурации по умолчанию. Можно начать с этого, но я бы посоветовал немного повторить факторинг:
- Пропустить атрибут shadowLastChange , поскольку тень LDAP нарушена. И если вы действительно используете карты теней, этот ACL позволит пользователю обойти срок действия теневого пароля.
- Измените порядок предложений who. В общем, следуйте правилу, чтобы сначала упомянуть «высшие» привилегии.
- Если cn = admin, dc = mydomain уже является rootdn этой базы данных, вам не нужно это предложение who.
- ] Лучше предоставить группе права администратора с паролем.
- Не предоставлять права чтения вообще путем включения
записидоступа, вместо этого используйте привилегию только для записи= w.
Лучше использовать:
{0} для attrs = userPassword by group = "cn = admins, ou = groups, dc = mydomain" = w by self = w by anonymous auth by * none
{1} для dn.subtree = "dc = something, dc = mydomain" от dn = "uid = something, ou = users, dc = mydomain" написать, * прочитав
Если dc = mydomain - суффикс вашей базы данных, этот ACL не имеет особого смысла.
мне в контексте вашего вопроса. Может быть, остатки каких-то тестов?
{2} к dn.base = "" * прочитано
Это не действует, если помещено в запись конфигурации вашей базы данных. Это должно быть добавлена в запись конфигурации внешнего интерфейса cn = config (ранее в статической конфигурации slapd.conf перед любым разделом базы данных ).
{3} в dn.exact = "dc = mydomain" attrs = запись, выполненная пользователями поиск по * нет
Я бы поместил такой ACL в конец списка ACL, чтобы он не останавливался. доступ к записи в этот момент. И если вы хотите использовать произвольный поиск такие базы, как ou = users, dc = mydomain , вам необходимо предоставить право на этот поиск на все поддерево.
Поместите это в конец списков управления доступом и удалите {3} или ...
{6} в dn.subtree = "dc = mydomain" attrs = запись по поиску пользователей автор: * none
... переместите это правило:
{4} в dn.subtree = "ou = users, dc = mydomain" путем самостоятельного чтения
Вероятно, должен быть последний ACL и заменить {3}. См. Комментарий для {5}.
{5} для * самостоятельной записи dn = "cn = admin, dc = mydomain" записи * none
Проблемы здесь:
-
при самостоятельной записиникогда не будет достигнут из-запри самостоятельном чтениив {4}. - Этот ACL не достигается вообще из-за неявного
by * noneв {4}. - снова: предоставление доступа к rootdn снова не требуется
- : лучше предоставить административный доступ группе
- используйте лучший порядок предложений
- пересмотрите, если вы действительно хотите предоставить доступ на запись ко всем атрибутам самому пользователю
Лучше:
{5} для * by group = "cn = admins, ou = группы, dc = mydomain "записать самостоятельно записать * никто
Один из наиболее важных вариантов отладки - запустить slapd с протоколированием обработки ACL:
/ usr / sbin / slapd… -d config, stats, stats2, acl
Итак, эти подсказки должны помочь вам начать работу над вашими ACL, решая ваши проблемы самостоятельно. Всегда думай дважды. Мне кажется, у вас есть немного противоречивых предположений в ваших правилах.
Но очевидно, что нет никакого способа обойтись без глубокого погружения в документацию:
Если вы хотите понять ACL в деталях, вам следует обратиться к различным он-лайн документация:
Этот ответ gace me решающий ключ. Единственное, что мне пришлось изменить, это предлагаемый поиск acl от верхнего dn (dc = mydomain) до пользователя dn (ou = users, dc = mydomain)
. Изменение ACL на это делает трюк:
{5} для * самостоятельной записи dn = "cn = admin, dc = mydomain" записи * none
{4} в dn.subtree = "ou = users, dc = mydomain" путем самостоятельного чтения
{3} в dn.exact = "ou = users, dc = mydomain" attrs = запись по пользователям поиск по * none
{2} в dn.base = "" на * чтение
{1} в dn.subtree = "dc = something, dc = mydomain" от dn = "uid = something, ou = users, dc = mydomain" запись с помощью * чтения
{0} для attrs = userPassword, shadowLastChange путем самостоятельной записи с использованием анонимной проверки подлинности с помощью dn = "cn = admin, dc = mydomain" записи с помощью * none