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

Обновлено: 05.07.2024

В этой статье данная статья позволяет решить проблему, из-за которой Windows 7 Клиенты периодически не применяют групповой политики при запуске.

Применяется к: Windows 7 Пакет обновления 1
Исходный номер КБ: 2421599

Симптомы

Windows 7 клиентов периодически не удается обработка групповой политики при запуске или перезагрузке. В журнале событий System регистрируются следующие события:

Ошибка 9/9/2010 2:43:29 PM NETLOGON 5719 Ошибка 9/9/2010 2:43:31 PM GroupPolicy 1055

Причина

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

Следующая последовательность событий отражает условие:

Information <DateTime> EventLog 6006 указывает на отключение системы
Информация e1kexpress 33 указывает на то, что установлена связь сетевого <DateTime> подключения с <speed/duplex>
Information <DateTime> EventLog 6005 указывает, что служба журнала событий запущена
Информация Dhcp-Client 50036 указывает на начало клиентской службы <DateTime> dhcp
Ошибка NETLOGON 5719 указывает, что netlogon не может достичь ни одного <DateTime> из контроллеров домена
Ошибка <DateTime> GroupPolicy 1055 указывает на сбой обработки групповой политики
Information <DateTime> GroupPolicy 1503 указывает на успешность обработки групповой политики

Это также можно подтвердить с помощью netlogon журналов:

Решение

Чтобы решить проблему, можно установить значение реестра, чтобы отложить применение групповой политики:

Откройте редактор реестра.

Расширь следующую подкайку: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Щелкните правой Winlogon кнопкой мыши , указать на New, а затем выберите значение DWORD.

Чтобы назвать новую запись, введите GpNetworkStartTimeoutPolicyValue и нажмите кнопку ENTER.

Щелкните правой GpNetworkStartTimeoutPolicyValue кнопкой мыши, а затем выберите Изменение.

В базовой статье выберите десятичной знак.

В поле Данных Значения введите 60 и выберите ОК.

Выйти из редактора реестра и перезапустить компьютер.

Если сценарий запуска групповой политики не работает, увеличите значение GpNetworkStartTimeoutPolicyValue записи реестра.

Дополнительная информация

Указанное значение должно быть достаточно длинным, чтобы обеспечить подключение. В течение периода ожидания Windows каждые две секунды проверяет состояние подключения и будет продолжать работу с запуском системы, как только подключение будет подтверждено. Поэтому рекомендуется перебиваясь на высокой стороне. Если система отключена законно (например, отключенный сетевой кабель, off-line server и так далее), Windows будет приостановлено на весь период ожидания.

Она также может быть определена с помощью групповой политики:

Расположение политики: > политики > шаблоны администратора > System > Group Policy Setting Name: Клавиша времени ожидания ожидания обработки политики запуска: HKLM\Software\Policies\Microsoft\Windows\System!GpNetworkStartTimeoutPolicyValue

Если вы определите параметр групповой политики, он переопределит параметр вручную. Если параметр ручной и групповой политики не определен, значение выбирается из следующего расположения реестра:

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

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

Всё о PowerShell в Windows и на Linux. Системное администрирование Windows

В этом руководстве я постараюсь рассказать вам о типичных причинах, по которым объект групповой политики (GPO) не может быть применён к организационном подразделении (OU), конкретному компьютеру или пользователю домена. Думаю, эта статья будет полезна как новичкам, так и IT-специалистам для понимания работы и архитектуры GPO. Прежде всего, я расскажу о возможных проблемах применения GPO, связанных с настройками политики на уровне домена, вместо устранения проблем с GPO на клиентах. Практически все параметры, описанные в статье, настраиваются с помощью Консоли управления групповыми политиками (GPMC.msc).

Управление областью действия GPO

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

Также убедитесь, что объект, к которому вы пытаетесь применить свой GPO, находится в правильном контейнере AD (OU) компьютеров или пользователей. Если у вас много объектов и вы не можете вспомнить, в каком организационном подразделении находится нужный вам пользователь или компьютер, то вы можете выполнить поиск по объектам в своём домене. После выполнения поиска, чтобы узнать, в какое организационное подразделение (OU) помещён найденный объект, дважды кликните на него, перейдите на вкладку Object («Объект»), где в поле «Каноническое имя объекта» вы увидите полный путь, включающий имя организационного подразделения.

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

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

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

