Windows не удалось применить параметры group policy drive maps + видео обзор

Методика диагностики причин долгого применения GPO в Windows

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

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

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

Windows не удалось применить параметры group policy drive mapsПерезагрузите компьютер и проверьте, сохранилась ли проблема с долгим применением GPO. Если сохранилась, вероятнее всего проблема с самим компьютером или локальными политиками (попробуйте их сбросить на дефолтные).

Вывод подробных сообщений на экране загрузки

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

Windows не удалось применить параметры group policy drive maps

Этот же параметр можно активировать через реестр, создав в ветке HKEY_LOCAL_MACHINE\SOFTWARE Microsoft \Windows \CurrentVersion\ Policies\System параметр типа DWORD с именем verbosestatus и значением 1.

В результате на экране в процессе загрузки будут отображаться такие сообщения:

Windows не удалось применить параметры group policy drive maps

Отчет GPResult

Результирующую политику, которая была применена к компьютеру, стоит проанализировать с помощью HTML отчета gpresult, создать который можно такой командой, запущенной с правами администратора:

gpresult /h c:\ps\gpreport.html

Этот отчет достаточно удобен для анализа и может содержать ссылки на различные ошибки при применении GPO.

Group Policy Files (N/A) 453 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Folders (N/A) 188 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Local Users and Groups (N/A) 328 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Registry (N/A) 171 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Scheduled Tasks (N/A) 343 Millisecond(s) 18.01.2017 14:10:01 View Log
Scripts (N/A) 156 Millisecond(s) 18.01.2017 14:09:04 View Log
Security (N/A) 3 Second(s) 495 Millisecond(s) 18.01.2017 14:09:08 View Log
Реестр (N/A) 18 Second(s) 814 Millisecond(s) 18.01.2017 14:10:00 View Log

Windows не удалось применить параметры group policy drive maps

Анализ событий от Group Policy в системных журналах Windows

В журнале приложений о медленном применении политик может свидетельствовать событие с EventID 6006 от источника Winlogon с текстом:

Судя по данному событию, пользователю пришлось ждать применения групповых политик при загрузке компьютера в течении почти часа…

Для анализа времени применения политик будут полезны следующие EventID:

При анализе журнала стоит также обращать на время, прошедшее между двумя соседними событиями, это может помочь обнаружить проблемный компонент.

Отладочный журнал службы GPSVC

В некоторых ситуациях бывает полезным включить ведение отладочного журнала обработки GPO — gpsvc.log. С помощью временных меток в файле gpsvc.log можно найти компоненты GPO, которые долго отрабатывали.

Отладочные журналы Group Policy Preferences

Windows не удалось применить параметры group policy drive mapsКак вы видите, доступные индивидуальные настройки для каждого CSE. В настройках политики можно указать тип событий, записываемых в журнал (Informational, Errors, Warnings или все), максимальный размер журнала и местоположение лога:

Windows не удалось применить параметры group policy drive maps

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

Windows не удалось применить параметры group policy drive mapsИтак, в этой статье мы рассмотрели основные способы диагностики проблем долгого применения групповых политик на компьютерах домена. Надеюсь, статья будет полезной.

Источник

Обновление MS16-072 ломает Group Policy. Что с этим делать?

Windows не удалось применить параметры group policy drive maps

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

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

При попытке разобраться в ситуации, результат GPRESULT поверг в некоторое замешательство: некоторые политики безопасности уровня пользователя (user scope) не применялись, выдавая весьма «информативное» сообщение: «Filtering: Not Applied (Unknown Reason)». Некоторые новые политики просто не появлялись в выводе GPRESULT.

Кто виноват?

«Виновником» такого поведения стало обновление безопасности из статьи KB3163622 (бюллетень безопасности MS16-072, номер KB для различных ОС: KB3159398, KB3163017, KB3163018, KB3163016), призванное закрыть дыру в безопасности процесса применения групповых политик. С момента появления технологии групповых политик не было уделено должное внимание обеспечению доверенности источника политик. Атакующий, применяя тактику MitM (Man in the Middle — атака посредника), мог подменить ответ от контроллеров домена и прислать на атакуемый компьютер поддельные политики безопасности, дающие, например, права локального администратора скомпрометированной учётной записи рядового пользователя.

Как оказалось, для устранения данной проблемы программисты Microsoft не нашли ничего лучше, чем изменить поведение процесса применения групповых политик, которое не менялось со времени выхода Windows 2000. Традиционное поведение предусматривало доступ к политикам безопасности уровня компьютеров (computer scope) от учётной записи компьютера, а к политикам безопасности уровня пользователя (user scope) — от учётной записи пользователя. После установки обновления KB3163622 все запросы стали направляться от учётной записи компьютера, чтобы обеспечить доверенность источника силами протокола Kerberos.

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

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

