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

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

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

Давайте пройдём далее и взглянем подробнее на каждый из этих моментов.

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

На нашей схеме вверху Rebeladmin Corp. имеет около 100 продавцов. Они к тому же применяют примерно 150 настольных компьютеров и ноутбуков. Нет никакой проблемы поместить все эти компьютеры в самый корень установленной иерархии (в контейнеры по умолчанию). Но будет не просто отличать объекты Sales department от прочих объектов Active Directory. Вместо этого мы можем создать определённый 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) обладают несомненными сходствами. И те, и другие могут совместно применяться с объектами групп. И те и другие могут применяться с Групповыми политиками. Однако между ими имеется и ряд различий.

Таблица 9-1. Сравнение групп и OU AD

Свойство	Группы Active Directory	Организационные элементы (OU)
Структура иерархии	Плоская структура. Группа может обладать различными типами объектов (пользователей, устройств, групп) в качестве участников, однако не могут представлять их порядок иерархии.	Могут применять различные модели для расположения OU в иерархической структуре. К тому же пособны в случае любой необходимости запросто изменять свою структуру.
Помещение объектов	Один объект способен быть частью множества различных групп.	Один объект может в определённый момент времени использовать один OU.
Списки контроля доступа (ACL)	Группы могут добавляться в ACL.	OU не могут быть частью ACL.
Значение идентификатора безопасности (SID)	Обладает значением SID.	Не имеет значения SID.

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

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

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

Когда границы OU имеют большие размеры, невозможно применять выполненные на заказ Групповые политики или точно делегируемый контроль, так как каждый OU может содержать различные классы объектов:

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

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

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

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

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

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

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

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

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

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

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

В среде Active Directory в основном имеются два типа объектов - Учётные записи (Accounts) и Ресурсы (Resourse). В небольшой организации вы можете группировать эти Учётные записи и Ресурсы на основании "функций". Например, давайте предположим что в Rebeladmin Inc. работают три веб сервера IIS и два сервера Microsoft SQL для размещения приложений на веб основе. Веб серверы IIS обладают в организации особой функцией. Мы можем сгруппировать эти три веб сервера IIS в свою группу "Web Servers". Каждый сервер в этой группе обладает аналогичной ролью в представлении операций компании. Точно также мы можем сгруппировать серверы Microsoft SQL как "Database Servers". Эти серверы будут применяться для размещения баз данных. Тот же самый метод применим также и к Учётным записям ("Accounts"). Например, пользователи из "Marketing Team" имеют один и тот же набор обязанностей в своей организации.

Таким образом, имеет смысл управлять Учётными записями Marketing Team как одной группой. Давайте рассмотрим как мы можем применять их для создания некой структуры Организационного элемента (OU).

В приведённой выше схеме примера имеются два OU - Учётные записи и Ресурсы. Затем Организационный элемент Учётных ресурсов и далее разбивается на различные OU на основе функции/ обязанностей Учётной записи.

Это не требует необходимости следованию организационной схеме самой организации. Для каждого подразделения может иметься потребность во множестве групп Учётных записей с различными функциями. Например, подразделение ИТ может обладать разными Организационными элементами, например "Server Administrators", "Network Engineers", "Storage Administrators" и так далее. Однако, могут иметься ситуации, в которых одна Учётная запись обладает обязанностями, которые могут размещаться в различных OU. В отличии от групп, объект может появляться лишь в одном Организационном элементе. Итак, важно понимать необходимую роль и обязанности объекта перед его размещением.

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

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

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

Это одна из самых распространённых моделей для больших организаций. Её структура Организационного элемента (OU) основывается на географическом местоположении рассматриваемых филиалов компании.

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

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

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

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

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

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

Мы также можем пользоваться департаментами для разбиения объектов на категории в среде Active Directory:

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

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

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

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

На данный момент в этой главе мы прошли несколько различных моделей Организационных элементов (OU). Каждая из них обладает преимуществами, также как и недостатками. Это не означает что для создания хорошего проекта OU нам требуется применять один из представленных проектов. Эти модели могут применяться как руководство для проектирования вашей собственной структуры на основе требований операций. Мы можем применять несколько моделей совместно и создавать собственную модель, если оно потребуется. Это носит название "гибридной модели". Нет никаких ограничений для множества различных моделей, которые вы можете смешивать или те способы, которыми вам приходится применять.

Всё это отдаётся на откуп инженерам для принятия решения на основании требований их операций. По причине такой "свободы", инженеры широко пользуются этой моделью.

В своём предыдущем примере я воспользовался двумя моделями Организационных элементов (OU), которыми выступают географическая модель и модель функций. На верхнем уровне ресурсы разбиваются на категории на основе географического уровня и затем каждое местоположение обладает OU Учётных записей и Ресурсов. Затем она и далее разбивается на различные OU на основании имеющихся функций/ обязанностей своих объектов. Как мы можем видеть, наша гибридная модель позволяет вам группировать объекты наиболее подходящим образом.

Давайте проследуем далее и выполним оценку преимуществ и недостатков нашей гибридной модели:

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

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

Когда речь идёт о гибридной модели, не существует правильного или неверного проекта. Свобода смешения моделей позволяет вам даже создавать вашу собственную модель, которая допустима только для вашей организации. Кроме того, даже когда имеются ошибки проектирования, мы можем изменять структуру Организационного элемента с минимальным воздействием на ваш бизнес.

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

Давайте начнём это с нового OU. Мы можем применить командлет 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.

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

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

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

На своём следующем шаге я намерен создать некий подчинённый Организационный элемент в своём 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. Нашим следующим шагом является перемещение в неё объектов. Для этого мы можем воспользоваться командлетом 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, это может быть выполнено посредством командлет 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:

Обратите внимание: Администраторы могут создавать индивидуальные MMC для Asia IT Team чтобы управлять Организационным элементом "Asia". Для этого выполните следующие шаги:

Это откроет новое окно Консоли управления (MMC). Затем проследуйте в File (Файл) | Save As (Сохранить как) и сохраните свою Консоль управления. После этого данная новая Консоль управления может применяться участником команды Asia IT для управления вашим Организационным элементом "Asia". Она будет отображать в Консоли управления только Организационный элемент "Asia".

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

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