LDAPツリー設計

LDAP ツリーは、検索範囲、ACL、管理単位を考えて設計する。 ou=people や ou=groups は慣習的なコンテナであり、Linux ユーザーとして扱われる本質ではない。

よくある構成

小規模な OpenLDAP の教材では、次のような DIT がよく使われる。

dc=example,dc=com
  ├─ ou=people
  │    └─ uid=ldapuser
  └─ ou=groups
       └─ cn=developers

ou=people にユーザーを置き、 ou=groups にグループを置く構成である。

ou=people や ou=groups は必須ではない。

これらは LDAP ツリーを整理するための慣習的なコンテナである。

たとえばクライアントが次の範囲を検索するなら、その下にある posixAccount が対象になる。

base dc=example,dc=com
filter (objectClass=posixAccount)

逆に、 ou=people にユーザーを置いても、クライアントが別の検索ベースだけを見ていれば見つからない。

organizationalUnit は、 ou 属性を持つコンテナを作るための標準的な STRUCTURAL objectClass である。

dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people

ou=people という RDN を使うなら、通常はエントリ内にも ou: people を持たせる。そして ou 属性を許可する objectClass として organizationalUnit を使う。

技術的には、 cn=people のような名前を使ってコンテナを作ることもできる。

dn: cn=people,dc=example,dc=com
objectClass: organizationalRole
cn: people

ただし、ユーザーやグループの分類コンテナとしては ou=people、 ou=groups のほうが自然で読みやすい。特別な理由がなければ、標準的な organizationalUnit を使うほうがよい。

次の DN では、RDN に ou=people を使っている。

dn: ou=people,dc=example,dc=com

この場合、エントリ内にも次の属性を書く。

ou: people

これは DN内の名前と属性値は役割が違うためである。DN はエントリの名前であり、属性はエントリの中身である。

ou=people や ou=groups のようなコンテナを作る理由は、見た目だけではない。

たとえば、ユーザー検索を ou=people に絞ると、不要なエントリを検索対象から外しやすい。

base passwd ou=people,dc=example,dc=com
base group  ou=groups,dc=example,dc=com

dc は domainComponent の略で、DNS ドメイン名を LDAP ツリーの基底に変換するときによく使われる。

example.com
  -> dc=example,dc=com

これは慣習として非常に一般的だが、LDAP が DNS と同一の仕組みになるわけではない。LDAP のツリー設計と DNS のゾーン管理は別物である。

小規模な学習環境なら、次の程度で十分である。

dc=example,dc=com
  ├─ ou=people
  ├─ ou=groups
  └─ ou=services

実運用では、次の観点も考える。