Windows не удалось применить параметры group policy drive maps
Список фильтров безопасности (security filtering)

В результате, на Microsoft полился поток жалоб, а форумы запестрели скороспелыми рекомендациями отменить (decline) обновление KB3163622 в WSUS. Ситуация, к сожалению, стала не редкостью в последние годы, когда чуть ли не каждый месяц некоторые обновления выходят повторно в новой редакции после негативной реакции пользователей. В этот раз, однако, Microsoft дала понять, что не пойдёт на попятную и к новым правилам применения политик безопасности придётся привыкнуть.

15 июня в бюллетень MS16-072 добавили короткое указание, что, как говорится, «это не баг, это — фича», и такое изменение поведения будет сохранено.

Сотрудник Microsoft Ian Farr 16 июня опубликовал скрипт на PowerShell, который позволяет системным администраторам проверить, повлияет ли новое обновление на существующие политики.

На протяжении недели на специализированных ресурсах кипели страсти, так как кроме трех строчек в бюллетене безопасности никакой официальной информации от Microsoft не поступало. Наконец, через 9 дней после выхода обновления, в официальном блоге Ask the Directory Services Team вышла подробная статья, которая, по хорошему, должна была если не предварять выпуск обновления (пусть, по соображениям безопасности, до выхода «заплатки» нельзя раскрывать суть уязвимости), то уж по крайней мере идти первой строкой в июньском бюллетене.

Что делать?

TL;DR: Ниже приведена Инструкция по внесению изменений в GPO и AD для предотвращения ущерба от установки этого обновления.

При всём уважении к AD DS Team, мне кажется, что решение, которое они предлагают — добавить Authenticated Users или Domain Computers с доступом только для чтения во все политики, которые перестали работать, — является полумерой. При модификации или создании новых политик безопасности отныне и навсегда нужно будет помнить о необходимости добавлять одну из вышеупомянутых групп. Наглядный инструмент фильтров безопасности (security filtering), доступный прямо на первой странице редактора политик безопасности (group policy editor) вообще теряет всякий смысл, так как всё равно необходимо вручную изменять списки контроля доступа.

Более простым в эксплуатации мне представляется следующее решение: добавить группу Domain Computers с правами только на чтение (но не на применение) во все политики (если это возможно по соображениям безопасности), а также произвести минимальную модификацию схемы (schema) AD, чтобы новые политики создавались сразу с необходимыми правами.

Плюсом такого решения является отсутствие необходимости его поддержки: поведение групповых политик практически не изменится, нет необходимости менять правила создания/модификации политик. Продолжит работать и механизм фильтров безопасности (security filters), который очень наглядно позволяет представлять и редактировать параметры доступа к политикам.

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

Почему я предлагаю добавить Domain Computers, а не Authenticated Users? Во-первых, для того, чтобы не нарушать Принцип минимальных привилегий: даже после такого надругательства над этим принципом, которое совершает данное обновление, мы всё ещё можем не дать непривилегированному пользователю читать политики, которые применяются к привилегированным пользователям простым заходом в SYSVOL. Во-вторых, по умолчанию Authenticated Users уже имеют права на чтение и применение политики. Удаляя Authenticated Users из списка фильтров безопасности (security filtering) мы удаляем не только права на применение, но и права на чтение. В то же время, если группа Domain Computers добавлена в списки доступа только для чтения, она не отображается в списке security filtering и не будет удалена.

Соображения по применимости данных рекомендаций

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

1. Вторичное ограничение доступа к ресурсу. Например, доступ к сетевому принтеру ограничен группой Example1 в настройках безопасности самого принтера и, дополнительно, политика безопасности, которая подключает этот принтер, применяется только к членам группы Example1. В такой ситуации добавление прав на чтение (но не применение политик) для Domain Computers совершенно безопасно.

2. Ограничение распространения информации, которая содержится в самой политике безопасности. Я не рекомендовал бы хранить уязвимые (sensitive) данные (например, пароли) в политиках безопасности, но, допускаю, что до прошлой недели такой подход имел право на существование, так как доступ к файлам политики безопасности в общей папке SYSVOL автоматически ограничивается списком доступа, применённым к самой политике. После изменений, которые приносит обновление, доступ вынужденно получат учётные записи всех компьютеров. Обратиться к папке SYSVOL от имени компьютера всё ещё не самая тривиальная задача для пользователя с ограниченными правами, но, потенциально, это возможно (например, с применением отдельной уязвимости локального повышения привилегий). Прежде чем переходить к следующим пунктам инструкции, следует взвесить потенциальные риски, и, возможно, убрать уязвимую (sensitive) информацию из политики безопасности.