Если вы хотите изменить фильтрацию безопасности, чтобы применить политику только к членам определённой группы безопасности (или определенным пользователям/компьютерам), удалите «Authenticated Users» из списка фильтрации безопасности и убедитесь, что целевой объект (пользователь или компьютер) добавлен в нужную вам группу AD. Также убедитесь, что группа, которую вы добавили в фильтр безопасности, имеет разрешения Read и Apply group policy с установленным флажком Allow («Разрешить») в GPO → Delegation → кнопка Advanced (GPO → Делегирование → кнопка «Дополнительно»).

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

Фильтрация GPO WMI

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

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

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

Статус GPO

Проверьте статус GPO на вкладке Details свойств политики в GPMC.msc. Обратите внимание на значение в раскрывающемся списке GPO Status («Состояние объекта групповой политики»).

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

All settings disabled (Все настройки отключены) — все настройки политики отключены (GPO не применяется);
Computer configuration settings disabled (Параметры конфигурации компьютера отключены) — параметры только из конфигурации компьютера вашего GPO не применяются;
User configuration settings disabled (Параметры конфигурации пользователя отключены) — параметры из раздела конфигурации пользователя не применяются;
Enabled (Включено) — все настройки GPO применяются к целевым объектам AD (значение по умолчанию).

Делегирование групповой политики

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

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

Наследование — одна из основных концепций GPO. По умолчанию политики высокого уровня применяются ко всем вложенным объектам в иерархии домена. Однако администратор может заблокировать применение всех унаследованных политик к определённому подразделению. Для этого щёлкните правой кнопкой мыши подразделение в консоли управления групповыми политиками и выберите Block inheritance («Заблокировать наследование»).

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

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

Обратите внимание, что политики домена с включённым свойством Enformed применяются даже к подразделениям с заблокированным параметром наследования (вы можете увидеть унаследованные политики, применённые к контейнеру, на вкладке Group Policy Inheritance).

Область действия GPO и порядок приоритетной обработки (LSDOU)

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

Политики локального компьютера (Local), настроенные в gpedit.msc (Редактор локальной групповой политики);
GPO уровня сайта (Site);
GPO уровня домена (Domain).
Объекты групповой политики с уровня организационного подразделения (Organizational Unit).

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

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

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

Link Enabled Setting («Связь включена») для GPO

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

Как включить GPO Loopback Processing Mode (режим обработки замыкания GPO)

Если вы включили Loopback Processing mode («Режим обработки замыкания»), вы можете применить настройки из раздела «Конфигурация пользователя» к объекту компьютера. Вы можете включить режим кольцевой обработки в следующем разделе редактора GPO: Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy Loopback Processing mode (в русифицированной версии Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Настройка режима обработки замыкания пользовательской групповой политики). Например, если вы включите обработку обратной связи политики, зададите некоторые параметры в разделе «Конфигурация пользователя» и свяжете политику с подразделением с объектами компьютеров, эти параметры политики будут применены к выполнившим вход пользователям.

Этот режим обработки замыкания политики имеет два возможных значения:

Merge («Слияние») – сначала к пользователю применяется объект групповой политики на основе местоположения пользователя, а затем применяется объект групповой политики, связанный с компьютером. В случае конфликта политик OU пользователя и компьютера, политика компьютера будет иметь более высокий приоритет.
В этом режиме политика запускается дважды, обратите внимание на это при использовании сценариев входа в систему.
Replace («Замена») – к пользователю будут применяться только политики, назначенные подразделению, содержащему компьютер, на котором пользователь вошёл в систему.

Устранение неполадок GPO на стороне клиента

Вы можете диагностировать применение GPO на стороне клиента с помощью gpresult, rsop.msc или Просмотра событий Windows (eventvwr.msc).

Чтобы увидеть журнал событий применения групповых политик, откройте Event Viewer («Просмотр событий»), это можно сделать с помощью команды:

В средстве просмотра событий вы можете фильтровать события по источнику для этого нажмите «Создать настраиваемое представление» и в качестве источника выберите GroupPolicy (Microsoft-Windows-GroupPolicy).

Вы увидите журнал событий, связанных с применением групповых политик:

