LDAP構造：dc = example、dc = com vs o = Example

私はLDAPが比較的新しいので、構造を設定する方法の2つのタイプの例を見てきました。

1つの方法はdc=example,dc=com、ベースビーイングを使用することo=Exampleです。他の例では、ベースビーイングを使用します。続けて、次のようなグループを作成できます。

    dn：cn = team、ou = Group、dc = example、dc = com
    cn：チーム
    objectClass：posixGroup
    memberUid：user1
    memberUid：user2

...または「O」スタイルを使用：

    dn：cn = team、o = Example
    objectClass：posixGroup
    memberUid：user1
    memberUid：user2

私の質問は：

1. あるメソッドを他のメソッドよりも使用することを指示するベストプラクティスはありますか？
2. どちらのスタイルを使用するかは好みの問題ですか？
3. どちらか一方を使用する利点はありますか？
4. 1つの方法は古いスタイルで、もう1つの方法は新しい改良バージョンですか？

これまでのところ、私はこのdc=example,dc=comスタイルに取り組んできました。コミュニティが問題について与えることができるどんなアドバイスも大歓迎です。

このdcスタイルは一般に、何らかのDNSベースのLDAPツリーを示します。これは、Active Directory（AD）が使用するスタイルです。DNSベースのLDAPツリーを気にしない場合は、他のタイプを使用できます。NovellのeDirectoryはOベースツリーです。いくつかの注意事項：

• DCスタイルはADが使用するものです。このスタイルのツリーのようなAD LDAPソースをサポートする多くのサードパーティ製品は、Oベースのツリーよりもはるかに優れています。これらのクライアントがOスタイルのLDAPツリーと通信するのに問題がありました。
• ADはまったく使用しないOため、一部のLDAPクライアント/パーサーは結果としてサポートしない場合があります。同じことがL（場所）にも当てはまります。
• ツリーをDNSルート化していない場合、DCスタイルはそれほど重要ではありません
• ハイブリッドスタイルは問題ありません。LDAPルートはdc=example,dc=comであり、その下でOスタイルのツリーを使用します。DNは非常によく、cn=bobs,ou=users,o=company,dc=example,dc=com

一般的に、サードパーティのLDAPクライアントとの互換性を確保する必要があります。方言が必要な場合は、可能な限りActive-Directoryに見える必要があります。それらが純粋なLDAPクライアントである場合、仕様全体を実際にサポートするという点で、構造は重要ではありません。

LDAPツリー構造の標準については知りませんが、他の標準がある場合は、他のパイプラインがパイプされると確信しています。