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 認証が 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を使用して書き込み権限をテストすると、次のテストでは「ALLOWED」が表示されます。
"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 パーサーが最初の例と 2 番目の例の間で「this/ou」に異なる値セットを取得する理由はわかりませんが、それが起こっているようです。
答え1
ACL の仕組みを誤解していたようです。どうやら、私がやろうとしていた「継承された」属性に対してテストすることはできないようです。DN 内の属性は特定のオブジェクトの一部ではありません。これは、LDAP 初心者にとって貴重な教訓です。
何が間違っていたのかが分かれば、解決策は非常に簡単でした。
承認オブジェクト[0]のuidと一致するinetorgpersonレコードに「ou」要素を追加しました。すると、物事が「魔法のように」動き始めました。
by set="this/ou & user/uid" write
[0] 各認証アカウントは特定のユニットに関連付けられているため、これはスキーマの誤用ではないようです。約束します!