Назад | Перейти на главную страницу

Структура LDAP: dc = example, dc = com vs o = Example

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

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

    dn: cn=team,ou=Group,dc=example,dc=com
    cn: team
    objectClass: posixGroup
    memberUid: user1
    memberUid: user2

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

    dn: cn=team, o=Example
    objectClass: posixGroup
    memberUid: user1
    memberUid: user2

Мои вопросы:

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

Пока что я пошел с dc=example,dc=com стиль. Мы будем очень признательны за любые советы, которые сообщество может дать по этому поводу.

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

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

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

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