Я преподаватель, преподающий Active Directory, и я уже некоторое время задаюсь следующим вопросом: при планировании новой структуры AD имеет ли смысл создавать местоположения в DIT (Directory Information Tree) как OU? Или это не очень хорошая идея, поскольку местоположения в любом случае можно настроить как объекты? Какой подход здесь будет хорошим?
Каковы аргументы в пользу Sites as OUs? Каковы аргументы против Sites as OUst?
решение1
Обычной практикой для конфигурации ваших сайтов и подсетей является максимально точное описание физической сети, при этом ссылки сайтов описывают, как соединены отдельные сайты. При правильном выполнении это позволяет AD принимать довольно умные решения относительно того, какие контроллеры домена использовать для обслуживания ваших аутентификаций и т. д. (например, какой должен взять на себя управление данным сайтом, если один из них выйдет из строя на некоторое время). На большом предприятии это может иметь решающее значение. Важным моментом является то, что у вас также есть определенные объекты подсети для всех ваших подсетей, поскольку первое, что делает устройство при запуске Windows, — это пытается определить, где оно находится. Если оно не может этого сделать, то любой контроллер домена в вашей сети может быть честно использован для аутентификации, что может привести к очень низкой производительности, если у вас есть недоиспользуемый контроллер домена на дальнем конце куска мокрой веревки!
решение2
Не существует правильного или неправильного ответа на создание OU на основе местоположения или организационной структуры. Даже комбинация обоих вариантов может сработать. Ответ на 100% основан на потребностях организации. Поверьте мне, когда я говорю, что какой бы макет вы ни выбрали, не все будут довольны. По моему мнению, OU следует создавать в первую очередь для делегирования административных привилегий. OU могут разделить ответственность за объекты AD, когда вы также создаете группу безопасности и делегируете управление OU этой группе. Это решает самую большую головную боль, связанную с пониманием того, кто чем управляет.
Другие типичные причины создания OU, такие как применение GPO или определение географического положения объектов, могут быть достигнуты более простыми способами. GPO можно применять с помощью фильтров WMI, фильтрации групп безопасности или связывать с сайтами AD. Не создавайте OU только для применения GPO, если только этот GPO не предназначен для заполнения локальных групп администраторов через Restricted Groups (подсказка-подсказка). Физическое расположение объектов должно храниться в атрибутах каждого объекта. Запрашивайте эти атрибуты, когда хотите узнать, в каком городе или здании находится этот пользователь или компьютер. У вас мало контроля над людьми, перемещающимися из одного места в другое, и именно поэтому структуры OU на основе местоположения плохо справляются с задачей определения физического положения чего-либо. Конечно, атрибуты также могут в конечном итоге оказаться неправильными, но обновление атрибута имеет меньше последствий, чем изменение OU.
решение3
Active Directory позволяет отделить логическую топологию от физической топологии.
Вы можете определить несколько сайтов с контроллерами домена в каждом из них. Сайты сопоставляются с IP-подсетями, и каждый компьютер в домене может искать «ближайший» контроллер домена на основе своей IP-подсети. Вы также можете управлять репликацией информации AD между сайтами.
Вам определенно стоит воспользоваться этим преимуществом, поскольку структура AD предусматривает многосайтовость и отказоустойчивость.
TL;DR: Вам следуетнетсопоставьте свои физические сайты с OU, ни один из них не использует несколько доменов. AD более чем способен позаботиться о нескольких сайтах; несколько доменов или OU, привязанные к сайту, определенно не нужны для этого.
Более подробная информация здесь:https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/understanding-active-directory-site-topology