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

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

ЦЕЛОВАТЬ

Первый и очевидный принцип — «Не усложняй, глупец!» или «KISS». В контексте планирования групповой политики это означает две вещи:

• Если один домен удовлетворит все потребности вашей компании, используйте только один домен. Причина проста в том, что количество объектов групповой политики (GPO), которые вам необходимо создать, примерно пропорционально количеству доменов в вашем лесу. Хотя привязка объекта групповой политики, находящегося в одном домене, к контейнеру (домену, сайту или организационной единице) в другом домене уменьшает общее количество объектов групповой политики, которые необходимо развернуть, это может оказать значительное влияние на производительность и, как правило, не должно выполняться.
  
• Старайтесь, чтобы структура вашей OU была относительно простой, например, максимум два или три уровня OU. Причина аналогична той, по которой вы должны свести количество доменов к минимуму: административные накладные расходы.

Итак, предположим, что вы начинаете разработку Active Directory с решения, что вы собираетесь предоставить нам один домен (см. рис. 1) с двумя или, может быть, тремя уровнями OU внутри него. Это хорошее место для начала. Что дальше?

Рисунок 1. По возможности используйте только один домен

Подразделения серверов

Групповая политика предназначена не только для управления рабочими столами; это также отлично подходит для блокировки серверов, чтобы обеспечить их безопасность и правильную работу. Под серверами я подразумеваю как рядовые серверы (включая файловые серверы, серверы печати, веб-серверы, DHCP-серверы и т. д.), так и контроллеры домена. Лучший способ заблокировать контроллеры домена — оставить их в подразделении «Контроллеры домена» по умолчанию и настроить объект групповой политики, связанный с этим подразделением. Это можно сделать двумя способами:

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

Какой подход лучше? Некоторые эксперты рекомендуют оставить объект групповой политики по умолчанию нетронутым, создать новый объект групповой политики и переместить его в начало порядка ссылок для объектов групповой политики, связанных с OU. Таким образом, если что-то пойдет не так позже, вы, по крайней мере, сохраните свой GPO по умолчанию и не тронете его. С другой стороны, если вы запустите новый мастер настройки безопасности (SCW) Windows Server 2003 с пакетом обновления 1 на контроллере домена, то в дополнение к другим изменениям он изменит определенные параметры в политике контроллеров домена по умолчанию, чтобы сделать ваш контроллер домена более безопасный. Так что любой подход работает нормально, но лично я предпочитаю второй подход.

А как насчет ваших рядовых серверов? Хитрость здесь заключается в том, чтобы понять, что различные роли рядового сервера в основном постепенно отличаются от базового (не имеющего роли) рядового сервера. Таким образом, хорошим подходом является создание ОП Рядовых серверов верхнего уровня, а затем добавление под ним дополнительных ОП для каждой роли (рис. 2):

Рисунок 2: Структура OU для рядовых серверов.

Преимущество этого подхода заключается в том, что теперь вы можете создать базовый объект групповой политики для рядовых серверов, который обычно защищает любой рядовой сервер и связать его с подразделением рядовых серверов. Таким образом, все рядовые серверы в дочерних подразделениях автоматически наследуют эту политику. Затем вы можете создать объект групповой политики «Серверы печати» и связать его с подразделением «Серверы печати», объект групповой политики «Файловые серверы» и связать его с подразделением «Файловые серверы» и т. д. Эти различные объекты групповой политики, связанные с дочерними подразделениями подразделения рядовых серверов, можно использовать для постепенного усиления безопасности для каждой роли сервера по сравнению с базовым усилением, обеспечиваемым объектом групповой политики рядовых серверов.

Вот совет: если вы хотите узнать больше об использовании описанного выше подхода для защиты серверов с помощью групповой политики, прочтите Руководство по безопасности Windows Server 2003, которое доступно в Центре загрузки Microsoft. В этом Руководстве содержатся потрясающие предложения о том, как защитить различные роли сервера, и его почти 300 страниц контента стоят того, чтобы их изучить. Если у вас нет времени читать все руководство, загляните в мой блог ITreader.net и нажмите «Групповая политика» в разделе «Темы», и вы найдете много полезной информации, которую я почерпнул из собственного чтения руководства, а также другие ресурсы Майкрософт.

Настольные и пользовательские подразделения

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

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

Затем вы должны попытаться создать свои подразделения по принципу отдела, а не по географическому местоположению. Таким образом, вы сможете более эффективно использовать делегирование, когда вам это нужно. Если вам необходимо иметь географические подразделения, сделайте их подразделениями верхнего уровня, а затем создайте дочерние подразделения под ними для каждого подразделения или отдела (рис. 3):

Рисунок 3: Типичная структура OU.

Затем создайте отдельные подразделения для учетных записей компьютеров и учетных записей пользователей (рис. 4). Таким образом, вы можете использовать отдельные подразделения для блокировки настроек компьютера и пользовательских настроек. Конечно, вы могли бы добиться того же, объединив учетные записи компьютеров и пользователей в одну организационную единицу, связав два объекта групповой политики с этой организационной единицей и отключив настройки компьютера в одной организационной единице и пользовательские настройки в другой организационной единице. Но хранение вашего компьютера и учетных записей пользователей в отдельных подразделениях облегчит вам устранение неполадок, когда групповая политика не работает так, как вы ожидали, а также снизит вероятность ошибок при настройке политики.

Рисунок 4. Используйте отдельные подразделения для компьютеров и учетных записей пользователей.

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

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