2a. В условиях повышенных требований к безопасности, согласно Принципу минимальных привилегий, доступ по умолчанию для Authenticated Users может быть заменён на более узкий для всех политик безопасности. В таком случае, необходим полный пересмотр всей стратегии защиты политик. Для политик уровня пользователя (user scope) попытка сузить круг доступа теперь неминуемо приведёт к нарушению постулата о разделения пользовательских и компьютерных политик безопасности. Например, попытка ограничить распространение политики, применимой только к привилегированным пользователям, группой компьютеров, на которых эти пользователи работают, приведёт к фактическому смешению уровней политик (user and computer scope), что не является хорошей практикой.

Инструкция

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

Предупреждение. Следующим шагом является изменение схемы (schema) AD для того, чтобы вновь создаваемые политики уже имели разрешение для чтения политики группой Domain Computers в своём списке контроля доступа. Хотя изменение минимально, я хотел бы посоветовать тем администраторам, которые не знают, что такое схема (schema) AD, сперва изучить данное понятие либо ограничиться предыдущим пунктом инструкции и добавлять Domain Computers в новые политики вручную, либо запускать вышеупомянутую команду PowerShell (или её модификацию с заменой «-All» на имя политики) после создания каждой новой политики безопасности.

Дальнейшая инструкция является вольным переводом статьи Darren Mar-Elia.

Проверьте, что у вас есть достаточный уровень доступа для проведения следующих операций. Вы должны входить в состав (напрямую или косвенно) группы Schema Admins.

1. Запустите ADSIEdit.msc в меню Action, откройте пункт Connect To и выберите Schema из списка:
Windows не удалось применить параметры group policy drive maps
Подключение к схеме (schema) AD в ADSIEdit

2. Раскройте дерево CN=Schema, CN=Configuration. В списке справа выберите CN=Group-Policy-Container:
Windows не удалось применить параметры group policy drive maps
Класс Group Policy Container в ADSIEdit

3. Двойным щелчком по CN=Group-Policy-Container откройте список атрибутов. Найдите атрибут defaultSecurityDescriptor. Откройте значение атрибута.

4. На всякий случай скопируйте текущее значение атрибута defaultSecurityDescriptor в Notepad и сохраните в файл. Установите курсор в самый конец длинного значения атрибута, после последней закрывающей скобки. Добавьте следующее значение (проверить, что означает данная «магическая» строка можно с помощью утилиты SDDLPARSE):

(A;CI;LCRPLORC;;;DC)

Windows не удалось применить параметры group policy drive maps
Редактирование defaultSecurityDescriptor

5. Нажмите OK, чтобы применить изменения.

6. Запустите MMC, войдите в меню FileAdd/remove snap-ins и в нём выберите Active Directory Schema. Если вы не видите AD Schema в списке, вам необходимо отключить так называемую «защиту от дурака». Запустите командную строку с повышенными привилегиями и введите regsvr32 schmmgmt.dll, после чего перезапустите MMC. Кликните правой кнопкой мыши на пункт «Active Directory Schema» и выберите «Reload the Schema» как показано ниже:
Windows не удалось применить параметры group policy drive maps
Обновление схемы (schema) AD

7. В результате вышеперечисленных действий новые групповые политики будут создаваться сразу с настроенным доступом для чтения группе Domain Computers:
Windows не удалось применить параметры group policy drive maps
Новая политика безопасности

Заключение

Я не берусь судить, была ли возможность закрыть брешь менее хлопотным для администраторов по всему миру способом (пусть и за счёт большего объёма работы для программистов Microsoft). Во всяком случае, подробное описание изменения должно было быть включено в изначальный бюллетень безопасности, а не опубликовано спустя 9 дней в (пусть и официальном) блоге.

Следует отметить, что, закрывая брешь MitM повышения уровня доступа (elevation of privilege), обновление KB3163622 открывает множественные бреши раскрытия информации (information disclosure), и с этим придётся считаться.

Источник

Долгая обработка GPP на этапе “Applying Group Policy Drive Maps policy” на клиентах RODC Windows Server 2008 R2

На этапе внедрения RODC на базе Windows Server 2008 R2 была замечена проблема связанная с увеличением времени входа в систему на клиентских ПК. Проблема была выявлена на всех площадках где для авторизации в домене и применения групповых политик клиенты использовали RODC. После ввода учетных данных процесс входа в систему на несколько минут «замерзал» на этапе «Applying Group Policy Drive Maps policy». Разумеется, подозрение сразу пало на обработку Group Policy Preferences (GPP) в части обработки подключения сетевых дисков, так как в одной из групповых политик, применяемых в части User Configuration у меня было n-ное количество таких подключаемых дисков через механизмы GPP с использованием для каждого подключения нацеливания (Item-level targeting)

Windows не удалось применить параметры group policy drive maps

