Я пытаюсь ограничить доступ для записи пользователям, имеющим атрибут userPassword
. Но уже несколько часов терпит неудачу. Вот что я сделал до сих пор:
dc = exmaple,dc = org
) и Менеджер для изменения, добавления и удаления с помощью Apache Directory Studio человека организационного подразделения
и группа
ou = 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
(принудительное переопределение).