пятница, 18 ноября 2022 г.

MSError Синхронизация времени в домене

Так, собственно моя история борьбы с этой штукой

Проблема возникла давно (года три назад), время расходилось на некоторых ПК аж на час, при этом kerberos ничуть не смущался и спокойно пускал куда надо. Когда начал лечение, делал по различным инструкциям при помощи GPO, программ NetTime, пытался указать насильно сервер обновления времени (роутер) и т.д. Понятно что некоторые варианты прокатывали, но под одной из статей я увидел гневный коммент пользователя, который сетовал на горе-админов, у которых руки из жопы и они настраивают время при помощи GPO. Распространение времени должно работать из коробки силами контроллера домена, единственная задача админа - настроить DC с ролью FSMO - PDC на получение времени снаружи.

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

Было 2 КД на базе 2008R2 (DC2 - первичный, DC3 - вторичный), надо обновляться, добавил КД на базе 2019 сервера (DC4). В периоде перехода была ошибка на первичном КД 2008R2, поэтому он был восстановлен, FSMO полностью переехали на DC4. 

  • появилась мигрирующая ошибка:
    • отказ в доступе к samba шаре на Ubuntu с доменной авторизацией (вводим верный пароль, а система отвечает что учетные данные не верны)
    • в логах ПК ничего не нашел
    • в логах samba-сервера также ничего нет
    • первоначальное мнение что проблема в samba-сервере заставило меня ввести в домен заново - отказ
    • set logonserver = \\DC4
    • ввод клиента в домен по новой - отказ
    • отключение DC4 и перезагрузка ПК в части случаев - успех
    • авторизация под ним же с другого ПК - успех
    • при входе по полному или короткому имени ресурса - отказ
    • при входе по ip-адресу - успех
    • на ПК с ошибкой разница во времени была, но незначительная - около 3х минут
Собственно временное решение - актуализировать время, klist purge и 95% работает, остальные 5% отправляются в перезагрузку и тоже работают
  • позавчера пользователь получил отказ в доступе к серверу по RDP (TRM02) (попытка входа в систему неудачна)
    • сервер 2019ый, виртуалка на Hyper-V
    • в логах 0, т.е. в логах безопасности нет отказа
    • set logonserver = \\DC4
    • время на клиенте правильное
    • авторизация в шаре на этой же машине прозрачно - успех
    • авторизация в RDP под другим пользователем - отказ
    • авторизации в RDP с заходом в другую учетку на клиенте - отказ
    • авторизация с другой тачки под этим пользователем - успех
    • авторизация по IP в 50% случаев - успех
    • удаление и добавление в список разрешенных для входа по RDP - отказ
Проведенные опыты указывают на проблему в клиенте. Собственно там и не RDP, а AppRemote, поэтому время я не видел. А теперь подробностей: DC4 и TRM02 -  виртуалки на одном гипервизоре Hyper-V. А теперь следим за руками:
  • Источник времени гипервизора - local cmos clock - часы отстают на 5 минут
  • Источник времени DC4 и TRM02 - VM IC Time Synchronization Provider - часы отстают на 5 минут
  • Клиент - set logonserver = \\DC4
  • Источник времени клиента - local cmos clock - идут верно
Ну как?, естественно он не будет авторизовывать, т.к. у клиента время кривое.
Поправил время на серверах, пара перезагрузок клиента и все работает. Но проблема времени резко дала под зад!

Именно тут я узнаю что PDC уже на DC4 и нам ничего не мешает. Как узнать?
netdom query fsmo
Далее создал групповую политику "TimeSync PDC", где WMI фильтр:
Select * from Win32_ComputerSystem where DomainRole = 5
А проверить его можно в Powershell:
Get-WmiObject -query "Select * from Win32_ComputerSystem where DomainRole = 5"
Команда вернет пустоту если сервер не обладает ролью PDC и портянку в обратном случае
Ну и чтобы политика лишний раз вообще не включалась - поместил ее в OU Domain Controllers 
Дальше все как по инструкции:

NtpServer: 0.ru.pool.ntp.org,0x1 1.ru.pool.ntp.org,0x1 2.ru.pool.ntp.org,0x1 3.ru.pool.ntp.org,0x1
Type: NTP
CrossSiteSyncFlags: 2
ResolvePeerBackoffMinutes: 15
Resolve Peer BAckoffMaxTimes: 7
SpecilalPoolInterval: 3600
EventLogFlags: 0

Тут я допустил первую ошибку  - указал тип NT5DS, но данный тип - передача времени в домене, а мы то запрашиваем не у домена. Включаем NTP Client и NTP Server. Проверяем 123 порт в брандмауэре, telnet его не возьмет, т.к. он UDP. 

gpupdate /force
w32tm /resync
w32tm /query /status

# если истоник и время не изменились
net stop w32time
w32tm.exe /unregister
w32tm.exe /register
net start w32time

У меня DC4 все получил, вроде бы и раздавать уж должен, а нет, не дает. Тыркался мыркался. Искал в групповых политиках другое учение - пусто клиентам AD. Отключил наследование времени от гипервизора и поставил NTP вместо NT5DS в политике и бац, время поправилось.

Дальше давай проверять на других машинах, выполняем w32tm /resync и w32tm /query /status дают красоту

UP ночь

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

Но технически проблема остается, расхождение на до пяти минут не критично для керберос, по-умолчанию - 5 минут, хранится в:
GPO или gpedit.msc - Политика - Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Политики учетных записей - Политика Kerberos - Максимальная погрешность синхронизации часов компьютера

secpol.msc - Параметры безопасности - Политики учетных записей - Политика Kerberos - Максимальная погрешность синхронизации часов компьютера

У меня стоит 10 минут, почему у пользователей возникают проблемы?

UP На следующий день

Тот же бух с той же проблемой, в качестве источника указан левый сервер, в связи с чем был выполнен сброс w32tm и настройка заново+перезагрузка:

net stop w32time
w32tm.exe /unregister
w32tm.exe /register
w32tm /config /syncfromflags:domhier
net start w32time

w32tm /resync
w32tm /query /status

shutdown -r -t 00 -f

Проверил после перезагрузки сервер и параметры реестра HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters, а также CurrentControlSet001 и CurrentControlSet002. Настройки верные, авторизация прошла

Но проблема в другом, теперь я со своего личного ПК (не в домене) не могу войти на этот сервер (TRM02) по RDP:

  • Учетка в правами доменного администратора.
  • В админскую шару с того же ПК с теми же кредами (не сохранены) пускает 
  • С ПК в домене с теми же кредами по RDP пускает 
  • В журнале Безопасность нет записей об отказе 
  • Время различается только поясами (сервер +3, клиент +5) 
  • На другие сервера (2008/2012/2019) по RDP пускает с этого ПК, в том числе и на КД авторизовавший (LOGONSERVER) TRM02.
  • В политике погрешности синхронизации часов стоит 10 минут на всех КД

UP

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

Комментариев нет:

Отправить комментарий