我必須在 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 中的屬性不是給定物件的一部分：這對 LDAP 新手來說是一個寶貴的教訓。
一旦我弄清楚我做錯了什麼，解決方案就非常簡單：
我為 inetorgperson 記錄中新增了一個與授權物件 [0] 的 uid 相符的「ou」元素。事情「神奇地」開始發揮作用。
by set="this/ou & user/uid" write
[0] 這看起來並不是對模式的濫用，因為每個身份驗證帳戶都與特定的單元相關聯。承諾！