Давайте вспомним, чем характеризуется лес доменов:

• наличием общей схемы,

• общего контейнера конфигурации,

• единого Глобального каталога (GC),

• полных транзитивных доверительных отношений между доменами.

Это позволяет пользователям регистрироваться в пределах леса применяя свое основное имя (UPN), выполнять поиск ресурсов в GK и осуществлять к ним доступ в пределах всего леса. Администраторы же могут не заботиться о доверительных отношениях и легко управлять конфигурацией, что очень немаловажно.

Примечание:  UPN (user principal name) – основное имя пользователя. У каждой учетной записи есть «удобное» имя и называется она основным именем пользователя –UPN и это и есть учетная запись пользователя и еще в купе с именем домена  естественно, где эта учетная запись зарегистрирована и имеет смысл. Иногда UPN называют регистрационным именем пользователя или именем входа или логином от user login name.

Так сколько лесов создавать? Исходя из основного правила (смотри выше), слышу крики  - Only One!  (только один).  И вы правы! Именно в одном лесу пользователи работают с единым каталогом, задействуют все преимущества транзитивных доверительных отношений, а администраторы легко управляют всеми доменами. Однако существуют  ситуаций, когда  необходимо и мы вынуждены использовать несколько лесов. Примером может служить объединение нескольких предприятий партнеров, или приказ министра производить обмен информацией между самостоятельными предприятиями по горизонтали, но подчиняющимися по вертикали одному министерству, или покупка нашей фирмы другой фирмы с уже существующим лесом, ну не ломать же его. Да, их связывают тесные партнерские отношения, им часто надо обмениваться информацией. Но это еще не повод для того, чтобы предоставлять пользователям разных предприятий или партнерских фирм прозрачный доступ к своим ресурсам. Администраторы разных организаций могут не доверять друг другу, они могут не прийти к согласию в том, как лес может изменяться. В такой ситуации не обойтись без нескольких лесов.

Если быть более строгим в изложении, то перечислим ситуации, в которых введение нескольких лесов оправдано.

• Задачи сетевого администрирования выполняются несколькими самостоятельными группами, между которых нет абсолютного доверия.

• Организационные единицы в силу «политических» причин разделены на самостоятельные группы.

• Существует необходимость в разделенном ведении организационных единиц.

• Леса содержат различные схемы каталога, контейнеров конфигурации и глобального каталога (GC). В этом случае требуется через создание лесов изолировать их друг от друга.

• Требуется в целях безопасности ограничить область доверительных отношений между доменами и деревьями доменов.

Кажись все.

Конечно в идеале один лес – это хорошо, так как при создании лесов  вы сознательно идете на дополнительные издержки. Во-первых, новый лес — это минимум еще один домен, и управление им  так же ляжет на ваши плечи; во-вторых, это новые схема и конфигурация, которыми надо управлять. В-третьих, чтобы пользователь из одного леса осуществил доступ к ресурсам в другом лесу, нужны явные нстранзитивные доверительные отношения. Администраторы  должны сконфигурировать  доверительные  отношения  вместо  использования  встроенных.  Наконец, чтобы пользователи одного леса увидели в GC объекты другого леса Вы должны либо импортировать эти объекты и постоянно поддерживать их свежую версию, либо пользователи должны уметь искать объекты в другом лесу. Если какая-либо  информация должна  быть синхронизована  между  лесами,  то  это также  надо сконфигурировать.

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

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

В  технических  терминах  просто  определить,  кто  является владельцем  леса.  Группы Schema Admins (Администраторы  схемы), Enterprise Admins (Администраторы предприятия) и Domain Admins (Администраторы домена)  в корневом домене могут  быть  определены  как  владельцы  леса,  потому  что  они  управляют  теми  изменениями, которые могут быть сделаны в лесу. Это роли чисто технические, и люди в этих группах почти не имеют окончательных полномочий на то, будут ли на самом деле сделаны модификации к лесу.  Например, группа Schema Admins может изменять схему, но член группы Schema Admins обычно не имеет полномочий для принятия заключительного решения относительно того, будет ли запрос  на изменение схемы одобрен.

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

Это политика определяет то, какие изменения могут быть сделаны к конфигурации уровня леса  и  при  каких  обстоятельствах.  Существует  два  типа  изменений  леса:

• изменения  схемы  и

• изменения  раздела  конфигурации  каталога ( например,  добавление  или  удаление  доменов  и разделов приложений каталога, изменение конфигурации сайта).

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

Документ «политика  управления  изменениями  леса»   должна  быть  сформирована  прежде,  чем  вы  начнете развертывать Active Directory.  Она так же должна быт прописана в документе более высокого ранга такой как «Политика IT безопасности предприятия» в целом. На   предприятиях   с  разнообразными  и  обособленными  деловыми подразделениями пояснение этой политики может быть трудным делом и занять много времени, но  и  после  развертывания Active Directory делать  это  совсем  не  легче.  Если  деловые подразделения  не  смогут  договориться  о  политике  управления  изменениями  леса  перед  развертыванием, вы должны принять решение о развертывании нескольких лесов, что весьма «не очень»

 И это правда, так как знаю по собственному опыту какие стрессы  и скандалы вызывают изменения, внесенные в лесе или даже в отдельном домене, если нет хорошо проработанного   документа  такой как «Политика IT безопасности предприятия» и все вытекающие из него документов.

Продолжение следует....