Иван Семин, создатель IT-портала Pyatilistnik.org, пишет отличные инструкции — за что ему спасибо. Мне пригодился раздел про Делегирование (разрешения) — что происходит, если убрать из Security Filtering группу «Прошедшие проверку». Но материал слишком ценный, чтобы его урезать.
Как найти и диагностировать причины, из-за которых назначенная вами групповая политика не применяется к отдельному компьютеру, пользователю или целому организационному подразделению? Пройдём по всем этапам взаимодействия с GPO, разберём утилиты, которые должен уметь использовать каждый администратор, работающий с созданием и назначением политик. Материал пригодится как новичку, так и опытному администратору.
Почему Active Directory так популярна? Одна из причин — мощь групповых политик. Администраторы (и большинство людей в целом) любят, когда управление централизовано и автоматизировано. GPO позволяют массово настроить десятки, сотни или тысячи машин из одного места: подключить принтеры, прописать скрипты входа, раздать профили Wi-Fi и многое другое.
Типичная ситуация — администратор создаёт политику и привязывает её к нужному объекту, но изменений нет. Новички теряются и не знают, с чего начать поиск причины. Ниже — упорядоченный алгоритм действий, который поможет обнаружить проблему и вернуть применение политики в строй.
К чему применяется групповая политика (GPO)
Сначала — что делает GPO. Windows — это совокупность служб и ключей реестра; то, что вы меняете в графическом интерфейсе, чаще всего отражается изменениями в реестре. Отсюда вытекает простое наблюдение:
- реестр существует для объекта «компьютер»;
- и реестр существует для объекта «пользователь».
Именно эти две сущности — конечные объекты воздействия групповой политики. В Active Directory объекты пользователей и компьютеров находятся в двух типах папок:
- Контейнер — по сути обычная папка; к нему нельзя привязать GPO.
- Организационные подразделения (OU) — специальные контейнеры для группировки объектов. Именно к OU привязываются политики, чтобы применить их к пользователям и компьютерам. В интерфейсе OU визуально отличается — у неё есть дополнительный маркер на значке, как видно на скриншоте.
Алгоритм устранения проблем с GPO
Допустим, у нас есть GPO, прикреплённая к OU «Client Computers» — политика называется «Управление UIPI». Пользователь жалуется, что политика не сработала. С чего начинать проверку?
Первое — сверить, находится ли целевой объект (компьютер или пользователь) в том пути, на который назначена политика. Откройте «Управление групповой политикой» (GPMC), найдите нужную GPO и посмотрите вкладку «Область (Scope)» — там видно, к каким OU привязана политика. В моём примере путь выглядит как root.pyatilistnik.org/Client Computers.
Поскольку AD — иерархия, OU могут быть вложены. Объект может находиться глубже в дереве, и вы сразу его не увидите. Используйте поиск в Active Directory: выберите «Найти» → Computers и введите имя, например w10-cl01. В результатах щёлкните по объекту и перейдите на вкладку «Объект», чтобы увидеть «Каноническое имя объекта» — это путь в AD. Сверьте его с областью применения GPO, чтобы понять, попадает ли объект под действие политики.
Далее проверьте, включена ли сама связь GPO с целевым OU. В GPMC щёлкните правой кнопкой по политике и убедитесь, что опция «Link enabled» отмечена; на вкладке «Область» в столбце «Связь задействована» должно стоять «да».
Следующий момент — состояние самой политики. Откройте вкладку «Сведения» в свойствах GPO и посмотрите «Состояние GPO». По умолчанию стоит «Включено» — тогда политика применяется как к пользователям, так и к компьютерам. Но может быть установлено одно из значений:
- Параметры конфигурации компьютера отключены (Computer configuration settings disabled)
- Параметры конфигурации пользователя отключены (User configuration settings disabled)
- Все параметры отключены (All setting disabled) — тогда политика не будет применяться вовсе
Это делается для оптимизации: если GPO содержит только пользовательские настройки, нет смысла пытаться применять её к компьютеру. Но ошибочное выключение нужной секции легко приведёт к тому, что политика не сработает там, где нужно.
Как я уже говорил, OU иерархичны — политика, привязанная к вышестоящему OU, распространяется на нижестоящие. Но если на дочерней OU включена опция «Block Inheritance», политики сверху применяться не будут. Найдите OU, щёлкните правой кнопкой и убедитесь, что пункт «Блокировать наследование» не установлен.
Эта настройка помечается характерным значком с восклицательным знаком — её используют, чтобы изолировать OU от политик, приходящих сверху.
Проверка прав на политику
У каждой GPO есть ACL — файл доступа. Это позволяет тонко управлять тем, кто и как может получить настройки из политики. В GPMC на вкладке «Область» смотрите секцию «Фильтры безопасности» — там перечислены пользователи, компьютеры и группы, к которым применяется политика. Возможные типы записей:
- Пользователь
- Компьютер
- Группа безопасности
По умолчанию здесь стоит группа «Прошедшие проверку (Authenticated Users)». В неё входят все доменные пользователи и компьютеры.
Если в фильтре указана другая группа или отдельные записи, убедитесь, что целевой объект входит в неё. Важно: в 2014 году Microsoft изменила порядок чтения GPO — теперь в ACL для корректной работы должна присутствовать группа «Компьютеры домена» или «Прошедшие проверку» с правом чтения. Когда вы удаляете «Прошедшие проверку» из Security Filtering, эта группа исчезает и из вкладки «Делегирование» — в результате компьютеры могут потерять право читать GPO.
!!! Чтобы пользовательские параметры успешно применялись, компьютеры должны иметь разрешение на чтение GPO на контроллере домена. Удаление группы «Прошедшие проверку» может остановить обработку политик для пользователей. Добавьте группу «Authenticated Users» или «Domain Computers» с правом Read (не менее). (см. https://support.microsoft.com/en-us/kb/316622)
Перейдите на вкладку «Делегирование» и проверьте: присутствует ли «Authenticated Users» или «Domain Computers» и стоит ли для них право «Чтение». Если групп нет — добавьте одну из них: кнопка «Дополнительно» → «Добавить» → выберите «Прошедшие проверку».
Убедитесь, что для добавленной записи отмечено право «Чтение».
Проверьте также, нет ли явно выставленных запретов (Deny) для нужного объекта — в моём примере это W10-CL03. Если есть — снимите их.
Особое внимание — группе «КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)»: она влияет на репликацию политики между контроллерами. Если в папке SYSVOL на других контроллерах политика отсутствует, проверьте права у этой группы.
Ещё один фильтр — WMI. Если к GPO прикреплён WMI-фильтр, а объект ему не соответствует, политика не применится. Проверьте раздел WMI-filters: возможно, ваш ноутбук в примере соответствует фильтру «для ноутбуков», а стационарный ПК — нет. Ниже показано, как на клиенте увидеть, что исключение произошло из-за WMI-фильтра.
Инструменты диагностики групповой политики
Мы пробежались по основным местам, где может прятаться проблема, но есть ещё инструменты, которые помогут получить ясную картину и быстро локализовать причину.
Главные утилиты для проверки применяемых политик:
- Командная утилита gpresult
- rsop (Resultant Set of Policy)
- Моделирование политик в оснастке gpmc.msc
- Просмотр результатов групповой политики через GPMC
Диагностика GPO через gpresult
Gpresult — первое, что нужно запускать на клиенте, чтобы понять, на каком этапе политика «теряется». Откройте cmd от имени администратора и выполните:
gpresult /r /scope:user (Для пользователя) gpresult /r /scope:computer (Для компьютера) Gpresult /r /z (Полный отчет) Gpresult /r /z > c:\gpresult.txt (Экспорт в файл)
В моём кейсе политика «Управление UIPI» привязана к компьютеру