Глава 9. Проектирование структуры OU

В Главе 3, Проектирование инфраструктуры Active Directory мы изучили как мы можем представлять некую организацию на основе доменов. Однако этот иерархический дизайн обладает очерченными границами. Там мы не учитывали требования класса объектов. OU помогают нам задавать необходимую иерархическую структуру для объектов в рамках границ домена на основании требований компании.

Для создания OU имеются три основные причины:

Некий контроллер домена AD поддерживает размещение примерно двух миллиардов объектов. По мере роста числа объектов в имеющейся инфраструктуре, те усилия, которые нам требуется прилагать для управления ими также возрастают. Когда у нас имеется надлежащая структура группирования таких объектов по меньшим группам, у нас имеется больший контроль над ними и мы с первого взгляда определяем где мы можем отыскать необходимый конкретно объект:

На нашей схеме вверху Rebeladmin Corp. имеет около 100 продавцов. Они к тому же применяют примерно 150 настольных компьютеров и ноутбуков. Нет никакой проблемы поместить все эти компьютеры в самый корень установленной иерархии (в контейнеры по умолчанию). Но будет не просто отличать объекты Sales department от прочих объектов AD. Вместо этого мы можем создать определённый OU для Sales department. Он может быть и дальше разбит на два подразделения OU: Users и Computers. Оба этих OU будут на одном и том же уровне иерархии. Теперь, когда нам требуется найти некий объект пользователя из Sales department в AD, мы определённо знаем, что он должен быть в OU Users из OU Sales department. Точно так же, когда нам требуется добавить некий новый объект в Sales department, мы теперь имеем некую предопределённую структуру в которую мы и поместим его. Каждый инженер из департамента ИТ должен следовать одной и той же структуре при управлении объектами, причём это не зависит от его личных предпочтений.

OU можно применять для делегирования администрирования неким набором объектов персонам или группам. Такие персоны будут иметь контроль над управлением объектами в данном OU и эти полномочия обычно задаются Администраторами домена или Администраторами предприятия. Позднее в этой главе мы рассмотрим необходимые этапы настройки.

Мы не можем размышлять об AD без Групповых политик. При помощи Групповых политик, мы можем применять правила управления настройками приложений, установками безопасности и системными настройками объектов AD. Абсолютно все объекты в AD имеют различные рабочие требования и требования безопасности. Например, требования безопасности компьютеров продавцов отличаются от требования сервера, размещающего из систему базы данных. Групповые политики могут быть ограничены на OU. Таким образом, имеющие различные требования Групповой политики объекты могут помещаться в различные OU, а им могут назначаться соответствующие политики. Даже хотя это и наиболее распространённая причина для OU, именно здесь вещи в основном и выходят из под контроля. Если вы не уделите внимания наследованию Групповой политики и старшинству Групповой политики, будет трудно иметь целью надлежащий объект:

В нашем предыдущем примере, имеющаяся структура имеет некую политику по умолчанию default policy, которая применяется к основной массе объектов в установленной структуре AD. Более того, она создана в самой вершине всей иерархии. По умолчанию она наследуется всеми дочерними уровнями OU. Тем самым, Sales department и Users из Sales department будут обладать политикой по умолчанию, наследуемой по умолчанию. Однако эта организация желала бы добавить определённые настройки пользователям продавцам через какую- то Групповую политику. Для этого создаётся некая новая Групповая политика с названием Sales user policy и она ставится в соответствие OU Users из Sales department. По умолчанию OU Computers из Sales department также обладают унаследованной политикой по умолчанию, однако по причине рабочих требований им следует блокировать такую политику и надлежит иметь только Sales computer policy, которая подключена к соответствующему OU Computers. Для осуществления этого нам приходится блокировать имеющееся наследование. После его блокирования, более не будет применяться никакая наследуемая политика от его родительских OU, а будут применяться лишь те политики, которые подключаются к данному OU напрямую. Это поясняет как мы можем использовать OU для применения Групповых политик к надлежащим объектам.