Для подключения разных дисков использовались три вида нацеливания: по членству пользователя в доменной группе, по NetBios имени компьютера и по вхождению пользователя в определенный OU в домене.
Для того чтобы выяснить то, обработка какого именно подключения являлась корнем проблемы пришлось прибегнуть к включению трейсов для обработки параметров GPP. Для этого пришлось в групповой политике применяемой к испытуемому клиентскому компьютеру в разделе Computer Configuration активировать и настроить параметр Policies > Administrative Templates > System > Group Policy >Logging and tracing > Drive Maps Policy Processing.

Windows не удалось применить параметры group policy drive maps

По умолчанию ведение трейсов выключено и параметры для определения размещения лог файлов ссылаются на каталог %COMMONAPPDATA%GroupPolicyPreferenceTrace.

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

Windows не удалось применить параметры group policy drive maps

После того как новая политика, включающая логирование применения GPP была применена на клиенте с помощью команды gpupdate, был сделано logoff/logon чтобы спровацировать обработку GPP в части подключения сетевых дисков пользователю. Теперь на испытуемом клиентском компьютере в указанном каталоге (C:ProgramDataGroupPolicyPreferenceTrace) был обнаружен файл трассировки User.log

Windows не удалось применить параметры group policy drive maps

Оказалось что это единственный сетевой диск, в котором для нацеливания использовался признак вхождения пользователя в определенный OU в домене. Было принято решение для пробы изменить нацеливание для данного сетевого диска по признаку членства пользователя в доменной группе… Каково же было моё удивление когда время входа в систему сократилось в разы 🙂 Даже покажу лог обработки после внесённых изменений, чтобы не быть голословным

Windows не удалось применить параметры group policy drive maps

Источник

Долгая аутентификация на сервере

Зарегистрирован: 06.09.2012
Пользователь #: 142,234
Сообщения: 316

Windows не удалось применить параметры group policy drive mapscobion
Участник форума

Зарегистрирован: 06.09.2012
Пользователь #: 142,234
Сообщения: 316

auth1.jpg
Описание:
Размер файла:52.1 KB
Просмотрено:1804 раз(а)
Windows не удалось применить параметры group policy drive maps

auth.jpg
Описание:
Размер файла:52.25 KB
Просмотрено:1807 раз(а)
Windows не удалось применить параметры group policy drive maps

Windows не удалось применить параметры group policy drive maps

Зарегистрирован: 06.09.2012
Пользователь #: 142,234
Сообщения: 316

gpo1.jpg
Описание:
Размер файла:157.47 KB
Просмотрено:1748 раз(а)
Windows не удалось применить параметры group policy drive maps

Зарегистрирован: 06.09.2012
Пользователь #: 142,234
Сообщения: 316

Зарегистрирован: 06.09.2012
Пользователь #: 142,234
Сообщения: 316

netlogon.jpg
Описание:
Размер файла:72.89 KB
Просмотрено:1731 раз(а)

Windows не удалось применить параметры group policy drive maps

Зарегистрирован: 06.09.2012
Пользователь #: 142,234
Сообщения: 316

Зарегистрирован: 29.06.2011
Пользователь #: 132,104
Сообщения: 8123

Зарегистрирован: 06.09.2012
Пользователь #: 142,234
Сообщения: 316

Источник

Видео

Доступ запрещен Не удалось применить выбранные настройки к системе #20

Доступ запрещен  Не удалось применить выбранные настройки к системе #20

Не удалось применить выбранные настройки к системе. ДОСТУП ЗАПРЕЩЁН[РЕАЛЬНО РАБОТАЕТ!]

Не удалось применить выбранные настройки к системе. ДОСТУП ЗАПРЕЩЁН[РЕАЛЬНО РАБОТАЕТ!]

💾 Не удается прочитать параметр ProductKey из файла ответов для автоматической установки

💾 Не удается прочитать параметр ProductKey из файла ответов для автоматической установки

Не удалось завершить процесс установки.Как исправить ошибку при установке системы Windows

Не удалось завершить процесс установки.Как исправить ошибку при установке системы Windows

Не удалось автоматически обнаружить параметры прокси этой сети (решение)

Не удалось автоматически обнаружить параметры прокси этой сети (решение)

Ошибка при применении параметров безопасности

Ошибка при применении параметров безопасности

Windows не удалось автоматически обнаружить параметры прокси этой сети

Windows не удалось автоматически обнаружить параметры прокси этой сети

Не удалось завершить процесс установки. Чтобы установить Windows перезапустите программу... #13

Не удалось завершить процесс установки. Чтобы установить Windows перезапустите программу... #13

Windows server 2012 Group Policy (Drive Maps LogonScripts Wallpaper)

Windows server 2012 Group Policy (Drive Maps LogonScripts Wallpaper)

Групповые политики и их включение в Windows 10 Home

Групповые политики и их включение в Windows 10 Home
Поделиться или сохранить к себе:
Добавить комментарий

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