Обнаружено быстрое подключение gpo windows 10

Обновлено: 07.07.2024

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

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

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

Чтобы убедиться, что проблема связана именно с доменными GPO, создайте в домене отдельную OU, перенесите в нее проблемный компьютер и с помощью консоли Group Policy Management Console (GPMC.msc) включите блокирование наследование политик для данного контейнера ( Block Inheritance ). Таким образом на компьютер перестанут действовать все доменные политики (исключение — политики, для которых включен режим Enforced) .

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

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

в Windows 7 / Vista : Computer Configuration -> Policies -> System -> Verbose vs normal status messages = Enabled
в Windows 8/10 : Computer Configuration -> Policies -> System -> Display highly detailed status messages = Enabled

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

Отчет GPResult

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

gpresult /h c:\ps\gpreport.html

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

Кроме того, в разделе отчета Computer Details -> Component Status присутствуют полезные данные о времени (в мс) применения различных компонентов 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

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

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

Подписчик уведомлений winlogon <GPClient> потратил 3594 сек. на обработку события уведомления (CreateSession).The winlogon notification subscriber <GPClient> took 3594 seconds to handle the notification event (CreateSession).

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

В Windows 7 / Windows 2008 R2 и выше все события, касающиеся процесса применения групповых политик на клиенте доступны в журнале событий Event Viewer (eventvwr.msc) в разделе Applications and Services Logs –> Microsoft -> Windows -> Applications and Services Logs -> Group Policy -> Operational .

Примечание. В журнале System остались только события, относящиеся к функционирования самой службы Group Policy Client (gpsvc) .

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

События 4016 и 5016 показывают время начала и завышения процесса обработки расширений применения GPO, причем в последнем указано общую длительность обработки расширения.К примеру, на скриншоте ниже был включен фильтр журнала Group Policy -> Operational по событиям 4016 и 5016. По тексту события 5016 можно увидеть время обработки этого компонента GPOЗавершена обработка расширения Group Policy Local Users and Groups за 1357 мс.

Событие 5312 содержит список применённых политик, а в событии 5317 есть список отфильтрованных GPO.

В событиях 8000 и 8001 содержится, соответственно, время обработки политик компьютера и пользователя при загрузке компьютера. А в событиях 8006 и 8007 есть данные о времени применения политик при периодическом обновлении.Завершена обработка политики загрузки компьютера для CORP\pc212333$ за 28 с.

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

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

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

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

Расширения Group Policy Preferences также могут вести подробные лог загрузки каждого компоненте CSE (Client-Side Extensions). Отладочные журналы CSE можно включить в разделе GPO: Computer Configuration -> Policies -> Administrative Templates->System->Group Policy -> Logging and tracing

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

Трейс файл пользовательских политик %SYSTEMDRIVE%\ProgramData\GroupPolicy\Preference\Trace\User.log
Трейс файл политик компьютера %SYSTEMDRIVE%\ProgramData\GroupPolicy\Preference\Trace\Computer.log

Совет . В том случае, если у вас в консоли gpedit/ GPMC в разделе Group Policy отсутствует подраздел Logging and Tracing, нужно будет скачать и установить шаблоны Group Policy Preferences ADMX и скопировать GroupPolicyPreferences.admx из %PROGRAMFILES%\Microsoft Group Policy в локальный каталог PolicyDefinitions либо в централизованный каталог PolicyDefinitions на SYSVOL .

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

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

Примененные объекты групповой политики
---------------------------------------
test
Default Domain Policy
Политика локальной группы

В результирующей политике написано

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

Обновление политики пользователя завершено успешно.
Обновление политики для компьютера успешно завершено.

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

Windows не удалось применить параметры "Scripts". Параметры "Scripts" могут имет
ь свой собственный файл журнала. Щелкните ссылку "Дополнительные сведения".