Такого же результата вы можете достичь если в окне Event Viewer («Просмотр событий») перейдёте по пути Applications and Services Logs → Microsoft → Windows → Applications and Services Logs → Group Policy → Operational (в русскоязычной версии это Журналы приложений и служб → Microsoft → Windows → Group Policy → Operational.

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

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

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

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

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

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

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

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

Обновление для системы безопасности из бюллетеня MS16-072, устраняет уязвимость в Microsoft Windows, с помощью которой злоумышленник может совершить атаку Man in the Middle (MiTM) с целью подмены трафика, проходящего между контроллером домена и целевой машиной. Целью такой атаки может быть получение прав локального администратора, на целевой машине.

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

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

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

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

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

Обычно объекты групповой политики назначаются на контейнер (домен, сайт или OU) и применяются ко всем объектам в этом контейнере. При грамотно организованной структуре домена этого вполне достаточно, однако иногда требуется дополнительно ограничить применение политик определенной группой объектов. Для этого можно использовать два типа фильтров.

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

Фильтры безопасности позволяют ограничить применение политик определенной группой безопасности. Для примера возьмем GPO2, с помощью которого производится централизованная настройка меню Пуск на рабочих станциях с Windows 8.1\Windows 10. GPO2 назначен на OU Employees и применяется ко всем без исключения пользователям.

Теперь перейдем на вкладку «Scope», где в разделе «Security Filtering» указаны группы, к которым может быть применен данный GPO. По умолчанию здесь указывается группа Authenticated Users. Это означает, что политика может быть применена к любому пользователю или компьютеру, успешно прошедшему аутентификацию в домене.

На самом деле каждый GPO имеет свой список доступа, который можно увидеть на вкладке «Delegation».

Для применения политики объект должен иметь права на ее чтение (Read) и применение (Apply group policy), которые и есть у группы Authenticated Users. Соответственно для того, чтобы политика применялась не ко всем, а только к определенной группе, необходимо удалить из списка Authenticated Users, затем добавить нужную группу и выдать ей соответствующие права.

Так в нашем примере политика может применяться только к группе Accounting.

WMI фильтры

Для примера возьмем класс Win32_OperatingSystem, который отвечает за свойства операционной системы. Предположим, что требуется отфильтровать все операционные системы кроме Windows 10. Заходим на компьютер с установленной Window 10, открываем консоль PowerShell и выводим имя, версию и тип операционной системы с помощью команды:

Get-WmiObject -Class Win32_OperatingSystem | fl Name, Version, ProductType

Для фильтра используем версию и тип ОС. Версия одинакова для клиентских и серверных ОС и определяется так:

Тип продукта отвечает за назначение компьютера и может иметь 3 значения:

Теперь переходим непосредственно к созданию фильтра. Для этого открываем оснастку «Group Policy Management» и переходим к разделу «WMI Filters». Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «New».

В открывшемся окне даем фильтру имя и описание. Затем жмем кнопку «Add» и поле «Query» вводим WQL запрос, который и является основой WMI фильтра. Нам необходимо отобрать ОС версии 10.0 с типом 1, соответственно запрос будет выглядеть так:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE ″10.0%″ AND ProductType = ″1″

Сохраняем получившийся фильтр.

Теперь осталось только назначить WMI фильтр на объект групповой политики, например на GPO3. Переходим к свойствам GPO, открываем вкладку «Scope» и в поле «WMI Filtering» выбираем из списка нужный фильтр.

Анализ применения групповых политик

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

Для примера зайдем на компьютер wks2, на котором установлена ОС Windows 7, и проверим, сработал ли WMI фильтр. Для этого открываем консоль cmd с правами администратора и выполняем команду gpresult /r, которая выводит суммарную информацию о групповых политиках, примененных к пользователю и компьютеру.

Примечание. Утилита gpresult имеет множество настроек, посмотреть которые можно командой gpresult /?.

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

Также проверить действие GPO можно из оснастки «Group Policy Management», с помощью специального мастера. Для запуска мастера кликаем правой клавишей мыши на разделе «Group Policy Results» и в открывшемся меню выбираем пункт «Group Policy Results Wizard».

Указываем имя компьютера, для которого будет составлен отчет. Если требуется просмотреть только пользовательские настройки групповой политики, то настройки для компьютера можно не собирать. Для этого необходимо поставить галочку снизу (display user policy settings only).

Затем выбираем имя пользователя, для которого будут собираться данные, либо можно указать не включать в отчет настройки групповой политики для пользователя (display computer policy settings only).

Проверяем выбранные настройки, жмем «Next» и ждем, пока собираются данные и генерируется отчет.

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

А теперь откроем отчет для пользователя Oleg. Этот пользователь является членом группы Accounting, поэтому к нему политика была успешно применена. Это означает, что фильтр безопасности успешно отработал.

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

Читайте также: