Проектирование эффективной структуры подразделений

Не стоит недооценивать важность (и сложность) процедуры проектирования надлежащей структуры подразделений. Специалисты по ИТ склонны впадать в крайности: они либо слишком много внимания уделяют структуре подразделений, либо вообще о ней не думают. И в том, и в другом случае это чревато возникновением проблем в модели Active Directory®.

Если вы слишком много внимания уделяете структуре подразделений, вы забываете о других аспектах проектирования Active Directory: о планировании топологии сайтов, о распределении размеров контроллеров доменов. С другой стороны, если отодвинуть планирование подразделений на второй план, страдают групповая политика и делегирование.

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

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

При проектировании структуры подразделений следует помнить вот такое уравнение: простота + адаптируемость = поддерживаемость. Слишком простая структура плохо адаптируется, и ее приходится часто менять. Слишком легко адаптируемая структура, в которой предусмотрено слишком много подразделений, оказывается чересчур сложной.

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

1. Нужно ли создавать это подразделение, чтобы применить к его членам уникальный объект групповой политики (GPO)?
2. Нужно ли организовать доступ к объектам данного подразделения для какой-то конкретной группы администраторов?
3. Приведет ли создание нового подразделения к упрощению администрирования объектов, относящихся к нему?

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

Принцип 1. Групповая политика

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

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

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

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

Кроме того, с точки зрения оптимизации работы с объектами групповой политики структура подразделений не должна быть слишком сложной. Создаваемое подразделение всегда должно расширять схему наследования объектов групповой политики. Если оно содержит серверы, требующие применения такой же политики, что и к другим серверам, можно попытаться поместить объекты создаваемого подразделения в более широкую группу (подразделение «Серверы»), а уже в ней создать несколько подразделений для разных типов серверов (см. рис. 1). Это упростит применение политик, поскольку к каждому компьютеру, входящему во вложенное подразделение, будет применяться как политика для подразделения «Серверы», так и другие конкретные политики для конкретного типа серверов.

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

И наконец, практически всегда следует создавать разные подразделения для объектов-пользователей и объектов-компьютеров. По умолчанию объекты-пользователи и объекты-компьютеры размещаются в контейнерах, и поэтому объекты групповой политики нельзя связать с ними напрямую. Они привязываются в домене к контейнерам «Пользователи» и «Компьютеры», но если наследование нигде не блокировано, политики применяются ко всем пользователям и ко всем компьютерам домена. В Windows Server® 2003 можно при помощи средств rediruser.exe и redircomp.exe изменить стандарное расположение объектов-пользователей и объектов-компьютеров так, чтобы они размещались в созданных для них подразделениях.

Принцип 2. Делегирование

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

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

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

В этом случае есть два варианта. Во-первых, можно создать два отдельных подразделения и в одно из них поместить тех пользователей, для которых пароль менять можно, а в другое — тех, для кого менять пароль нельзя. Но в таком случае, если нужно будет изменить параметры делегирования для всех пользователей, их придется менять по отдельности. Кроме того, тут мы нарушаем правило, согласно которому не следует без нужды создавать лишние связи (см. рис. 2).

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

Будьте внимательны при работе с контейнером AdminSDHolder. Приведенные выше решения можно использовать в том случае, если те самые «особые» пользователи не принадлежат ни к одной группе администраторов («Администраторы домена», «Администраторы схемы», «Администраторы предприятия» и просто «Администраторы»), поскольку полномочия для указанных групп применяются иначе. Смысл в том, чтобы не предоставить полномочия администратора по ошибке.

Если вы создадите отдельное подразделение для администраторов, вы заметите, что полномочия, которые вы им выдаете, исчезают. Причина связана с контейнером AdminSDHolder. Это специальный контейнер, который применяет свой список управления доступом к каждую учетную записи администратора через указанный промежуток времени. В результате все связанные с делегированием изменения, внесенные в учетную запись администратора, отменяются — за исключением тех, которые были внесены в контейнер AdminSDHolder. Это означает, что не следует отделять учетные записи администраторов от всех остальных учетных записей для делегирования. А вот для целей групповой политики их действительно лучше разделить — тем более в Windows Server 2008, где можно настроить несколько политик паролей.

Принцип 3. Администрирование объектов

Каждое новое подразделение должно упрощать администрирование объектов. Часто объекты, сгруппированные в подразделения, проще изменять (если изменения касаются их всех). Оснастка «Пользователи и компьютеры Active Directory» позволяет изменять некоторые атрибуты сразу для нескольких объектов. Если вам часто приходится менять атрибут для целой группы объектов, их лучше объединить в подразделение.

Такой прием особенно удобен, если обновление выполняется при помощи сценария. Языки сценариев позволяют без труда перечислить все объекты, входящие в подразделение, и обработать их один за другим. Альтернативный вариант — отыскивать и изменять объекты по одному. Объединение объектов в подразделения с целью администрирования иногда позволяет сэкономить несколько часов в неделю.

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

Выбор модели

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

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

Плоская модель