У меня тут другая трабла(
потребовалось создать некоторые GP. ну в общем создал только они не применяются! GP крайне просты - одна содержит только Logon script в виде bat файла для смены основного шлюза и dns сервера ( в сети используется статическая адресация ) и вторая содержит параметры настройки proxy сервера - указывает путь до proxy.pac файла.
так вот ни та ни другая не применяется на клиентах. Пытался писать gpupdate /force и на сервере и на клиенте. Старые политики как работали так и работают, а вот новые не хотят подхватываться. Политики добавлял в раздел GPM -> Group Policy Object и далее делал ссылки в соответствующих OU в том же GPM на существующую политику. Так работают все нынешние политики - по другому у меня не работало.
В логах клиента и сервера ни чего странного.

задела меня мысля гражданина mattveiko по поводу прав. думаю авось и вправду он прав! Ну прикрутил я значится щас к своему скрипту права админа домена и О ЧУДО! он сработал, НО ладно скрипт, а что делать с обычными настройками GP такими как параметры автоматической конфигурации прокси сервера? я конечно могу написать и для его изменения батник, там всё просто - настройки для IE прокси хранятся в известной ветке реестра.

и всё таки мне всю жизнь казалось что GP применяются именно с правами NT AUTHORITY/SYSTEM.

контроллер домена и и сервер на вин сервер 2008 р2 сп1
создаю пользоваелей и назначаю локальные политки. делаю gpupdate,в 1-й раз принменяются

если потом в политике на какого-ниь юзера менять что-то, то эти измененния не применяются, хотя после gpupdate /force типов все успевшно.

Всё о 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 как можно более простой и не создавать ненужных политик. Используйте прозрачную схему именования политик: имя должно чётко указывать, для чего предназначен объект групповой политики.

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

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

Кто виноват?

«Виновником» такого поведения стало обновление безопасности из статьи 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), а также непосредственной модификации настроек доступа к некоторым политикам. Следует отметить, что модификация списков контроля доступа к политикам является штатным инструментом настройки политик и не может быть поводом для обвинения системных администраторов в создании нестандартной ситуации.

