В нашем предыдущем разделе я объяснял как мы можем группировать объекты при помощи доменов и лесов. Однако внутри определённой организации объекты могут быть разбиты по категориям на различные группы в соответствии с операциями, организационной структурой, географическим местоположением или ролями и ответственностями. В качестве некого примера, организации имеют множество подразделений. Мы можем преобразовывать каждое из таких подразделений в дочерние домены и группы всех таких объектов департаментов. Однако такой дочерний домен нуждается в каком- то отдельном контроллере домена, так как он будет иметь некий отдельный раздел домена.
Не будет ли лучшим способом группировать эти объекты внутри своего домена? Именно здесь вступают в действие организационные единицы (organizational units). Организационные единиц (подразделения) помогают группировать объекты меньшего масштаба внутри их домена. Наиболее общий способ состоит в группировании воедино объектов которые имеют аналогичные безопасность и административные требования. Например, в подразделении продаж имеется более 50 пользователей. Подразделение продаж использует общие разделяемые папки и принтеры. Их требования безопасности для данных и сетевой среды аналогичны. По этой причине мы можем создать некую организационную единицу (OU, organizational unit) с названием sales и сгруппировать в ней всех пользователей из подразделения продаж. Теперь мы можем применять политики безопасности на полученном уровне OU вместо уровня конкретного пользователя.
При развёртывании контроллера домена создаётся некая структура OU по умолчанию для сегментации всех наиболее распространённых типов объектов, таких как пользователи, компьютеры и контроллеры домены. Имеющиеся администраторы в случае необходимости способны добавлять, перемещать и удалять некую OU.
Замечание
Время от времени мне встречаются инженеры перемещающие/ изменяющие установленную по умолчанию структуру OU. Все такие установленные по умолчанию OU имеют различные подключённые политики безопасности. Если им в действительности требуются изменения, важно сопоставлять те политики безопасности, которые применены и повторно подключаются к соответствующей новой OU по мере необходимости. Я настоятельно рекомендую чтобы вы по крайней мере не изменяли/ перемещали установленные по умолчанию OU контроллеров домена. Тем не менее, вы всё ещё можете добавлять или изменять политики, применяемые к установленным по умолчанию OU.
После того как некий объект назначен в какую- то OU, он наследует те настройки безопасности и разрешения, которые применяются на самом уровне OU. Если те же самые объекты перемещаются в некую иную OU, тогда будут применены соответствующие настройки из этой новой OU и отброшены те установки, которые были применены в своей предыдущей OU. OU также помогают индивидуально делегировать административный контроль для особых задач. Однако имеется возможность создавать администраторов и назначать им управление объектами и ресурсами на неком уровне OU. Для этих администраторов данная OU будет конкретной границей безопасности. Не будет возможности изменять какие бы то ни было прочие объекты вне определённой OU. Позднее в этой книге я буду пояснять делегирование администрирования. OU выступают контейнерами объектов. Их можно ассоциировать с аналогичными или иными объектами. Также как и предки- потомки доменов, OU также способны содержать дочерние OU. Это также встроенные организационные единицы (nested organization units).
OU также могут содержать такие типы объектов как пользователи, группы, контакты, компьютеры, организационные единицы и принтеры:
Active Directory - Организационные подразделения
В нашем предыдущем примере Rebeladmin Corp. имела некое Sales department (подразделение продаж). В имеющейся иерархии OU, самый первый момент, который необходимо предпринять, это создать некую OU с названием Sales department. Все имеющиеся региональные офисы имеют свои собственные подразделения продаж. Большая часть установленных требований безопасности и администрирования для объектов в таких подразделениях продаж те же самые. Однако создание OU на основании географических областей позволит администраторам домена делегировать управление таким объектам индивидуалов или групп в имеющиеся региональные офисы. Кроме того, если требуется применить конкретную политику к какому- то подразделению продаж регионального офиса, она может быть применена на подходящем уровне OU, вместо тог чтобы применять её ко всем Sales department по имеющимся офисам отделений. По умолчанию все устанавливаемые OU наследуют те полномочия, которые применяются к их родительскому OU.
В нашем предыдущем примере те индивидуалы и группы, которые имеют полномочия управления объектами Sales department, по умолчанию имеют контроль над всеми объектами в OU Europe, Asia и North America. Устанавливаемая иерархия OU является независимой. Она не намерена оказывать воздействие на прочую иерархию OU домена. Определённая OU к тому же может содержать объекты лишь из того же самого домена.