Windows 10: Групповая политика не удается применяться непосредственно после начальной загрузки, успешно выполняется позже
Моя проблема состоит в том, что Групповая политика не применяется, когда клиент недавно загружается. Непосредственно после начальной загрузки, клиент отправляет сообщение об ошибке, в конечном счете регистрируют с источником "GroupPolicy (Microsoft-Windows-GroupPolicy)" и Идентификатор события 1058: "Обработка Групповой политики перестала работать. [...]". На вкладке Details ErrorCode равняется 50, который обозначает ERROR_NOT_SUPPORTED. Это не просто косметическая проблема: политики действительно не применяются правильно: подключенные сетевые диски не там, например. После ожидания некоторое время, выполняя "gpupdate" работы и политики применяются обычно: подключенные сетевые диски появляются.
Самый простой сценарий, в котором я смог воспроизвести проблему: Недавно созданный домен на недавно установленном Windows Server 2012R2, клиент является недавно установленным Windows 10 64-разрядная машина. Домен состоит из просто одного контроллера домена и не имеет никаких отношений с другими доменами.
Так как сообщение об ошибке указывает, что Windows не может считать.GPT файл из Sysvol-доли домена, я пытался получить доступ к тому же файлу от Командной строки. И действительно, когда я открываю Command Prompt прямо после начальной загрузки, я получаю это:
C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.
После ожидания минуты или два, выполняя ту же команду даст список каталогов. Выполнение gpupdate в этой точке будет работать просто великолепно.
Я действительно устанавливал установку Group Policy, "Всегда ожидают сети при компьютерном запуске и входе в систему" "Включенного", и я знаю, что эта политика применяется: в том же объекте политики установка Registry указана, и когда я проверяю Реестр на клиенте, указанная установка там.
Другие факторы, которые могли быть соответствующими:
- NTLM ограничивается в домене, но это, кажется, не имеет значения: даже после включения его, обновления политик и перезагрузки всех машин, признаки остаются тем же.
- Не имеет значения, настроен ли сервер с помощью DHCP или со статической конфигурацией.
- Сервер DNS для домена не поддерживает Динамические Обновления. Необходимые записи были добавлены вручную (от C:\Windows\System32\config\netlogon.dns)
- Спящий режим отключен на клиенте (использование
powercfg /h off) таким образом, каждая начальная загрузка является полной начальной загрузкой, не Быстрой загрузкой - Политика Запуска политики, Обрабатывающая Время ожидания, установлена на 120 секунд
- Возможность соединения к DC хорошо работает. Ping будут работать. Выключение клиента, отключение моей учетной записи в AD, включение клиента приведут к клиенту, не регистрирующему меня в: это сразу замечает, что учетная запись отключена.
- Кроме этой проблемы, я не замечаю ничего необычного.
Это, кажется, больше проблемы SMB, чем проблема Групповой политики. Сниффинг соединения на стороне сервера показывает что-то интересное: В первый раз я выполняю команду dir \\domain.example.com\sysvol, следующие шоу в Microsoft передают Анализатор на DC:
- Клиент настраивает соединение TCP для портирования 445 из DC, и ComNegotiation успешно выполняется (DialectRevision: 0x02FF).
- Сразу после этого Согласовывание успешно выполняется. DialectRevision является 0x0302.
- Сразу после этого клиент закрывает соединение TCP с RST TCP (??)
Каждый после времени я даю команду и получаю ошибку, шаги 2 и 3 происходят.
Когда команда начинает работать, шаги 1 и 2 происходят, но вместо клиента, отправляющего RST TCP, SessionSetup выполняется, затем TreeConnect, и затем много (на вид нормальной) болтовни SMB происходит.
Так, похоже так или иначе, что клиент не будет правильно говорить SMB с DC до минуты или два после начальной загрузки, и это заставляет обработку Групповой политики перестать работать.
Кто-либо знает, как я могу отладить и решить эту проблему?
Мне удалось решить эту проблему самостоятельно. Для ссылки вот что решило мою проблему:
Во-первых, я был неправ, когда отключение всей блокировки NTLM приводило к тем же симптомам. Это привело к появлению другого симптома, оказавшего такой же эффект. Без действующих политик блокировки NTLM команда dir теперь приводила к ошибке отказа в доступе. Групповая политика по-прежнему не применяется, что имеет смысл: SYSVOL по-прежнему недоступен.
Небольшой поиск в Интернете показал мне, что у меня была более распространенная проблема. хотя. По-видимому, у клиентов Windows 10 могут возникнуть проблемы с доступом к общей папке SYSVOL контроллеров домена (а также, возможно, к общей папке NETLOGON). Предположительно Windows 10 что-то изменила в способе доступа к этим общим ресурсам, что может привести к проблемам. Обходной путь - отключить защиту пути UNC на клиенте для этих общих ресурсов, установив групповую политику «Защищенные пути UNC» для клиентов Windows 10 следующим образом:
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1
(Если у вас возникли проблемы с доступом к общему ресурсу Netlogon из Windows 10 клиентов, это может помочь установить все три параметра равными нулю и для этого общего ресурса.)
См. Статью от Microsoft о MS15-011 для получения дополнительной информации. Он содержит хорошее описание последствий изменения этого параметра для безопасности, а также подробные инструкции по изменению политики.
Предупреждение : обратите внимание, что настройки выше отключают некоторые или все из защита от проблемы безопасности MS15-011 была создана! Не просто слепо копируйте / вставляйте их, а принимайте осознанное решение, основанное на сопряженных рисках. Кроме того, эта проблема, вероятно, будет решена когда-нибудь в будущем. В этом случае не забудьте установить для этой политики рекомендуемые значения, как описано в MS15-011.
Начиная с Windows 8, Microsoft ввела понятие «быстрой загрузки», при котором, когда вы выключаете ОС, они переводят объем памяти ОС в спящий режим так же, как спящий режим работает в обычных сценариях спящего режима. Это приводит к тому, что ОС запускается быстрее, но также имеет побочный эффект отключения обработки GP на компьютере при запуске. Вероятно, это то, что вы видите, и это можно отключить, отключив политику в разделе Computer Configuration \ Policies \ Administrative Templates \ System \ Shutdown \ Require use of fast startup
Если это не решит проблему, тогда вероятно, проблема синхронизации сетевого стека, когда обработка GP для компьютера начинается до полной инициализации сетевого стека. Это было примерно с XP, а начиная с Windows 7, Microsoft добавила политику в папку Computer Configuration \ Policies \ Administrative Templates \ System \ Group Policy \ Startup Policy Processing Wait Time, где вы можете увеличить время ожидания GP перед запуском. Попробуйте установить его на 60 секунд и посмотрите, поможет ли это.
Даррен
Я попробовал несколько предложений, включая изменения реестра и изменения локальной групповой политики, ни одно из которых не решило проблему - подключенные диски по-прежнему были отключены при загрузке. Программа 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