Мне нужны рекомендации по структурированию каталога LDS и поиск только лучших практик, нацеленных на доменные службы. Есть ли здесь у кого-нибудь ссылки на иерархическую структуру, которую мы создали в каталоге?
Меня интересуют мелкие элементы, например, назвать ли верхний узел тегами «DC» или «O» и т. Д. Например, если это будет «DC = CompanyName, DC = local», когда мы фактически не используем никаких конкретный домен? Разве это не должно быть «O = CompanyName»? И меня интересует, стоит ли вообще рассматривать этот вопрос.
Чтобы понять разницу между dc= и o= в Active Directory вам нужно помнить, что Active Directory - это Реализация LDAP в его ядре.
DC= на языке LDAP определяет Компонент домена. Его следует использовать, если и только если вы определяете то, что существует в пространстве DNS.
Если ваша организация foobarco.example.com в DNS совершенно законно использовать dc=foobarco,dc=example,dc=com как ваш корень.
O= на языке LDAP определяет Организация. Его следует использовать при определении элемента организации, который существует вне других иерархий, таких как DNS.
Например, если foobarco.example.com была дочерняя компания под названием Shiny Widgets с собственным доменом AD, но не с собственным доменом DNS, вы бы укоренили это дерево в o=ShinyWidgets,dc=foobarco,dc=example,dc=com.
Обычно предполагается, что домен AD будет иметь соответствующее пространство имен DNS, поэтому наиболее распространенная конфигурация, которую вы увидите с Active Directory, заключается в том, что корень дерева будет определяться серией Dдомен Cкомпоненты.
Обычно я использую только теги DC для корневого DN. Например:
DC=something,DC=example,DC=COM
Я также сопоставляю часть корня с доменом (в данном случае это example.com). Это просто привычка, она не поможет и не помешает вам, например, использовать прокси-аккаунты.
Каждый продукт с поддержкой LDAP, который я могу придумать, позволяет вам указать полный DN пути, по которому находятся ваши пользователи. Таким образом, используемые вами компоненты не имеют такого значения, как сама структура (называемая информационным деревом каталогов или DIT). По сути, вам нужно сбалансировать две вещи:
Плоский DIT, где, например, все пользователи будут в:
OU=Users,DC=something,DC=example,DC=COM
Подойдет к любой организационной структуре, с которой вам придется работать. Но вы пожертвуете некоторой способностью разделять пользователей между приложениями, использующими ваш LDS.
Вот пример. Если у вас есть два приложения, у вас может быть:
OU=Application_A,OU=Users,DC=something,DC=example,DC=COM
OU=Application_B,OU=Users,DC=something,DC=example,DC=COM
Но что будет, если пользователь из Application_A хочет использовать Application_B ? То же самое и с группами:
OU=Groups_A,OU=Users,DC=something,DC=example,DC=COM
OU=Groups_B,OU=Users,DC=something,DC=example,DC=COM
Короче говоря, не беспокойтесь о компонентах, но подумайте о том, насколько хорошо ваше DIT будет соответствовать другому сценарию повторного использования.