Я пытаюсь ограничить доступ на запись пользователям, имеющим userPassword атрибут. Но вот уже несколько часов подряд. Вот что я сделал до сих пор:
dc=exmaple,dc=org) и менеджер для изменения, добавления и удаления через Apache Directory Studio.people и groupou=people - uid=timo,ou=people,dc=example,dc=org и uid=heike,...Следующее, что я хочу сделать, это иметь возможность изменять собственный пароль пользователя. Для этого я создал changepw.ldif файл.
dn: uid=timo,ou=people,dc=example,dc=org
changetype: modify
replace: userPassword
userPassword: newpw
и применил это вот так
$ ldapmodify -x -D "uid=timo,ou=people,dc=example,dc=org" -W -f changepw.ldif
modifying entry "uid=timo,ou=people,dc=example,dc=org"
ldap_modify: Insufficient access (50)
Сначала я установил userPassword для uid = timo с помощью Apache Directory Studio и убедился, что он работает правильно.
На данный момент все работает как надо (по крайней мере, соответствует моим ожиданиям :-P). Итак, я добавил контроль доступа к /etc/openldap/slapd.conf следующим образом:
[...]
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
access to attrs=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=example,dc=org" write by * none
#######################################################################
# MDB database definitions
database mdb
[...]
и делал обычные вещи:
$ slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
$ chown -R ldap:ldap /etc/openldap/slapd.d
$ systemctl restart slapd
и попробовал еще раз.
$ ldapmodify -x -D "uid=timo,ou=people,dc=example,dc=org" -W -f changepw.ldif
modifying entry "uid=timo,ou=people,dc=example,dc=org"
ldap_modify: Insufficient access (50)
По какой-то причине доступ запрещен. Я включил ведение журнала acl и получил следующее:
5f12f36a => access_allowed: result not in cache (userPassword)
5f12f36a => access_allowed: auth access to "uid=timo,ou=people,dc=example,dc=org" "userPassword" requested
5f12f36a => slap_access_allowed: backend default auth access granted to "(anonymous)"
5f12f36a => access_allowed: auth access granted by read(=rscxd)
5f12f36a => access_allowed: backend default write access denied to "uid=timo,ou=people,dc=example,dc=org"
Буду очень признателен за любую помощь!
Я придумал решение после того, как узнал, что есть инструмент под названием slapacl для проверки ACL.
Позвольте мне показать вам, как это выглядело до каких-либо изменений.
$ slapacl -F /etc/openldap/slapd.d/ -b "uid=timo,ou=people,dc=example,dc=org" -D "uid=timo,ou=people,dc=example,dc=org" -u userPassword
authcDN: "uid=timo,ou=people,dc=example,dc=org"
userPassword: read(=rscxd)
Это в основном то, что я уже понял и дал мне достаточно доказательств, чтобы подвергнуть сомнению команду генерации конфигурации (slaptest -f ... -F ...).
Фактическая проблема заключалась в том, что каталог конфигурации (/etc/openldap/slapd.d) не было отменено
Вы должны сначала удалить этот каталог и снова создать каталог конфигурации.
$ rm -rf /etc/openldap/slapd.d/*
$ slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
$ chown -R ldap:ldap /etc/openldap/slapd.d
$ systemctl restart slapd
И именно так тест должен был выглядеть в первую очередь.
$ slapacl -F /etc/openldap/slapd.d/ -b "uid=timo,ou=people,dc=example,dc=org" -D "uid=timo,ou=people,dc=example,dc=org" -u userPassword
authcDN: "uid=timo,ou=people,dc=example,dc=org"
userPassword: write(=wrscxd)
Я надеюсь, что кому-то будут полезны мои выводы. Все еще любопытно, что об этом не упоминается на страницах руководства и что нет -f (принудительное переопределение) для этого.