You are here

Для применения групповых политик и изменений в аккаунте пользователя (например членства в группах), необходимо перезаходить в систему 2 раза


Для применения групповых политик и изменений в аккаунте пользователя (например членства в группах) необходимо перезаходить в систему 2 раза

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

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

Практически сразу подозрения пали на tokenы Kerberos. Изучив все возможные логи на контроллере домена и компьютере абсолютно ничего, не было найдено. Проверил репликацию между контроллерами домена – так же проблем не обнаружил. Зато была найдена занимательная ]]>статья]]>, про механизм обновления Токенов Kerberos, где говориться, что в общем то это нормальное поведение. При первом заходе обновляется кэш, который храниться в реестре на локальном компьютере, при втором обновляется сам токен из кэша.

Интересно то, что раньше подобного не замечали (не берусь утверждать, что такого не было, возможно было, но именно не замечали), плюс ко всему если человека раньше в группе не было, и его в нее добавляли первый раз, то достаточно одного перезахода в систему, что бы информация о группах обновилась. К слову, я сделал тестовый, чистый домен, т.к. грешил на какую-то групповую политику, но на чистом домене, только с дефолтными политиками на Windows 2012R2 такой проблемы нет. Поставил чистую 10ку, ввел ее в домен – проблема есть.

В AD человек в группе есть, на компьютере - нет

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

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

Для того, что бы полностью отключить кэш необходимо установить 0 кэширующихся логонов, в параметре политики: Computer Configuration – Windows Settings – Security Settings – Local Policies – Security Options – Interactive Logon: Number of previous logons to cache (in case domain controller is not available).

Параметр групповой политики для отключения кэширования учетных записей

Что бы заставлять компьютеры пытаться дождаться сети, нужно добавить 2 параметра в  групповых политиках:

  1. Computer Configuration – Administrative Templates – System – Logon – Always wait for the network at computer startup and logon
  2. Computer Configuration – Administrative Templates – System – Group Policy – Specify startup policy processing wait time. В этом параметре необходимо увеличить время ожидания с 30 секунд, до скажем 60.

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

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

2 3

Share the article with your friends in social networks, maybe it will be useful to them.


If the article helped you, you can >>thank the author<<