Список фильтров безопасности (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 с правами доменного администратора или иной учетной записи, имеющей полный доступ ко всем политикам безопасности и ввести следующую команду:

Get-GPO -All | Set-GPPermissions -TargetType Group -TargetName "Domain Computers" -PermissionLevel GpoRead

Данная команда добавит права на чтения (но не применение) политик для группы Domain Computers во все политики безопасности домена. После её выполнения можно смело устанавливать обновление KB3163622, для существующих политик безопасности оно больше не страшно.

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

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

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

1. Запустите ADSIEdit.msc в меню Action, откройте пункт Connect To и выберите Schema из списка:

Подключение к схеме (schema) AD в ADSIEdit

2. Раскройте дерево CN=Schema, CN=Configuration. В списке справа выберите CN=Group-Policy-Container:

Класс Group Policy Container в ADSIEdit

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

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

(A;CI;LCRPLORC;;;DC)

Редактирование defaultSecurityDescriptor

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

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

Обновление схемы (schema) AD

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

Новая политика безопасности

Заключение

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

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

В последних билдах Windows 10 встречался неприятный баг, из-за которого перестают подключаться сетевые диски после перезагрузки компьютера. После входа в систему пользователь в проводнике Windows видит красный крест на иконках всех подключенных сетевых дисков. Если в командой строке выполнить команду net use, то напротив всех подключенных дисков вы увидите статус Недоступны (Unavailable). Автоматически не переподключаются как сетевые диски, подключенные пользователем, так и диски, подключаемые через GPO.

Впервые эта проблема была обнаружена в Windows 10 1809, но она встречается и в более новых билдах, в том числе в Windows 10 2004.

В этой статье рассмотрим:

Windows 10 не восстанавливает подключение к сетевым дискам
PowerShell скрипт для автоматического переподключения сетевых дисков
Подключение сетевых дисков через GPO
Не подключаются сетевые диски в Windows 10 2004
Настроить задержку подключения сетевых дисков в Windows через GPO
Отключить уведомление “Не удалось восстановить подключение ко всем сетевым дискам”

Windows 10 не восстанавливает подключение к сетевым дискам

Windows 10 по какой-то причине перестает автоматически подключать сетевые диски после перезагрузки компьютера. Сетевые диски отображаются в проводнике, но подключиться к ним нельзя.

При этом в области уведомлений появляется всплывающее окно с текстом:

Проблема возникает как с дисками, подключенных с NAS устройств, так и с сетевыми папками на других компьютерах Windows/Linux. Этот баг впервые появился в Windows 10 1809 и по словам Microsoft исправлен обновлением KB469342 выпущенным 5 декабря 2018 года (addresses an issue that may cause mapped drives to fail to reconnect after starting and logging onto a Windows device). Но проблема встречается и в других билдах Windows 10.

Вы можете скачать и установить обновление из Microsoft Update Catalog вручную.

Также Microsoft предлагает обходное решение проблемы с восстановлением подключения к сетевым дискам (см. KB4471218 — Mapped network drive may fail to reconnect in Windows 10). Для этого при входе пользователя в систему предлагается запускать PowerShell скрипт, который должен переподключить все недоступные сетевые диски. Если сетевые диски подключаются через групповые политики, нужно изменить настройки GPO.

PowerShell скрипт для автоматического переподключения сетевых дисков

Рассмотрим, как использовать PowerShell скрипт для автоматического переподключения сетевых дисков при входе пользователя в Windows.

Откройте блокнот (notepad.exe), скопируйте в него следующий PowerShell код и сохраните файл в каталог C:\PS с именем MapDrives.ps1:

$i=3
while($True)$error.clear()
$MappedDrives = Get-SmbMapping |where -property Status -Value Unavailable -EQ | select LocalPath,RemotePath
foreach( $MappedDrive in $MappedDrives)
try New-SmbMapping -LocalPath $MappedDrive.LocalPath -RemotePath $MappedDrive.RemotePath -Persistent $True
> catch Write-Host "Ошибка подключения сетевого каталога $MappedDrive.RemotePath в диск $MappedDrive.LocalPath"
>
>
$i = $i - 1
if($error.Count -eq 0 -Or $i -eq 0)
Start-Sleep -Seconds 30
>

Данный скрипт выбирает все недоступные сетевые диски и пытается их переподключить в постоянном режиме (ключ Persistent).

Создайте еще один файл сценария MapDrives.cmd с кодом:

PowerShell -Command "Set-ExecutionPolicy -Scope CurrentUser Unrestricted" >> "%TEMP%\StartupLog.txt" 2>&1
PowerShell -File "%SystemDrive%\PS\MapDrives.ps1" >> "%TEMP%\StartupLog.txt" 2>&1

Данный код позволяет корректно вызвать PowerShell скрипт, описанный выше.

Вы можете поместить файл в автозагрузку пользователя, скопировав файл MapDrives.cmd в каталог %ProgramData%\Microsoft\Windows\Start Menu\Programs\StartUp.

Также вы можете создать задание планировщика, которое дожно запускать файл MapDrives.cmd при входе пользователя в систему. Вы можете создать задание планировщика с помощью PowerShell или из графического интерфейса консоли планировщика Windows (Taskschd.msc).

Создайте новое задание, укажите его имя, выберите что задание должно запускаться от имени встроенной группы Пользователи (Builtin\Users).

На вкладке Триггеры выберите, что задание должно выполняться при входе в систему любого пользователя (At logon -> Any user).

На вкладке действие в поле Программа укажите путь к файлу MapDrives.cmd.

На вкладке Условие можно включить опцию Сеть -> Запускать только при подключении к следующей сети -> Любое подключение.

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

Обратите внимание, что по-умолчанию сетевые диски, подключенные в привилегированном режиме не доступны в обычном и наоборот.

Подключение сетевых дисков через GPO

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

Откройте политику, подключающую диски, и в разделе User Settings -> Preferences -> Windows Settings -> Drive maps найдите вашу политику (политики) назначения сетевых дисков и измените тип действия с Update на Replace.

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

Не подключаются сетевые диски в Windows 10 2004

Проблема с подключением сетевых дисков также наблюдается в билде Windows 10 2004. Проблема возникает с сетевыми дисками, подключенных с legacy устройств с поддержкой только протокола SMBv1 (Windows XP/2003, старые NAS устройства).

Для решения этой проблемы нужно прописать в реестре пользователя для каждого подключенного сетевого диска параметр ProviderFlags =1.

Например, если у пользователя в сессии подключен сетевой диск U:, перейдите в раздел реестра HKEY_CURRENT_USER\Network\U. Создайте параметр типа DWORD с именем ProviderFlags и значением 1.

Или выполните команду:

REG ADD "HKCU\Network\U" /v "ProviderFlags" /t REG_DWORD /d "1" /f

Настроить задержку подключения сетевых дисков в Windows через GPO

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

Вы можете настроить этот параметр через редактор локальной групповой политики (gpedit.msc) или из редактора доменных GPO (gpmc.msc). Перейдите в раздел Computer Configuration -> Administrative Templates -> System -> Logon и включите политику Always wait for the network at computer startup and logon (Всегда ожидать инициализации сети при загрузке и входе в систему).

Также эту проблему можно решить, если просто подождать 15 секунд после загрузки компьютера (или выхода его из режима гибернации/спящего режима), прежде чем логиниться. Этого времени будет достаточно, чтобы Windows инициализировала сеть.

Отключить уведомление “Не удалось восстановить подключение ко всем сетевым дискам”

Если ваш компьютер находится не в сети предприятия (сетевые диски не доступны по определению), и вам мешает назойливое уведомление “Не удалось восстановить подключение ко всем сетевым дискам” при каждой загрузке Windows, вы можете его отключить.

Для этого в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider нужно создать параметр типа DWORD с именем RestoreConnection и значением 0.

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