Как реализовать фильтрацию безопасности групповой политики

Самое вводящее в заблуждение свойство групповой политики — это ее название. Групповая политика — это просто не способ применения политик к группам! Вместо этого групповая политика применяется к отдельным учетным записям пользователей и учетным записям компьютеров путем связывания объектов групповой политики (GPO), представляющих собой наборы параметров политики, с контейнерами Active Directory (обычно подразделениями, но также доменами и сайтами), в которых находятся эти учетные записи пользователей и компьютеров. Таким образом, вопрос новичка относительно групповой политики обычно звучит так: «Как я могу заставить этот объект групповой политики применяться к этой группе?» Ответ на этот вопрос таков: внедрив фильтрацию безопасности.

Общие сведения о фильтрации безопасности

Фильтрация безопасности основана на том факте, что объекты групповой политики имеют связанные с ними списки управления доступом (ACL). Эти ACL содержат ряд ACE для разных субъектов безопасности (учетных записей пользователей, учетных записей компьютеров, групп безопасности и встроенных специальных удостоверений), и вы можете просмотреть ACL по умолчанию для типичного объекта групповой политики следующим образом:

1. Откройте консоль управления групповыми политиками (GPMC).
2. Разворачивайте дерево консоли, пока не увидите узел «Объекты групповой политики».
3. Выберите конкретный объект групповой политики в узле «Объекты групповой политики».
4. Выберите вкладку «Делегирование» на правой панели (см. рис. 1).

Рисунок 1. Просмотр списка управления доступом для объекта групповой политики Ванкувера с помощью вкладки «Делегирование»

Для более подробного просмотра записей ACE в этом ACL объекта групповой политики нажмите кнопку «Дополнительно», чтобы отобразить знакомый редактор ACL (рис. 2):

Рисунок 2: Просмотр ACL для Vancouver GPO с помощью редактора ACL

Очевидная разница между этими двумя представлениями заключается в том, что редактор ACL отображает разрешение «Применить групповую политику», а вкладка «Делегирование» — нет. Это связано с тем, что на вкладке «Делегирование» отображаются записи ACE только для принципов безопасности, которые фактически обрабатывают объект групповой политики, и это неявно означает, что для этих участников безопасности разрешение «Применить групповую политику» установлено на «Разрешить». В частности, если вы хотите, чтобы объект групповой политики обрабатывался субъектом безопасности в контейнере, связанном с объектом групповой политики, субъекту безопасности требуются как минимум следующие разрешения:

• Разрешить чтение
• Разрешить применение групповой политики

Фактические детали ACE по умолчанию для недавно созданного объекта групповой политики несколько сложны, если вы включаете расширенные разрешения, но вот основные сведения о фильтрации безопасности:

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

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

Использование фильтрации безопасности

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

Рис. 3. Пример структуры OU для офиса в Ванкувере

Предположим, что из пятнадцати пользователей, работающих в отделе продаж и маркетинга в Ванкувере, трое — это старшие сотрудники, у которых есть особые требования, например, доступ к определенному программному обеспечению, к которому другие сотрудники отдела не должны иметь доступа. Такое программное обеспечение может быть предоставлено им путем публикации его в разделе «Установка и удаление программ» с использованием объекта групповой политики установки программного обеспечения на основе политики пользователя. Проблема в том, что если вы свяжете этот объект групповой политики с OU Sales and Marketing Users, то все пятнадцать пользователей в отделе будут иметь к нему доступ через «Установку и удаление программ». Но вы хотите, чтобы только эта специальная группа из трех пользователей имела доступ к программному обеспечению, так что же вы делаете?

Вы можете создать еще одну OU под OU Sales and Marketing Users и назвать эту новую OU OU Senior Sales and Marketing Users. Затем вы можете переместить учетные записи трех старших сотрудников в эту новую организационную единицу, создать объект групповой политики для установки программного обеспечения и связать его с новой организационной единицей. Хотя этот подход будет работать, он имеет несколько недостатков:

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

Лучшее решение — оставить существующую структуру OU нетронутой и оставить всех пятнадцать пользователей Sales and Marketing в OU Sales and Marketing Users, создать объект групповой политики для установки программного обеспечения и связать его с OU Sales and Marketing Users (см. рис. 4), а затем использовать фильтрация безопасности для настройки ACL в объекте групповой политики установки программного обеспечения, чтобы гарантировать, что только три старших пользователя получают политику.

Рисунок 4: Объект групповой политики установки программного обеспечения для старших пользователей отдела продаж и маркетинга

Чтобы отфильтровать объект групповой политики установки программного обеспечения, чтобы только пользователи Боб Смит, Мэри Джонс и Том Ли получали его во время обработки политики, давайте сначала с помощью Active Directory Users and Computers создадим глобальную группу с именем Senior Sales and Marketing Users, в которую входят только эти три пользователя. в качестве членов (см. рис. 5):

Рисунок 5: Членство в глобальной группе Senior Sales and Marketing Users

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

Теперь вернитесь в консоль управления групповыми политиками, выбрав объект групповой политики установки программного обеспечения на левой панели, и на вкладке «Область» правой панели удалите специальное удостоверение «Прошедшие проверку» из раздела «Фильтрация безопасности», а затем добавьте старший специалист по продажам и маркетингу. Глобальная группа пользователей (рисунок 6):

Рисунок 6. Фильтрация объекта групповой политики таким образом, чтобы он был нацелен только на группу Senior Sales and Marketing Users

Вот и все, мы закончили! Теперь, когда политика обрабатывается для учетной записи пользователя, находящейся в подразделении Sales and Marketing Users, механизм групповой политики на клиенте сначала определит, какие объекты групповой политики необходимо применить к пользователю. Если пользователь является членом группы безопасности Senior Sales and Marketing Users, следующие объекты групповой политики будут применяться в следующем порядке (при условии, что мы нигде не использовали блокировку или принудительное применение):

1. Политика домена по умолчанию
2. Ванкувер GPO
3. Объект групповой политики по продажам и маркетингу
4. Объект групповой политики для пользователей отдела продаж и маркетинга
5. Старшие пользователи отдела продаж и маркетинга GPO

Однако, если пользователь является одним из других двенадцати (младших) сотрудников отдела продаж и маркетинга, то последняя политика выше (GPO для старших пользователей по продажам и маркетингу) не будет применяться к ним. Другими словами, опубликованное программное обеспечение будет доступно Бобу, Мэри и Тому только по желанию.

Сила фильтрации безопасности

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

Рисунок 7. В Торонто более простая структура OU, чем в Ванкувере.

Затем я мог бы сгруппировать учетные записи пользователей и компьютеров в Торонто в глобальные группы следующим образом:

• Пользователи ИТ-отдела
• ИТ-отдел Компьютеры
• Пользователи управления
• Компьютеры управления
• Пользователи отдела продаж и маркетинга
• Компьютеры для продаж и маркетинга

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

Рисунок 8: Использование групповой политики для управления пользователями в Торонто

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

Вывод

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