Групповая политика не применяется на клиентском компьютере

В этой обзорной статье я постараюсь разобрать типовые причины, из-за которых та или иная групповая политика может не применяться к подразделению (OU) или конкретному компьютеру / пользователю. Я думаю эта статья будет полезна как новичкам, так и профессионалам групповых политик AD для понимания принципов работы и архитектуры GPO. В первую очередь в статье я расскажу о возможных проблемах применения GPO, связанные с настройками самих политик на уровне домена, а не о траблшутинге применения GPO на клиентах. Практически все настройки, описанные в статье, выполняются в консоли редактора доменных групповых политик — Group Policy Management Console (GPMC.msc).

Область действия (scope) GPO

Если некой параметр политики не применятся на клиенте, проверьте область действия (scope) групповой политики. Если вы настраиваете параметр в секции Конфигурация компьютера (Computer Configuration), значит ваша групповая политика должна быть привязана к OU с компьютерами. Соответственно, если настраиваемый параметр относится к Конфигурация пользователя (User configuration).

Также проверьте, что объект, к которому вы пытаетесь применить политику находится в нужном OU с компьютерами или пользователями. Можно воспользоваться поиском по домену. OU, в котором находится объект содержится на вкладке Object в консоли ADUC.

Т.е целевой объект должен находится в OU, на который назначена политика (или во вложенном контейнере).

Фильтр безопасности GPO

Проверьте значение фильтра безопасности политики (Security Filtering). По-умолчанию на всех новых объектах GPO в домене присутствуют разрешения для группы «Authenticated Users«. Эта группа включает в себя всех пользователей и компьютеры домена. Это означает, что данная политика будет применяться на всех пользователях и ПК, которые попадают в область ее действия.

Если вы решили изменить этот фильтр безопасности, чтобы политика применялась только к членам определенной группы безопасности домена (или конкретным пользователям/ компьютерам), удалив группу Authenticated Users, убедитесь, что целевой объект (пользователь или компьютер) добавлен в эту группу AD. Также проверьте, что для группы, которую вы добавили в Security Filtering на вкладке GPO -> Delegation -> Advanced в списке разрешений присутствуют права Read и Apply group policy с полномочиями Apply.

Если вы используете нестандартные фильтры безопасности политик, проверьте, что для целевых групп нет явного запрета на применение GPO (Deny).

WMI фильтры GPO

В групповых политиках можно использовать специальные WMI фильтры. Это позволяет применить политику к компьютерам на основании некоторого WMI запроса. Например, мы можете создать WMI фильтр GPO для применения политики только к компьютерам с определенной версией Windows, к ПК в определенной IP подсети, только к ноутбукам и т.д.

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

gwmi -Query ‘select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"‘

Если запрос возвращает любые данные, значит WMI фильтр применится к этому компьютеру.

Статус групповой политики

Проверьте статус групповой политики, перейдя в консоли GPMC.msc в свойствах политики на вкладку Details. Обратите внимание на значение в поле GPO Status.

Как вы видите, доступно 4 варианта:

• All setting disabled – все настройки политики отключены (не применяются);
• Computer configuration settings disabled – не применяются настройки из параметров GPO компьютера;
• User configuration settings disabled – не применятся настройки пользовательских политик;
• Enabled – все настройки политики применяются к целевым объектам AD (значение по –умолчанию).

Делегирование GPO

На вкладке политики Delegation указаны разрешения, настроенные для данной групповой политики. Здесь можно увидеть каким группам даны права на изменения настроек GPO, а также на разрешение или запрет применения политики. Вы можете предоставить права на управление GPO из этой консоли или с помощью мастера делегирования в ADUC. Кроме того, наличие строки доступа для Enterprise Domain Controllers определяет возможность репликации данной политики между контроллерами домена Active Directory (это нужно иметь в виду при наличии проблем с репликацией политики между DC). Обратите внимание, что права на вкладке Delegation соответствуют NTFS правам, назначенным на каталог политики в папке SYSVOL

Наследование групповых политик

Наследование это одна из основных концепции групповых политик. Политики верхнего уровня по-умолчанию применяются ко всем вложенным объектам в иерархии домена. Однако, администратор может заблокировать применение всех наследованных политик на определенный OU. Для этого в консоли GPMC нужно щелкнуть ПКМ по OU и выбрать пункт меню Block inheritance.

Организационные подразделения с отключенным наследованием политик в консоли отображаются с синим восклицательным знаком.