Прежде чем мы реализуем необходимую структуру OU, нам требуется принять решение зачем нам требуется каждый из этих OU. Это необходимо оценивать на основании всех трёх моментов, которыми являются организация объектов, делегирование контроля и применение групповых политик; когда имеющиеся требования не удовлетворяют этим трём моментам, нам не следует устанавливать некий OU. Большинство инженеров не уделяют внимания проектированию необходимой структуры OU, так как эти структуры просто менять по сравнению со структурами домена. Когда установленная структура OU не соответствует вашим потребностям, её можно заменить совершенно новой структурой. Однако за этим следует перемещение объектов и переоформление структуры иерархии имеющейся Групповой политики. Даже хотя OU обладают известной гибкостью для приспособления к изменениям структуры, важно получать верными первоначальные требования.

Когда мы открываем свою Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC) в расширенном просмотре, будут иметься предварительно установленные папки. Однако не все они являются OU. В основном это контейнеры (containers:

Единственным установленным по умолчанию OU в начальной среде AD выступает OU Domain Controllers. Все прочие папки в этом дереве являются контейнерами. Контейнеры также могут содержать объекты. Хорошими примерами этого выступают контейнеры Computers и Users. По умолчанию, все определяемые объекты компьютеров сохраняются в установленном контейнере Computers. Все устанавливаемые по умолчанию учётные записи пользователей и группы безопасности сохраняются в имеющемся контейнере Users. Аналогично OU контейнеры также могут применяться для делегирования административного контроля. Единственным отличием между контейнерами и OU является то, что Групповые политики не могут применяться к контейнерам. Групповые политики можно применять только к OU. Сама система также не позволяет вам создавать новые контейнеры, отличающиеся от тех контейнеров, которые созданы самой системой.

В этом разделе мы намерены рассмотреть различные модели OU. Это не означает, что всякий проект должен состоять из них. Современные требования инфраструктур сложные и создающие проблемы. Данные модели помогут вам в руководстве проектирования подходящего под требования вашей организации.

В разделе Сопоставление контейнеров и OU я упоминал об устанавливаемых по умолчанию контейнерах в среде AD. Одна из основных характеристик таких установленных по умолчанию контейнеров состоит в том, что они обладают большими административными границы. В качестве примера, такой контейнер Computers будет содержать по умолчанию все добавляемые в AD компьютеры. Это может быть некий физический сервер, виртуальный сервер, настольный компьютер или ноутбук. Имеющаяся модель контейнера основывается на аналогичном понятии. Это в целом удобно для небольших организаций, в которых вы ограничены административными требованиями и требованиями безопасности для объектов AD. Когда границы OU имеют большие размеры, невозможно применять выполненные на заказ Групповые политики или точно делегируемый контроль, так как каждый OU может содержать различные классы объектов:

В предыдущей схеме наша организация имеет четыре основных OU. В данной модели с контейнерами не будет никаких дочерних OU. Как мы можем наблюдать, каждый OU охватывает обширные границы. Например, OU Standard users будет содержать объекты абсолютно из всех подразделений. Это не предполагает применения различных политик или делегирования контроля на основе каждого из подразделений. В данном случае для каждого из объектов пользователей в данном OU решения будут применяться на основании их собственных полномочий. Когда некий объект пользователя имеет полномочия Администратора, он будет пребывать в OU Administrators, если же это не так, он будет находиться в OU Standard users.

Наша следующая таблица обсуждает преимущества и недостатки такой модели с контейнерами:

Таблица 9-1. За и против модели с контейнерами

Преимущества	Недостатки
Простота реализации: Нет никаких дочерних OU и нет никакого уровня дополнительной грануляции безопасности, что требует проектирования административных ограничений.	Меньший контроль: Это будут объекты без подразделений по подробностям. Следовательно, у администраторов будет меньший контроль над такими объектами. Поскольку границы администрирования велики, не существует каких бы то ни было практических способов реализации делегирования.
Меньше групповых политик: Когда OU содержат большое число объектов различных классов, трудно быть конкретным при задании установок системы или безопасности. Следовательно каждый OU будет обладать меньшим числом групповых политик. Даже для них настройки будут иметь более высокий уровень чем сложные регулировки.	Меньшая безопасность: Трудно применять различные групповые политики для установления соответствия требований безопасности объектов и рабочих нагрузок, так как установленная структура OU не содействует группировке соответствующих объектов воедино.
Более простое изменение: Поскольку все OU не содержат большого числа Групповых политик и сложных наследований, в случае необходимости, такая структура может полностью меняться с минимальными последствиями.	Меньшая расширяемость: Это не имеющий больших перспектив дизайн. По мере роста бизнеса также будут меняться и требования к управлению объектами. Когда потребуется дальнейшее подразделение, будет сложно его осуществлять без изменения всей структуры целиком.

Как мы знаем, AD содержит различные типы объектов, таких как пользователи, группы и компьютеры. Можно сгруппировать эти различные типы объектов в отдельные OU и управлять ими. Каждый из этих типов может быть далее разделен на дочерние OU на основе географического местоположения или ролей и обязанностей:

В своей предыдущей схеме мы в целом разделили категории на основе типов объектов Users и Computers. Наш OU Users дальше делится на категории Administrators и Standard users Это основывается на уровне полномочий и ответственностей каждого из объектов внутри данной организации. Наш OU Computers получает дочерний OU дляServers. Он играет иную роль нежели прочие объекты компьютеров, таких как настольные компьютеры/ ноутбуки. Он и дальше разбивается на категории по географическому местоположению рабочих нагрузок.

Следующая таблица перечисляет преимущества и недостатки такой модели типов объектов:

Таблица 9-2. За и против модели с типами объектов

Преимущества	Недостатки
Гибкость: Когда дело доходит до разбиение по категориям объектов, это предоставляет большую гибкость. Для каждого из типов объектов вы можете разбивать категории и далее на основе ролей, географического положения,команд, подразделений и тому подобного.	Сложность: Поскольку эта модель даёт инженерам свободу разбивать объекты по категориям при помощи множества вариантов, такую структуру может оказаться сложно сопровождать. Нет никаких ограничений на общее число растущих уровней, причём управление также усложняется.
Более простое управление объектами AD: Ключевая польза данной модели состоит в упрощении управляемости. Именно по этой причине многие методы применяют разбиение объектов на категории. Когда объекты разбиты по небольшим категориям в малых административных границах, управление объектами становится проще во всех смыслах.	Трудность структурных изменений: Когда возникают требования изменения структуры OU, будет сложно и дальше применять к этим объектам подогнанные под них установки и делегирование контроля. При структурных изменениях, такие особые установки также требуется перемещать вместе с объектами.
Расширяемость: Поскольку эта модель позволяет вам применять большое число вариантов по разбиению объектов на категории, она обладает высокой степенью расширяемости для реализации последующих организационных требований с минимальным воздействием.	Нет
Применение групповых политик: При разбиении на категории более гранулированным образом групповые политики могут применяться к объектам более подходящим образом.	Нет

Это одна из самых распространённых моделей для больших организаций. Её структура OU основывается на географическом местоположении рассматриваемых филиалов компании. Каждый из таких филиалов компании может также иметь свою собственную команду ИТ. По этой причине самая основная идея, стоящая за данной моделью состоит в делегировании административного контроля:

В нашей предыдущей схеме рассматриваемая организация обладает двумя филиалами в Азии и Европе. Самый первый уровень её OU был создан на основании географического местоположения, а затем он делится по категориям на основании типов объектов. И Asia и Europe, оба обладают дочерними OU Users и Computers на своём вторичном уровне. В такой модели в большинстве случаев каждое географическое местоположение будет следовать одной и той же структуре в своих дочерних OU. Это делает для вас возможным простым делегирование контроля группе администраторов для управления объектами филиалом компании. Такой подход улучшает управление инфраструктурой и саму производительность действий ИТ.

Ниже перечислены преимущества и недостатки данной географической модели.

Таблица 9-3. За и против географической модели

Преимущества	Недостатки
Делегирование контроля: Как пояснялось ранее, основной составляющей ценности данной модели является простота делегирования контроля. Каждый объект относится к своему филиалу согласно местоположению в единой структуре и такое делегирование управления предоставляет дополнительный контроль для администраторов.	Сложность: Поскольку эта модель даёт инженерам свободу разбивать объекты по категориям при помощи множества вариантов, такую структуру может оказаться сложно сопровождать. Нет никаких ограничений на общее число растущих уровней, причём управление также усложняется.
Расширяемость: Ограниченная расширяемость по сравнению с моделью для типов объектов. В большинстве случаев каждое подразделение должно следовать предварительно заданным стандартам. Таким образом, когда требуются структурные изменения, это будет иметь ограничения на основании таких стандартов.	Повторяемость: В большинстве случаев такой модели каждый филиал компании будет иметь аналогичные административные, операционные требования и требования безопасности. Таким образом, большинство настроек Групповой политики, применяемых в одном филиале будут применимы также и к другому филиалу.
Расширяемость: Поскольку эта модель позволяет вам применять большое число вариантов по разбиению объектов на категории, она обладает высокой степенью расширяемости для реализации последующих организационных требований с минимальным воздействием.	Операционные ограничения: Каждое команда ИТ филиала компании будет обладать делегированным контролем для управления объектами своего филиала компании. Однако эти полномочия имеют ограничения. Может оказаться, что для осуществления определённых задач им всё ещё будет требоваться зависимость от команды ИТ своей штаб- квартиры.
Сопровождение стандартов: Данная модель делает возможным для вас придерживаться административных стандартов и стандартов безопасности по всей организации даже когда имеются различные филиалы компании. Даже когда ИТ командам филиалов делегирован контроль для определённых задач, привилегированные администраторы способны изменять или отзывать такое делегирование контроля.	Нет

Модель подразделения представляет имеющийся иерархический порядок организации, а также разбиение на категории зон ответственности. Мы также можем пользоваться департаментами для разбиения объектов на категории в среде AD:

В нашей приведённой выше схеме общая структура OU начинается со своих подразделений. Каждое подразделение обладает своим собственным OU и его объекты дальше разбиваются на основании имеющегося класса и зон ответственности. Это позволяет нам запросто делегировать контроль объектов в каждом из подразделению Как пример, управляющим каждого из подразделений может быть установлено делегирование контроля для добавления и изменения объектов в своих собственных подразделениях.

Преимущества и недостатки такой модели подразделений перечисляются следующим образом:

Таблица 9-4. За и против модели подразделения

Преимущества	Недостатки
Распределённый делегированный контроля: В имеющихся подразделениях объекты группируются совместно на основании классов и зон ответственности. Это делает возможным для администраторов делегировать контроль персонам или группам для управления объектами в рамках действий их собственных подразделений. Администраторам не требуется изменять установленную структуру на основе делегирования требований, так как эта модель сгруппирует их по умолчанию так, как то требуется.	Сложность локализации объекта для соответствия со структурой: Не все объекты могут соответствовать данной структуре. В организациях имеются средства и службы, которые совместно используются различными подразделениями. Например, принтеры, файловые серверы и серверы электронной почты разделяются всеми имеющимися в такой организации подразделениями. Они потребуют представления в неком общем OU, что не соответствует имеющейся структуре обычной организации.
Минимальные структурные изменения: Поскольку данная модель соответствует рабочей и структурной архитектуре самой компании, по сравнению с прочими моделями вносимые в структуру OU изменения минимальны	Ограниченность применения настроек для всей компании: В организации существуют требования к работе и безопасности, которые не зависят от подразделения. Например, некие политики безопасности данных организации, политики сетевой безопасности, а также измерения защищённости идентичности общие для всех подразделений и абсолютно всех пользователей в определённой организации. Поскольку объекты группируются на основании уровней подразделений, у нас будут иметься ограничения в целеуказании объектов для применения таких различных политик.
Меньшая сложность: Рабочие структуры организации (подразделения) обычно не сложны. Подразделения имеют хорошо заданную структуру для управления их средствами и зонами ответственности. Так как получаемая структура OU практически реплицирует данную модель, получаемая структура OU также будет менее сложной при управлении ею.	Нет

Эти различные типы моделей могут применяться как руководство для проектирования вашей структуры OU. Возможно никакая из этих моделей не соответствует в точности вашим бизнес- требованиям. Абсолютно нормально создавать смешанные модели с применением перечисленных, но убедитесь что вы получили подтверждение своего проекта, рассмотрев простоту управления объектами, требования GPO и надлежащее делегирование контроля.

Аналогично всем прочим объектам Active Directory, имеющаяся структура OU может управляться посредством ADAC (Active Directory Administrative Center), MMC ADUC и PowerShell. В этом разделе я намерен продемонстрировать то как управлять вашей структурой OU с помощью PowerShell.

Давайте начнём это с нового OU. Мы можем применить cmdlet New-ADOrganizationalUnit для создания некого нового OU. Его полный синтаксис можно просмотреть при помощи такой команды:

Get-Command New-ADOrganizationalUnit -Syntax
		

Своим первым шагом я намерен создать некий новый OU с названием Asia для представления Азиатского филиала:

New-ADOrganizationalUnit -Name "Asia" -Description "Asia Branch"
		

В нашем предыдущем примере -Description определяет описание для нашего нового OU, когда нет никакого определения пути, будет создано OU в самом корне. Мы можем рассмотреть подробности своего нового OU при помощи следующей команды:

Get-ADOrganizationalUnit -Identity "OU=Asia,DC=rebeladmin,DC=com"
		

При помощи приводимой далее команды мы способны добавлять/ изменять значения атрибутов OU:

Get-ADOrganizationalUnit -Identity "OU=Asia,DC=rebeladmin,DC=com" | Set-ADOrganizationalUnit -ManagedBy "Asia IT Team"
		

Наша предыдущая команда установит значение атрибута ManagedBy в Asia IT Team.

Хорошим охранником, который мы можем применять является ProtectedFromAccidentalDeletion для конкретного объекта OU. Это предотвратит от случайного удаления объекта OU. Он будет применяться по умолчанию когда вы пользуетесь для создания OU ADAC или ADUC:

Get-ADOrganizationalUnit -Identity "OU=Asia,DC=rebeladmin,DC=com" | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true
		

На своём следующем шаге я намерен создать некий подчинённый OU в своём OU Asia с названием Users:

New-ADOrganizationalUnit -Name "Users" -Path "OU=Asia,DC=rebeladmin,DC=com" -Description "Users in Asia Branch" -ProtectedFromAccidentalDeletion $true
		

Наша предыдущая команда создаст некий OU с названием Users в пути OU=Asia,DC=rebeladmin,DC=com. Он также защищён от непредумышленного удаления.

Теперь у нас имеется соответствующая структура OU. Нашим следующим шагом является перемещение в неё объектов. Для этого мы можем воспользоваться cmdlet -ом Move-ADObject:

Get-ADUser "tuser3" | Move-ADObject -TargetPath "OU=Users,OU=Asia,DC=rebeladmin,DC=com"
		

Наша предыдущая команда отыщет указанный объект tuser3 и переместит этот объект в OU=Users,OU=Asia,DC=rebeladmin,DC=com.

Мы способны также перемещать в свой новый OU множество объектов:

Get-ADUser -Filter 'Name -like "Test*"' -SearchBase "OU=Users,OU=Europe,DC=rebeladmin,DC=com" | Move-ADObject -TargetPath "OU=Users,OU=Asia,DC=rebeladmin,DC=com"
		

Наша предыдущая команда вначале находит все учётные записи пользователей, которые начинаются с Test в OU=Users,OU=Europe,DC=rebeladmin,DC=com, а затем перемещает все обнаруженные ею объекты в наш новый путь OU.

Если нам необходимо удалить некий OU, это может быть выполнено посредством cmdlet Remove-ADOrganizationalUnit:

Remove-ADOrganizationalUnit "OU=Laptops,OU=Europe,DC=rebeladmin,DC=com"
		

Наша предыдущая команда удалит указанный OU OU=Laptops,OU=Europe,DC=rebeladmin,DC=com .

Администраторы могут делегировать контроль на основе OU. Это предоставляет контроль персонам или группам для управления объектами в рамках OU.

В своей демонстрации я намерен предоставить делегирование контроля для участников Asia IT Team чтобы управлять объектами в OU Asia:

OU играют критически важную роль в AD, делая возможным создание иерархической структуры в рамках границ домена. Такая иерархическая структура должная создаваться с учётом управления объектами, делегирования контроля и применения Групповых политик для управления приложениями, службами и настройками безопасности. В данной главе мы изучили почему проектирование важно и что требуется принимать в расчёт при проектировании необходимых структур OU. К кону главы мы изучили как управлять OU в имеющейся инфраструктуре Active Directory и как делегировать контроль в OU.

В своей следующей главе мы рассмотрим Групповые политики, которые являются одной из центральных функциональных возможностей в Active Directory.