我们创建了一个主/从环境,其中一个 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 吗?
由于从属端的任何更改都被拒绝,我们如何完全停止复制模式?
答案1
您只需使用复制用户的凭据登录并确认userPassword
在查询其他用户对象时显示即可,从而简单地检查 ACL 是否正确。
例如一个简单的ldapsearch -D "cn=syncprov,dc=thedomain,dc=com" -w secret -p 389 -h server.example.com "cn=Heiner"
如果 ACL 正确,您应该能够看到用户密码。
修复 ACL 不会自动开始将丢失的 userPassword 属性复制到您的从属服务器。
(更改后的 ACL 不会修改原始用户帐户对象,尽管 cn=syncprov 现在可以看到主服务器上的一个额外属性(不是“新”属性),但该帐户保持不变。而且由于复制仅同步已更新的对象,因此什么也不会发生。)
这次你需要再次完全初始化从属设备和用户密码。