Могу ли я получить объяснение синтаксиса суффиксов базы поиска LDAP?

Я знаю, что суффикс базы поиска LDAP обычно совпадает с именем хоста сервера каталогов. Другими словами, я знаю, если имя хоста od.foobar.com, я должен использовать суффикс базы поиска:dc=od,dc=foorbar,dc=com

Меня беспокоит, что я не понимаю, почему я это делаю. Может ли кто-нибудь предоставить некоторые сведения и точно объяснить, что я делаю?

До того, как Microsoft «охватила, расширила и изменила» LDAP, в большинстве реализаций были объекты, представляющие корень дерева. Т.е. начинать нужно откуда-то.

По причинам, которые мне не совсем понятны, в Active Directory каждый домен в дереве / лесу коренится с именем dc = domain, dc = com, которое на самом деле не является двумя отдельными объектами, скорее это виртуальный корень каталога пространство имен.

Я думаю, что отчасти это происходит из-за того, что независимо от того, что говорится об Active Directory, это все еще ряд связанных доменов, и каждый домен должен рассматриваться как самостоятельный объект.

Теперь в дереве AD есть автоматические транзитивные доверительные отношения, поэтому для конечных пользователей это менее важно, но хотя пространство имен выглядит несколько смежно, на самом деле это не так.

Это становится более очевидным с некоторыми правилами именования в AD. Например, sAMAccountName должно быть уникальным в пределах домена, независимо от того, находятся ли они в одном контейнере или нет. Т.е. полное различающееся имя должно быть уникальным (вы не можете иметь двух пользователей John Smith в одном контейнере), но короткое имя, которое используется для многих внутренних целей (sAMAccountName), должно быть уникальным во всем домене.

К другим службам каталогов предъявляются аналогичные требования, например, uniqueID должен быть действительно уникальным во всем каталоге, но это еще не все, потому что приложения обычно делают это предположение, поскольку разработчики приложений слишком ленивы, чтобы справиться со сложной проблемой (я не виню это сложная проблема) того, как обрабатывать двух пользователей с короткими именами jsmith, пытающихся использовать службу, но находящихся в двух разных контейнерах. (Т. Е. Возможно cn = jsmith, ou = Лондон, dc = acme, dc = com и cn = jsmith, ou = Техас, dc = acme, dc = com).

Как ваше приложение, использующее этот каталог, должно решить, какого пользователя использовать? Обычный ответ - пользователь может решить. Но это означает, что нужно поймать этот случай, представить пользовательский интерфейс и многое другое.

Большинство разработчиков приложений просто игнорируют эту возможность и просто используют uniqueID или sAMAccountName, потому что это уникально (своего рода) и легче сделать.

Разница между uniqueID и sAMAccountName заключается в том, что uniqueID должен быть уникальным во всем пространстве имен каталога. Принимая во внимание, что sAMAccountName гарантированно уникален только в пределах домена. Если в дереве AD есть несколько доменов, то нет никакой гарантии уникальности между доменами.

Другие объяснили, почему использование доменного имени - хорошая идея (но не обязательная). Я просто добавляю, что вопрос неправильный: использование базового суффикса, основанного на имени машины, вообще не рекомендуется (по понятным причинам: что, если вы замените gandalf.example.comна sarouman.example.com?). Обычно вы используете только делегированное доменное имя, поэтому, если у вас есть example.com, вы используете dc=example,dc=com.

Корень каталога должен быть установлен на что-то. Это может быть установлено на что угодно. Установка его в качестве имени домена является просто полезным соглашением, которое гарантирует, что пространство имен вашего каталога уникально.

Краткая версия: сопоставьте свое доменное имя, чтобы гарантировать уникальность базового пути.

Сделайте это, и вы не будете выглядеть как новый администратор, если ваша компания объединится с другой, и вам нужно объединить системы :)

Хорошо, это была очень короткая версия =)