Разбираем путаницу в модели OU

Меня никогда не перестает поражать, как сильно различаются советы по структуре OU в определенной Active Directory. Хотя OUs были одним из компонентов Active Directory, которые были впервые представлены в Windows 2000 почти десять лет назад, кажется, все еще отсутствует четкое руководство о том, как их использовать. Если вы начнете поиск информации о конструкции OU в интернете, то найдете там массу противоречивой информации даже среди публикаций компании Microsoft.

Отчасти я понимаю, почему вся эта противоречивая информация существует. Active Directory создана, чтобы быть крайне гибкой в своей структуре. Будучи таковой, OUs являются одним из компонентов Active Directory высшего уровня, и они тоже по природе своей очень гибкие. Если совместить эту гибкость с тем фактом, что каждый администратор имеет свой способ работы, причины существования всей этой противоречивой информации становятся очевидными.

Прежде чем начать

Прежде чем я начну говорить о конструкции OU, я хочу обратить ваше внимание на то, что информация, которую я собираюсь вам здесь предоставить – это лишь совет, и ничего более. Как я уже говорил, существует масса противоречивой информации о том, как OUs нужно организовывать. По этой причине вы можете относить или не относить те советы, которые я собираюсь вам дать, к лучшей практике в отрасли, так как я не уверен, что по данной теме (построение OU) вообще существует прописная лучшая практика. Итак, совет основан на моем личном опыте работы с Active Directory с момента ее появления в Windows 2000.

Моя философия построения OU

Когда дело доходит до конструкции Active Directory, я использую подход чем меньше тем лучше. Хотя и существуют ситуации, требующие создания большого количества OUs, я стараюсь придерживаться максимально простых конструкций, и по возможности ограничивать Active Directory использованием одной OU. Конечно, далеко не все используют такой подход.

Я помню, как посещал семинар на TechEd пару лет назад, на котором выступающий пытался продемонстрировать разносторонность Active Directory. В этой модели, OUs использовались практически как заменители доменов. Active Directory была настроена так, что в ней были различные группы пользователей, каждая из которых располагалась в собственной OU. Также, вместо того чтобы создавать ресурсный домен, выступающий создал OUs для различных групп компьютеров. На самом деле практически все располагалось в собственной OU. После этого я несколько раз встречал такие модели в реальности.

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

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

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

Я читал различные статьи, в которых говорилось, что необходимость в нескольких групповых политиках является еще одной веской причиной создания нескольких OUs, и для некоторых ситуаций это действительно так. Следует помнить, что OU – это самый высокий уровень, на котором групповая политика может быть применена, но это не единственная область, в которой можно применять групповую политику. Групповые политики можно также применять на сайте, в домене, на уровне локального компьютера иерархии Active Directory.

На мой взгляд, одной из причин чрезмерного использования OUs является то, что многие администраторы полагают, что когда групповая политика применяется к сайту или домену, она применяется ко всем объектам этого сайта или домена. Обычно это так, но у вас есть возможность создания групповой политики, которая будет применима только для определенного подмножества сайта, домена или даже OU.

Если вы посмотрите на рисунок A, вы увидите, что я открыл Active Directory Users and Computers, правой клавишей нажал на домене и выбрал опцию свойства из появившегося меню, чтобы открыть страницу свойств домена. Если вы посмотрите на вкладку «Групповая политика» этой страницы свойств, вы увидите, что здесь есть опция назначения нескольких групповых политик для домена. Обычно, когда вы это делаете, политики являются кумулятивными по природе. Политики сочетаются вместе из результирующей политики. Обратите внимание, что на рисунке показана кнопка свойств, которую вы можете нажать после выбора отдельной групповой политики. Когда вы нажимаете эту кнопку, Windows отображает страницу свойств этой групповой политики. Эта страница свойств содержит вкладку «Безопасность», которую вы можете использовать для присвоения прав политике. Можно предотвратить применение политики к определенным группам пользователей, установив эксплицитный отказ. Используя этот метод, вы можете разделять групповые политики, чтобы применять их к различным группам пользователей и компьютеров без необходимости создавать дополнительные OUs

Увеличить рисунок

Рисунок A: Вы можете использовать эксплицитный отказ, чтобы запретить применение групповой политики к определенной группе пользователей или компьютеров.

Сейчас вы, возможно, думаете, что я имею против создания нескольких OUs. Есть пара причин, в силу которых я стараюсь не использовать несколько OUs, если в них нет необходимости. Возможно, это просто лень с моей стороны, но первая причина, по которой я стараюсь использовать одну OU в модели Active Directory, заключается в том, что наличие нескольких OUs склонно усложнять LDAP запросы. Это особенно применимо в том случае, когда вы создаете вложенную (гнездовую) структуру OU. К тому же такая сложная структура практически не имеет никакого эффекта для конечных пользователей. В конце концов, сколько из ваших конечных пользователей вообще знают, что такое LDAP запрос? Суть в том, что создание чрезмерно сложной структуры OU может значительно осложнить вам работу.

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

Заключение

Как я уже говорил, не существует правильного или неправильного способа создания модели Active Directory. Преимуществом Active Directory является ее гибкость. Windows облегчает задачу создания Active Directory, состоящей из одной OU. Если со временем вы осознаете, что эта модель больше не подходит, вы можете с легкостью создать дополнительные OUs.