Плоская модель называется так, потому что она действительно практически плоская. Есть несколько подразделений верхнего уровня, и большинство объектов содержится в них (см. рис. 4). Такая модель чаще всего встречается в небольших организациях, где отдел ИТ невелик, где подразделений мало, где пользователи исполняют несколько ролей одновременно. Обычно я рекомендую не использовать в иерархии подразделений более 10 уровней, хотя специалисты Майкрософт отмечали снижение производительность лишь при превышении предела в 15 уровней.

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

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

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

Географическая модель

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

Допустим, у вашей компании есть офисы в Атланте, Балтиморе и Сиэттле. С точки зрения делегирования хорошо, если в каждом офисе можно организовать отдельное управление пользователями и компьютерами. Но что произойдет в таком случае, если, допустим, пользователь из Сиэттла отправится в Балтимор на семинар и заблокирует свою учетную запись? Специалисты по ИТ в Балтиморе не смогут ему помочь, если у них не будет полномочий на доступ к его учетной записи. Когда в Балтиморе 8 часов утра, в Сиэттле еще только 5. Значит, пользователю придется прождать несколько часов, прежде чем в Сиэттле кто-то появится в офисе.

В ряде международных компаний применяется так называемый принцип «подсолнечника»: обращения в службу поддержки направляются в центр, расположенный в том часовом поясе, где звонок попадает в рабочее время. Ни в одном офисе служба поддержки не работает 24 часа в сутки, и тем не менее сотрудникам, работающим поздно вечером, может быть оказана необходимая помощь, к примеру по разблокированию учетной записи.

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

Географическую модель сложно реализовать на одном домене — из-за основных пронципов работы домена. Зачастую модель безопасности одного домена отличается от модели безопасности остальных. Это становится очевидным на примере корпоративных приложений, таких как Microsoft® Exchange.

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

Модель на основе типов

В модели на основе типов объекты классифицируются по назначению (см. рис. 6). Чем был последний созданный вами объект, учетной записью пользователя, учетной записью администратора или учетной записью службы? В модели на основе типов эти объекты обрабатываются по-разному.

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

Здесь наследование объектов групповой политики может пойти на пользу. Например, можно создать политику «Все пользователи», соотносящуюся с политиками, применяемыми ко всем объектам-пользователям. Кроме того, можно создать отдельную политику для учетных записей служб, основывающуюся на политике «Все пользователи». Такой подход гарантирует, что для учетных записей служб будет применяться такой же набор политик, что и для всех остальных учетных записей, а кроме них — дополнительные ограничения на вход в систему.

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

Этот подход в равной степени хорош с точки зрения объектов-компьютеров. Серверы и рабочие станции можно отделить друг от друга, что позволит применить к ним разные политики. Серверы можно дальше разделить по функциям (см. рис. 1). При такой схеме вы можете настроить политику верхнего уровня для подразделения «Серверы», которая будет распространяться на все серверы организации, и дополнительные индивидуальные политики для подразделений более низкого уровня.

Допустим, у вас есть учетная запись службы Microsoft Operations Manager (MOM). В многоуровневой модели вы можете создать объект групповой политики для MOM и применить его к подразделению, содержащему серверы MOM. Затем в созданном объекте групповой политики вы можете выдать службе MOM право на вход в систему в качестве службы. Оно будет применяться только к тем серверам MOM, которые входят в данное подразделение. На серверы MOM будет распространяться объект групповой политики, настроенный для более широкого подразделения «Серверы», но кроме него будет действовать еще и специализированный объект групповой политики, созданный непосредственно для подразделения MOM.

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

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

Документируйте только ту информацию, которая имеет отношение с структуре подразделений. Я твердо уверен в том, что у каждого документа должно быть свое предназначение. Очень часто в документах содержится так много ненужных сведений, что сложно докопаться до сути. Не стоит увлекаться документированием ради документирования. Так ли уж нужно вам записать количество объектов в каждом подразделении, зафиксировать каждый элемент списка управления доступом? Для документирования подразделения обычно достаточно указать следующие сведения:

• Название подразделения.
• Краткое описание.
• Имя человека, создавшего подразделение, или контактные данные человека, с которым можно связаться, чтобы получить дополнительную информацию или внести изменения.
• Дата и время создания.

Не затрудняйте обновление. Если, к примеру, обновление какого-то сложного документа Microsoft Word отнимает слишком много сил и времени, вы скорее всего перестанете вносить в него изменения. Если вы не вписали какую-то незначительную информацию, потому что знаете, что скоро будет более значительное изменение файла, то это не страшно. Но к сожалению, мы нередко просто забываем о подобных незначительных обновлениях или бесконечно откладываем их. Процесс обновления должен быть простым, он не должен вызывать приступов пессимизма. В большинстве случаев подойдет таблица Microsoft Excel® в несколько столбцов.

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

Автоматизируйте документирование. Вы можете создать сценарий, который будет записывать сведения о структуре подразделений в текстовый файл, таблицу Excel, файл HTML. Такой сценарий можно запускать по расписанию каждую ночь. Такой подход очень удобен, если вы используете поле описания подразделения. Содержимое поля переписывается в файл, и у вас всегда под руками имеется полная, обновленная документация по подразделению. Если при запуске сценария каждый раз создается новый файл, а не перезаписывается старый, можно вести учет изменений структуры подразделений.

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

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