Моя проблема в том, что групповая политика не применяется, когда клиент только что загружен. Сразу после загрузки клиент публикует сообщение об ошибке в журнале событий с источником "GroupPolicy (Microsoft-Windows-GroupPolicy)" и идентификатором события 1058: "Обработка групповой политики не удалась. [...]". На вкладке Details код ошибки равен 50, что означает ERROR_NOT_SUPPORTED. Это не просто косметическая проблема: политики действительно не применяются должным образом: например, сопоставленные сетевые диски отсутствуют. После некоторого ожидания выполнение "gpupdate" срабатывает, и политики применяются нормально: сопоставленные сетевые диски появляются.
Самый простой сценарий, в котором мне удалось воспроизвести проблему: недавно созданный домен на свежеустановленном Windows Server 2012R2, клиент — свежеустановленная машина Windows 10 64-bit. Домен состоит только из одного контроллера домена и не имеет никаких связей с другими доменами.
Поскольку сообщение об ошибке гласит, что Windows не может прочитать файл .GPT из Sysvol-share домена, я попытался получить доступ к тому же файлу из командной строки. И действительно, когда я открываю командную строку сразу после загрузки, я получаю это:
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 на DC отображается следующее:
- Клиент устанавливает TCP-соединение с портом 445 контроллера домена, и ComNegotiation успешно выполняется (DialectRevision: 0x02FF).
- Сразу после этого Negotiate успешно выполняется. DialectRevision — 0x0302.
- Сразу после этого клиент закрывает TCP-соединение с помощью TCP RST (??)
Каждый раз, когда я даю команду и получаю ошибку, происходят шаги 2 и 3.
Когда команда начинает работать, происходят шаги 1 и 2, но вместо отправки клиентом TCP RST выполняется SessionSetup, затем TreeConnect, а затем происходит много (на первый взгляд, нормальной) болтовни SMB.
Таким образом, похоже, что клиент каким-то образом не может правильно подключиться к контроллеру домена по протоколу SMB в течение минуты или двух после загрузки, и это приводит к сбою обработки групповой политики.
Кто-нибудь знает, как можно отладить и решить эту проблему?
решение1
Начиная с Windows 8, Microsoft ввела это понятие "быстрой загрузки", когда при завершении работы ОС они переводят ОС в спящий режим, как это происходит в обычных сценариях спящего режима. Это приводит к тому, что ОС загружается быстрее, но также имеет побочный эффект в виде отключения обработки GP для каждого компьютера при запуске. Вероятно, вы видите именно это, и это можно отключить, отключив политику в разделе Конфигурация компьютера\Политики\Административные шаблоны\Система\Завершение работы\Требовать использования быстрого запуска
Если это не решит проблему, то, скорее всего, проблема в синхронизации сетевого стека, когда обработка GP для компьютера запускается до полной инициализации сетевого стека. Это было примерно со времен XP, и начиная с Windows 7, Microsoft добавила политику в Computer Configuration\Policies\Administrative Templates\System\Group Policy\Startup Policy Processing Wait Time, где вы можете увеличить время ожидания GP перед запуском. Попробуйте установить его на 60 секунд и посмотрите, поможет ли это.
Даррен
решение2
Мне удалось решить эту проблему самостоятельно. ДляссылкаВот что решило мою проблему:
Во-первых, я ошибался, что отключение всех блокировок 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.
решение3
Просто FYI для всех, кто найдет эту ветку, отключение защиты 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
решение4
Я попробовал несколько предложений, включая изменения в реестре и локальные групповые политики, но ни одно из них не решило проблему — сопоставленные диски все еще были X'ом при загрузке. Gpupdate исправлял это каждый раз, но это был дополнительный шаг для пользователя.
В итоге это исправилось ручным сопоставлением сетевых дисков, заменой записей GPO на каждом из них. Не нужно было отключать и заменять, я сопоставил их так же, как они были сопоставлены, просто вручную.