Если политика не применяются на клиенте, проверьте, не находится ли он в OU с отключенным наследованием.

Имейте в виду, что доменные политики, для которых включено свойства “Enforced”, применяются даже на OU с отключённым наследованием (наследованные политики, которые применяются к контейнеру доступны на вкладке Group Policy Inheritance).

Область действия и порядок применения групповых политик (LSDOU)

Чтобы запомнить особенности порядка применения групповых политик в домене, нужно запомнить аббревиатуру LSDOU. Это аббревиатура позволяет запомнить порядок применения GPO:

1. Локальные политики компьютера (Local), настроенные через gpedit.msc (при некорректной настройке их можно сбросить);
2. Групповые политики уровня сайта (Site);
3. Групповые политики уровня домена (Domain);
4. Групповые политики уровня организационного подразделения (Organizational Unit).

Последние политики имеют наивысший приоритет. Т.е. если вы включили некий параметр Windows на уровне политики домена, но на целевом OU данный параметр отключается другой политикой – это означает, что нужный параметр в результате будет отключен на клиенте (выиграет ближайшая политика к объекту в иерархии AD).

При использовании параметра Forced у GPO выигрывает та, политика находится выше в иерархии домена (например, при включении Forced у политики Default Domain Policy, она выигрывает у всех других GPO).

Кроме того, администратор может изменить порядок обработки политик (Link Order) в консоли GPMC. Для этого нужно выбрать OU и перейти на вкладку Linked Group Policy Objects. В списке содержаться список GPO, которые применяются к данной OU с указанием приоритета. Политики обрабатываются в обратном порядке (снизу-вверх). Это означает что политика с Link Order 1 выполнится последней. Вы можете изменить приоритет GPO с помощью стрелок в левом столбце, передвинув ее выше или ниже в списке.

GPO Link Enabled

У каждого объекта GPO, который привязан к организационному контейнеру AD вы можете включить или отключить связь (применение политики). Для этого нужно включить или отключить опцию Связь включена (Link Enabled) в меню политики. Если связь для политики отключена, ее иконка становится бледной. При отключении связи политика перестает применяться к клиентам, но ссылка на объект GPO не удаляется из иерархии. Вы можете активировать данную связь в любой момент.

Замыкание групповой политики

При включении опции Режим замыкания групповой политики (Loopback Processing mode) вы можете применить к компьютеру настройки, которые содержаться в секции GPO с настройками пользователями. Например, если вы примените к OU с компьютерами политику, в которой настроены параметры в секции User Configurations, эти политики не будут применены к пользователю бзз использования замыкания. Режим Loopback Processing включается в разделе Computer Configuration -> Administrative Templates -> System -> Group Policy -> Configure user Group Policy Loopback Processing mode.

У этой политики есть два возможных значение:

Режим Merge (слияние) – к компьютеру применяться GPO основанные на расположении пользователя, а потом GPO, привязанные к компьютеру. При возникновении конфликтов между политиками OU пользователя и OU компьютера, политика в компьютер будет иметь более высокий приоритет

Диагностика применения GPO на стороне клиента

Вы можете провести диагностику применения групповых политик на стороне клиента с помощью утилит gpresult, rsop.msc и журнала событий Windows. При использовании Event Viewer нужно использовать фильтр по источнику GroupPolicy (Microsoft-Windows-GroupPolicy), а также в журнале Application and Services Logs -> Microsoft -> Windows -> Group Policy -> Operational.

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

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

Почему не применяется групповая политика, решаем за минуту

Почему не применяется групповая политика, решаем за минуту

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз я вам показал, как я делал досрочное погашение ипотеки Сбербанка, поделился свои жизненным опытом. Сегодня я хочу вас научить, как находить и диагностировать причины, по которым у вас может не применяться назначенная вами групповая политика к компьютеру или пользователю или целому организационному подразделению. Мы рассмотрим все этапы, через которые проходит происходит взаимодействие с GPO. Разберем утилиты, которыми должен владеть системный администратор в задачи которого входит создание и назначение политик. Уверен, что данный пост будет вам полезен и интересен.

За, что Active Directory от Microsoft получила такую популярность? Одним из ответов на данный вопрос, будет функционал групповой политики. Все администраторы, как и большинство современных людей, существа очень ленивые и любят, когда все централизованно управляется и по возможности автоматизированно. Именно объекты GPO, позволяют производить настройки десятков, сотен и тысяч компьютеров, из одного места и практически по всем направлениям, например добавление принтеров, скриптов входа, профилей WiFi и многое другое.

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

