Проектирование структуры организационной единицы

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


Организационные единицы и проектирование Active Directory

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

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

Проектирование структуры OU

В большинстве компаний модель OU имеет большую гибкость. При этом следует учесть множество факторов.


Практический опыт. Структура компании и проектирование OU

Первой мыслью при создании структуры организационных единиц становится подражание организационной схеме компании. В некоторых случаях это работает, в некоторых — нет. Организационная схема компании обычно основана на деловых подразделениях без учета того, где фактически располагаются пользователи. Возможно, что члены деловых подразделений рассеяны по всему миру. Группировка этих пользователей в единственную OU может быть весьма неэффективной. Исследование структуры компании и ее организационной модели - это хорошая отправная точка для проектирования OU. Если компания централизована и иерархична, то структура OU, вероятно, отразит эту модель. Если компания представляет большую автономию деловым подразделениям или географическим местам, то проект OU должен отразить этот подход. При исследовании структуры компании исследуйте также структуру управления информационными технологиями (IT). В некоторых компаниях отдельным деловым подразделениям дается большая автономия для управления бизнесом по их собственному усмотрению, но ГГ-управле-ние может оставаться централизованным. В этом случае необходимо проектировать структуру OU, базируясь на структуре 1Т-управления, а не на структуре управления бизнесом.


Проект OU, основанный на делегировании администрирования

Одна из причин создания структуры OU заключается в возможности делегирования административных задач. Многие компании, которые соединили домены ресурсов Windows NT в единственный домен Active Directory, возможно, захотят делегировать административные задачи, которые обычно выполняли администраторы домена в домене ресурсов. Некоторые компании имеют несколько офисов с локальными сетевыми администраторами в каждом, и они, возможно, захотят делегировать администрирование каждому из этих офисов. Другие компании захотят делегировать определенную административную задачу. Например, дать одному или двум человекам в каждом отделе право сбрасывать пароли пользователей, а также изменять информацию для всех пользователей отдела.

Все это становится возможными путем создания структуры OU в Active Directory и последующим делегированием административного доступа. Возможно представление любого уровня административного доступа на уровне OU. Если вы создаете OU для отдаленного офиса, вы можете представить его администратору полное управление объектами этого офиса. Администратор может выполнять любую административную задачу в этой OU, включая создание дочерних OU и делегирова-
ние разрешений другим администраторам. Если вы создаете OU для каждого отдела, вы можете предоставить очень специфические права, типа права сбрасывания паролей, нескольким пользователям в отделе. Можно предоставить административные права, основанные на типах объектов в OU, например, администраторы отдела могут изменять учетные записи пользователя, но не объекты групп или компьютеров. В главе 9 содержится подробная информация о делегировании администрирования. Следует прочесть эту главу перед созданием проекта OU.

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

Проект 0U, основанный на проекте групповых политик

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

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


Создание проекта OU

Начните разрабатывать проект OU с организационных единиц высшего уровня. Их труднее модифицировать после развертывания из-за OU, расположенных ниже. OU высшего уровня должны основываться на чем-то неизменном: на географических регионах или деловых подразделениях.

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

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

На рисунке 5-11 показан проект OU для крупной компании. OU высшего уровня включает Domain Controllers OU (OU контроллеров домена) (все контроллеры домена расположены в этой OU) и OU администраторов уровня домена. OU высшего уровня могут включать OU службы
учетных записей для всех служебных учетных записей (Service Account), используемых в домене. Создание на высшем уровне OU для специальных учетных записей пользователей, таких как служебные учетные записи, упрощает их администрирование. OU высшего уровня могут включать OU серверов, если все серверы управляются централизованно. В дополнение к этим административным OU могут быть также OU высшего уровня, основанные на географии корпорации. Организационные единицы высшего уровня, основанные на географии, могут использоваться для делегирования административных задач.


Рис. 5-11. Типовая структура OU

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

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