Мы создали среду главный / подчиненный, в которой сервер ldap периодически реплицирует другой. Все записи реплицируются правильно, но атрибут userPass не реплицируется. Мы предположили, что это проблема ACL, поэтому на главной стороне мы добавили
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to attrs=userPassword by dn.base="cn=syncprov,dc=thedomain,dc=com" read
, но userPass все еще отсутствует.
Для отладки этого шага было бы полезно
Есть ли инструмент, который помогает мне проверять проблемы ACL? Чтобы я мог выдать себя за пользователя и проверить атрибут?
Какой уровень ведения журнала на стороне сервера будет отображать проблемы ACL?
Каждый раз, когда мы пытаемся изменить ldapmodify на подчиненной стороне, они отклоняются с «теневым контекстом», который является довольно логично, но как мы можем внести изменения? Должны ли мы исключить cn = config из репликации
Поскольку любые изменения на ведомой стороне отклоняются, как вообще остановить режим репликации?
Теперь вы можете просто проверить правильность ACL, войдя в систему с учетными данными для пользователя репликации и подтвердив, что userPassword
отображается, когда вы запрашиваете другие пользовательские объекты.
Например, с простым ldapsearch -D "cn = syncprov, dc = thedomain, dc = com" -w secret -p 389 -h server.example.com "cn = Heiner"
Если ACL правильный, вы должны увидеть userPassword.
Исправление ACL не приведет к автоматической репликации отсутствующих атрибутов userPassword на ваше ведомое устройство.
(Измененный ACL не изменяет исходный объект учетной записи пользователя, хотя cn = syncprov теперь может видеть дополнительный атрибут, который не является «новым» атрибутом, на главном сервере эта учетная запись остается неизменной. И поскольку репликация только синхронизирует объекты, которые были обновлены, ничего не происходит.)
Вам нужно будет снова полностью инициализировать ведомое устройство, на этот раз с помощью паролей пользователя.