К чему применяется групповая политика (GPO)

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

• что реестр есть как для объекта компьютер
• и реестр есть для объекта пользователь

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

1. Это контейнер – по сути простая папка, важно, что к ней нельзя применять объекты групповой политики.
2. Второй тип, это организационные подразделения (OU) – это специальные папки для объединения объектов AD по принципам. Именно с OU связываются объекты групповой политики, для применения их к компьютерам и пользователям. Внешне контейнер отличается от организационной утилитой, тем что у OU, есть дополнительная лычка на значке, это показано на скриншоте.

Алгоритм устранения проблем с GPO

Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение "Client Computers". Политика называется "Управление UIPI". По какой-то причине пользователь жалуется, что она у него не применилась.

Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке "Управление групповой политикой" найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке "Область (Scope)", ее еще называют областью действия политики. В моем случае, это путь root.pyatilistnik.org/Client Computers.

Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле "Найти" компьютеры и в имени указываем w10-cl01, после чего нажимаем "Найти". В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку "Объект", где смотрим "Каноническое имя объекта", по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.

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

Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку "Сведения" на нужной GPO. Нас интересует строка "Состояние GPO". По умолчанию там стоит значение "Включено", означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:

• Параметры конфигурации компьютера отключены (Computer configuration settings disabled)
• Параметры конфигурации пользователя отключены (User configuration settings disabled)
• Все параметры отключены (All setting disabled) – запретит применение политики для любого объекта

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

Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.

Проверка прав на политику

Объекты групповой политики, так же имеют свой ACL (лист доступа), это означает, что вы можете более тонко настраивать к каким объектам применяется данная политика. В редакторе "Управление групповой политикой" выберите ваш GPO. На вкладке "Область" найдите раздел "Фильтры безопасности", он отображает к каким объектам применяется политика. Данный фильтр безопасности может включать объекты:

• Пользователь
• Компьютер
• Группа безопасности

Если у вас тут выставлена другая группа или отдельные записи, то убедитесь, что нужный объект состоит в данном ACL. Хочу отметить, что если даже нужный объект присутствует в списке фильтра безопасности, то это не означает, что политика к нему применяется и тут дело все в том, что в 2014 году Microsoft изменила принцип чтения политики, таким образом, что у вас в делегированном фильтре безопасности обязательно должна присутствовать группа "Компьютеры домена" или "Прошедшие проверку" у которой должны быть прав на чтение политики. Вся соль в том, что когда вы удаляете группу "Прошедшие проверку" из фильтра безопасности, она удаляется и из вкладки делегирование.

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

Удостоверьтесь, что выставлена галка "Чтение".

Тут же убедитесь, что нет запретов на нужный вам объект, в моем примере, это W10-CL03. Если есть снимите.

Обратите внимание на группу "КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)" данная группа определяет, будет ли происходить репликация данной политики на другие контроллеры или нет, так что если политика отсутствует в папке SYSVOL на других контроллерах, то проверьте права у данной группы.

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

Инструменты диагностики групповой политики

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

Существуют три инструмента, которые вам покажут информацию, о применяемых политиках на объекты:

• Утилита командной строки gpresult
• Утилита rsop
• Моделирование групповой политики в оснастке gpmc.msc
• Результаты групповой политики

Диагностика GPO через gpresult

Gpresult первое средство, которое позволит системному администратору определить на каком этапе есть проблемы с выполнением GPO. Откройте на клиентском компьютере или ноутбуке командную строку от имени администратора и введите команду:

В моем примере у меня есть политика для компьютера "Управление UIPI", поэтому я воспользуюсь gpresult для компьютера. Выполнив gpresult /r /scope:computer я вижу, что моя политика не применилась и числится в списке "Следующие политики GPO не были применены, так как они отфильтрованы". Фильтрация отказано в доступе (Безопасность). Из этого видно, что у компьютера просто нет прав на чтение политики.

Так же в логах Windows вы можете обнаружить событие с кодом ID 5313:

Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (безопасность)

А вот пример 5313, но с уже WMI фильтром:

Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (фильтр WMI)

Я для исключаю его из запрета применения и пробую новую попытку применения политики. Я делаю для начала обновление групповой политики через gpupdate /force и затем снова выполняю команду gpresult /r /scope:computer, где теперь вижу, что политика не применилась из-за WMI фильтра. Теперь уже понятно куда копать.

