我必须在Ubuntu 12.04服务器上设置一个外部匿名可访问的LDAP目录，并且我想要将authentication和内部数据保存在不同的子树中。
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
当我使用slapacltesting写权限的时候，如果我testing的话，我会得到“允许”
"ou=group1,ou=hie_ext,dc=example,dc=com"
但是当我testing时“拒绝”
"cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com"
这对我来说似乎有些</s> </s>。
我可能忽视了一些显而易见的事情（在这一点上，我对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
debugging输出是这样的。
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
但是放弃特定于logging的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
我不确定为什么ACLparsing器会为第一个和第二个示例之间的“this / ou”获取一组不同的值，这似乎是发生了什么事情。
看来我误解了ACL是如何工作的。 显然，你不能对“inheritance”属性进行testing，这是我正在尝试做的。 DN中的属性不是给定对象的一部分：对新手LDAPer来说是一个宝贵的教训。
一旦我发现自己做错了，解决scheme非常简单：
我向与授权对象[0]的uid匹配的inetorgpersonlogging添加了一个“ou”元素。 事情“神奇地”开始工作。
by set="this/ou & user/uid" write
[0]这似乎不是滥用模式，因为每个授权帐户都绑定到一个特定的单元。 诺言！