Я знаю, что суффикс базы поиска LDAP обычно совпадает с именем хоста сервера каталогов. Другими словами, я знаю, является ли имя хоста od.foobar.com, Я должен использовать суффикс базы поиска: dc=od,dc=foorbar,dc=com
Меня беспокоит то, что я не понимаю, зачем я это делаю. Может ли кто-нибудь предоставить некоторую предысторию и точно объяснить, что я делаю?
Другие объяснили, почему использование доменного имени - хорошая идея (но не обязательное). Я просто добавляю, что вопрос неверный: наличие базового суффикса на основе имени машины не рекомендуется вообще (по понятным причинам: а если заменить gandalf.example.com по sarouman.example.com ?). Обычно вы используете только делегированное доменное имя, поэтому, если у вас есть example.com, ты используешь dc=example,dc=com.
До того, как Microsoft «охватила, расширила и изменила» LDAP, в большинстве реализаций были объекты, представляющие корень дерева. Т.е. Вы должны откуда-то начинать.
По причинам, которые мне не совсем понятны, в Active Directory каждый домен в дереве / лесу имеет корень с именем dc = domain, dc = com, которое на самом деле не два отдельных объекта, а скорее виртуальный корень каталога. пространство имен.
Я думаю, что отчасти это связано с тем фактом, что независимо от того, что говорится об Active Directory, это все еще ряд связанных доменов, и каждый домен нужно рассматривать как отдельный объект.
Теперь в дереве AD есть автоматические транзитивные доверительные отношения, так что это делает его менее важным для конечных пользователей, но хотя пространство имен выглядит как бы непрерывным, на самом деле это не так.
Это становится более очевидным с некоторыми правилами именования в AD. Например, sAMAccountName должно быть уникальным в пределах домена, независимо от того, находятся они в одном контейнере или нет. Т.е. Полное отличительное имя должно быть уникальным (у вас не может быть двух пользователей John Smith в одном контейнере), но короткое имя, которое используется для многих внутренних целей (sAMAccountName), должно быть уникальным в пределах всего домена.
Другие службы каталогов либо имеют несколько схожие требования, например, uniqueID действительно должен быть уникальным во всем каталоге, но это больше потому, что приложения обычно делают это предположение, поскольку разработчики приложений были слишком ленивы, чтобы решать сложную проблему (я не виню их, это сложная проблема) как обращаться с двумя пользователями с короткими именами jsmith, пытающимися использовать службу, но существующими в двух разных контейнерах. (То есть, возможно, cn = jsmith, ou = London, dc = acme, dc = com и cn = jsmith, ou = Texas, dc = acme, dc = com).
Как ваше приложение, использующее этот каталог, должно решать, какого пользователя использовать? Обычный ответ - позволить пользователю решать. Но это означает уловить этот случай, предоставить пользователю пользовательский интерфейс, из которого он выберет, и еще много чего.
Большинство разработчиков приложений просто игнорируют эту возможность и просто используют uniqueID или sAMAccountName, потому что это уникально (в некотором роде) и легче сделать.
Разница между uniqueID и sAMAccountName заключается в том, что uniqueID должен быть уникальным во всем пространстве имен каталога. В то время как sAMAccountName гарантированно уникален только в пределах домена. Если в дереве AD есть несколько доменов, там нет гарантии уникальности между доменами.
Корень каталога должен быть установлен на что-то. Его можно настроить так, как вам нравится. Установка имени домена - это просто полезное соглашение, которое гарантирует уникальность пространства имен вашего каталога.
Краткая версия: сопоставьте свое доменное имя как гарантию уникальности базового пути.
Сделайте это, и вы не будете выглядеть как новичок-админ, если ваша компания объединится с другой, и вам нужно объединить системы :)
Хорошо, это был очень короткая версия =)