Мы создали среду master / slave, в которой сервер 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 теперь может видеть дополнительный атрибут, который не является «новым» атрибутом, на главном сервере эта учетная запись остается неизменной. И поскольку репликация синхронизирует только объекты, которые имеют был обновлен ничего не происходит.)
Вам нужно будет снова полностью инициализировать ведомое устройство, на этот раз с участием userPasswords.