Получение данных GPResult с удаленного компьютера GPResult /s server01 /r, поможет администратору или технической поддержке собрать диагностические данные. Аналогичные действия вы можете выполнять и для пользователя, тут все аналогично. Теперь воспользуемся утилитой RSOP. Откройте окно выполнить и введите rsop.msc.

Начнется сбор применяемых политик.

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

Но это не удобно и мы можем совместить две утилиты gpresult и Resultant Set of Policies (RSoP), получив выгодный симбиоз. В командной строке введите:

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

Результаты групповой политики

В оснастке GPMC есть возможность посмотреть какие политики применяются к нужному объекту групповой политики. Данный мастер называется "Результат моделирования групповой политики". Щелкаем по нему правым кликом и открываем мастер.

Выбираем нужный компьютер, к которому мы хотим проверить применение политики.

Если в момент добавления компьютера у вас выскочит ошибка "Сервер RPC-недоступен", то проверьте, что у вас запущена на нем служба WMI и в брандмауэре открыты порты для подключения к ней.

Так как я проверяю GPO для компьютера, то мне нет смысла отображать политику для пользователей.

Нажимаем далее. У вас появится отчет. Раскрыв его на вкладке "Сведения" вы увидите, какие политики применены, а какие нет.

Раскрыв подробнее политику, которая не смогла примениться, я вижу, что причиной всему был WMI фильтр.

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

На первом шаге мастера моделирования групповой политики, будет простое уведомление, что к чему, нажимаем далее.

Далее вам будет предложен выбор, дабы указать нужный контроллер домена.

Теперь выбираем нужную OU, для которой мы будем тестировать групповую политику. Делается все через кнопку "Обзор". Я выбрал "Client Computers"

На следующем шаге мастера моделирования групповой политики, вам предоставят сэмулировать таки параметры:

• Медленное сетевое подключение, меньше 500 кб/с
• Обработка петлевого адреса (Замыкание групповой политики – loopbacl policy) – это опция когда вы применяете для OU в которой находятся компьютеры, например терминальные сервера, политики для пользователя. Делается это для того, чтобы политики применяемые к пользователю на его рабочей станции или другом сервере от тех, что в данной OU. Можете подробно почитать, что такое замыкание групповой политики.
• Выбор сайта.

Указываем в какой группе находится наш объект, к которому будет применяться политика.

далее вы можете применить любой из фильтров WMI, который вы хотите тестировать.

В итоге мы получаем результат моделирования групповой политики, тут можно посмотреть, что применилось, что нет.

После установки системы Windows 7 Professional (х64) на одну из пользовательских машин, появились проблемы с применением групповых политик, на данной машине. В роли домен контроллера выступает Windows Server 2008 R2, ошибок в его работе не наблюдается, да и все остальные пользователи сети, не испытывают подобных затруднений с применением групповых политик.

При тестировании результатов применения групповых политик на проблемной машине, видно что часть групповых политик применяется, а часть нет. Групповые политики которые не применяются помечены как Inaccessible (Недоступные).

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

Групповые политики которые не применялись на проблемной машине и имели статус Inaccessible (Недоступные), имеют права доступа только из определенных групп.

А групповые политики которые успешно были применены на проблемной машине, имели права доступа для всех пользователей прошедших проверку.

Как выяснилось в итоге, корнем всех этих бед, стало выпущенное в рамках бюллетеня MS16-072 от 14 июня 2016 года, обновление безопасности для групповых политик, KB для различных ОС: KB3159398, KB3163017, KB3163018, KB3163016. Данное обновление призвано закрыть уязвимости в безопасности применения групповых политик.

Таким образом если удалить из групповой политики, права доступа для группы Прошедшие проверку (Authenticated Users), то на машине с установленным обновлением из бюллетеня MS16-072, мы заблокируем доступ к групповой политики.

Решить данную проблему можно несколькими способами:

1. На машине, удалить установленное обновление из бюллетеня MS16-072.
2. Для всех групповых политик, у которых используется фильтрация безопасности по пользовательским группам, делегировать группу Компьютеры домена (Domain Computers) с правами Read.

Удалять установленные обновления на клиентских машинах, не целесообразно. Поэтому действенным решением данной проблемы, является метод добавления в групповые политики с фильтрацией безопасности по пользовательским группам, группу Компьютеры домена (Domain Computers) с правами чтения. Таким образом, у компьютеров домена появится право на чтение этой политики.

Посмотреть в каких групповых политиках отсутствует группа доступа Прошедшие проверку (Authenticated Users), можно выполнив команду в Powershell: