Windows 10: групповая политика не может быть применена сразу после загрузки

Моя проблема заключается в том, что групповая политика не применяется при новой загрузке клиента. Сразу после загрузки клиент публикует сообщение об ошибке в журнале событий с источником «GroupPolicy (Microsoft-Windows-GroupPolicy)» и идентификатором события 1058: «Обработка групповой политики завершилась неудачей. [...]». На вкладке Сведения код ошибки равен 50, что означает ERROR_NOT_SUPPORTED. Это не просто косметическая проблема: политики действительно не применяются должным образом: например, подключенные сетевые диски отсутствуют. Через некоторое время выполнение «gpupdate» работает, и политики применяются нормально: отображаются подключенные сетевые диски.

Простейший сценарий, в котором мне удалось воспроизвести проблему: недавно созданный домен на недавно установленной Windows Server 2012R2, клиент - это недавно установленная 64-разрядная машина с Windows 10. Домен состоит только из одного контроллера домена и не имеет никаких отношений с другими доменами.

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

C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.

Подождав минуту или две, выполнение той же команды выдаст список каталогов. Запуск gpupdate на этом этапе будет работать нормально.

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

Другие факторы, которые могут иметь значение:

• NTLM ограничен в домене, но это, похоже, не имеет значения: даже после его включения, обновления политик и перезагрузки всех компьютеров симптомы остаются прежними.
• Не имеет значения, настроен ли сервер с использованием DHCP или со статической конфигурацией.
• DNS-сервер для домена не поддерживает динамические обновления. Необходимые записи были добавлены вручную (из C: \ Windows \ System32 \ config \ netlogon.dns)
• Гибернация отключена на клиенте (используется powercfg /h off), поэтому каждая загрузка является полной загрузкой, а не быстрой загрузкой
• Время ожидания обработки политики запуска политики установлено на 120 секунд.
• Подключение к DC работает нормально. Пинги будут работать. Выключение клиента, отключение моей учетной записи в AD, включение клиента приведет к тому, что клиент не будет входить в систему: он сразу же заметит, что учетная запись отключена.
• Помимо этой проблемы, я не замечаю ничего необычного.

Кажется, это больше проблема SMB, чем проблема групповой политики. Обнаружение соединения на стороне сервера показывает кое-что интересное: при первом выполнении команды dir \\domain.example.com\sysvolв Microsoft Message Analyzer на контроллере домена отображается следующее:

1. Клиент устанавливает TCP-соединение с портом 445 контроллера домена, и ComNegotiation успешно выполняется (DialectRevision: 0x02FF).
2. Сразу после этого переговоры успешно выполнены. DialectRevision является 0x0302.
3. Сразу после этого клиент закрывает TCP-соединение с TCP RST (??)

Каждый раз, когда я выполняю команду и получаю ошибку, выполняются шаги 2 и 3.

Когда команда начинает работать, выполняются шаги 1 и 2, но вместо того, чтобы клиент отправил TCP RST, выполняется SessionSetup, затем TreeConnect, а затем происходит много (на первый взгляд, нормального) болтовни SMB.

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

Кто-нибудь знает, как я могу отладить и решить эту проблему?

Начиная с Windows 8, Microsoft ввела понятие «быстрой загрузки», когда при выключении ОС они спят в памяти, так как Hibernate работает в обычных сценариях гибернации. Это приводит к более быстрому запуску ОС, но также имеет побочный эффект отключения обработки GP для каждого компьютера при запуске. Это, вероятно, то, что вы видите, и это можно отключить, отключив политику в разделе Конфигурация компьютера \ Политики \ Административные шаблоны \ Система \ Завершение работы \ Требовать использования быстрого запуска

Если это не решает проблему, то, скорее всего, это проблема синхронизации сетевого стека, когда обработка GP для компьютера начинается до полной инициализации сетевого стека. Это было примерно с XP и начиная с Windows 7, Microsoft добавила политику в Конфигурация компьютера \ Политики \ Административные шаблоны \ Система \ Групповая политика \ Время ожидания при обработке политики запуска, где вы можете увеличить время ожидания GP перед инициацией. Попробуйте установить его на 60 секунд и посмотреть, поможет ли это.

Даррен

Мне удалось решить эту проблему самостоятельно. Для справки вот что решило мою проблему:

Во-первых, я был неправ в том, что отключение всех блокировок NTLM приводило к тем же симптомам. Это привело к другому симптому, который оказал тот же эффект. Без действующих политик блокировки NTLM dirкоманда теперь вызвала ошибку отказа в доступе. Групповая политика по-прежнему не будет применяться, что имеет смысл: SYSVOL все еще не был доступен.

Небольшой поиск в сети сказал мне, что у меня была более распространенная проблема. хоть. Очевидно, что клиенты Windows 10 могут иметь проблемы с доступом к общей папке контроллеров домена SYSVOL (и, возможно, к общей папке NETLOGON). Предположительно, Windows 10 изменила что-то в способе доступа к этим ресурсам, что может привести к проблемам. Временное решение: отключить UNC Path Hardening на клиенте для этих общих ресурсов, установив групповую политику «Hardened UNC Paths» для клиентов Windows 10, например:

\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1

(Если у вас возникают проблемы с доступом к общему ресурсу Netlogon с клиентов Windows 10, это может помочь установить все три параметра на ноль и для этого общего ресурса.)

См. Статью от Microsoft о MS15-011 для получения дополнительной информации. Он содержит хорошее описание последствий изменения этого параметра для безопасности, а также подробные инструкции по изменению политики.

Внимание : обратите внимание, что приведенные выше настройки отключают некоторые или все защиты от проблемы безопасности, для которой был создан MS15-011! Не просто слепо копируйте / вставляйте их, но принимайте обоснованное решение, основанное на связанных с этим рисках. Кроме того, эта проблема, вероятно, будет решена когда-нибудь в будущем. Когда это произойдет, не забудьте установить для этой политики рекомендуемые значения, как описано в MS15-011.

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

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

Просто к вашему сведению для всех, кто найдет эту ветку, отключение защиты UNC через установку взаимной аутентификации на 0 отключает некоторые из ваших мер безопасности. У нас та же проблема с клиентами win7, и я пытался работать с Microsoft над этим. Они сказали мне, что это ошибка, но пока не дали мне способа отследить, когда ошибка будет устранена.

См. Эту другую ветку для получения дополнительной информации https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise -x64