Структура LDAP: dc = пример, dc = com vs o = пример

Я относительно новичок в LDAP и видел два типа примеров того, как настроить вашу структуру.

Один из методов заключается в том, чтобы иметь основу, dc=example,dc=comтогда как другие примеры имеют основу o=Example. Продолжая, вы можете создать группу, похожую на:

    dn: cn = команда, ou = группа, dc = пример, dc = com
    cn: team
    objectClass: posixGroup
    memberUid: user1
    memberUid: user2

... или используя стиль "O":

    dn: cn = команда, o = пример
    objectClass: posixGroup
    memberUid: user1
    memberUid: user2

Мои вопросы:

1. Есть ли лучшие практики, которые диктуют использование одного метода над другим?
2. Это просто вопрос предпочтения, какой стиль вы используете?
3. Есть ли преимущества использования одного над другим?
4. Является ли один метод старым стилем, а другой - новой и улучшенной версией?

До сих пор я пошел со dc=example,dc=comстилем. Любой совет, который сообщество может дать по этому вопросу, будет принята с благодарностью.

dcСтиль обычно указывает на DNS на основе LDAP дерево своего рода. Это стиль, который использует Active Directory (AD). Если вас не интересуют деревья LDAP на основе DNS, тогда другие типы можно использовать просто отлично. EDirectory Novell является Oоснованным деревом. Некоторые предостережения:

• Стиль DC - это то, что использует AD. Многие сторонние продукты, поддерживающие AD LDAP-источники, любят этот стиль дерева намного лучше, чем Oоснованные на дереве . Мне было трудно заставить этих клиентов общаться с деревьями LDAP в стиле O.
• AD вообще не используется O, поэтому некоторые клиенты / парсеры LDAP могут не поддерживать его в результате. То же самое касается L(местоположение).
• Если вы не внедряете DNS в свое дерево, стиль DC гораздо менее важен
• Гибридные стили просто отлично. Ваш корень LDAP есть dc=example,dc=com, и вы используете дерево O-style под ним. DN вполне может быть,cn=bobs,ou=users,o=company,dc=example,dc=com

Как правило, ваша структура должна быть совместима с LDAP-клиентом стороннего производителя. Если ему нужен диалект, он, вероятно, должен выглядеть как можно более активным-каталогом. Если они являются чистыми клиентами LDAP, поскольку они действительно поддерживают всю спецификацию, тогда структура не должна иметь значения.

Я не знаю ни одного стандарта древовидной структуры ldap, но я уверен, что другие будут работать, если таковые будут.