我必须在 Ubuntu 12.04 服务器上设置一个外部匿名可访问的 LDAP 目录，并且我想将身份验证和内部数据保存在不同的子树中。
LDAP 布局示例
dc=example.com,dc=com
organizationUnit: ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group1,ou=hie_ext,dc=example,dc=com
inetOrgPerson: cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com
inetOrgPerson: cn=user2,ou=group1,ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group2,ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group_auth,dc=example,dc=com
account: uid=group1,password=XXX,ou=group_auth,dc=example,dc=com
这个想法是，uid=group1 auth 将能够添加/编辑（基本上是“写入”）ou=hie_ext,ou=group1 下的条目。我尝试了这样的 ACL 规则：
access to dn.children="ou=hie_ext,dc=example,dc=com"
by set="this/ou & user/uid" write
by * none
但是，当我使用 slapacl 测试写权限时，如果我测试
"ou=group1,ou=hie_ext,dc=example,dc=com"
但当我测试时“被拒绝”
"cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com"
我觉得这有点奇怪。
我可能忽略了一些显而易见的东西（目前我对 LDAP 还不是很熟悉）。运行 slapacl 的“-d trace”选项并没有多大帮助，因为我不知道我在看什么。:)
更新：
因此，虽然“-d trace”有点太过冗长，对我来说没什么用，但我意识到“-d acl”可能会更有帮助。
所以如果我跑
slapacl -f slapd.conf -D"uid=group1,ou=servers,dc=example,dc=com" \
-b "cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com" "sn/write" -d acl
调试输出是这样的。
52d544e1 => access_allowed: write access to "cn=test,ou=group1,ou=hie_ext,dc=example,dc=com" "sn" requested
52d544e1 => dn: [1]
52d544e1 => dn: [2] ou=hie_ext,dc=example,dc=com
52d544e1 => acl_get: [2] matched
52d544e1 => acl_get: [2] attr sn
52d544e1 => acl_mask: access to entry "cn=test,ou=group1,ou=hie_ext,dc=example,dc=com", attr "sn" requested
52d544e1 => acl_mask: to all values by "uid=group1,ou=servers,dc=example,dc=com", (=0)
52d544e1 <= check a_set_pat: this/ou & user/uid
52d544e1 => bdb_entry_get: found entry: "uid=group1,ou=servers,dc=example,dc=com"
52d544e1 ACL set[0]=group1
52d544e1 ACL set: empty
52d544e1 <= check a_dn_pat: *
52d544e1 <= acl_mask: [2] applying read(=rscxd) (stop)
52d544e1 <= acl_mask: [2] mask: read(=rscxd)
52d544e1 => slap_access_allowed: write access denied by read(=rscxd)
52d544e1 => access_allowed: no more rules
write access to sn: DENIED
但删除特定于记录的 cn：
slapacl -f slapd.conf -D"uid=group1,ou=servers,dc=example,dc=com" \
-b "ou=group1,ou=hie_ext,dc=example,dc=com" "sn/write" -d 128
它有效吗？
52d545ef => access_allowed: write access to "ou=group1,ou=hie_ext,dc=example,dc=com" "sn" requested
52d545ef => dn: [1]
52d545ef => dn: [2] ou=hie_ext,dc=example,dc=com
52d545ef => acl_get: [2] matched
52d545ef => acl_get: [2] attr sn
52d545ef => acl_mask: access to entry "ou=group1,ou=hie_ext,dc=example,dc=com", attr "sn" requested
52d545ef => acl_mask: to all values by "uid=group1,ou=servers,dc=example,dc=com", (=0)
52d545ef <= check a_set_pat: this/ou & user/uid
52d545ef ACL set[0]=group1
52d545ef => bdb_entry_get: found entry: "uid=group1,ou=servers,dc=example,dc=com"
52d545ef ACL set[0]=group1
52d545ef ACL set[0]=group1
52d545ef <= acl_mask: [1] applying write(=wrscxd) (stop)
52d545ef <= acl_mask: [1] mask: write(=wrscxd)
52d545ef => slap_access_allowed: write access granted by write(=wrscxd)
52d545ef => access_allowed: write access granted by write(=wrscxd)
write access to sn: ALLOWED
我不确定为什么 ACL 解析器会在第一个和第二个示例之间获得一组不同的“this/ou”值，这似乎就是正在发生的事情。
答案1
看来我误解了 ACL 的工作原理。显然，您无法针对“继承”属性进行测试，而这正是我试图做的。DN 中的属性不是给定对象的一部分：对于新手 LDAPer 来说，这是一个宝贵的教训。
一旦我弄清楚我做错了什么，解决方案就非常简单了：
我在 inetorgperson 记录中添加了一个与授权对象 [0] 的 uid 匹配的“ou”元素。一切“神奇地”开始发挥作用。
by set="this/ou & user/uid" write
[0] 这并不是看上去的滥用模式，因为每个身份验证帐户都与特定单元绑定。保证！