Так, собственно моя история борьбы с этой штукой
Проблема возникла давно (года три назад), время расходилось на некоторых ПК аж на час, при этом 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х минут
- позавчера пользователь получил отказ в доступе к серверу по RDP (TRM02) (попытка входа в систему неудачна)
- сервер 2019ый, виртуалка на Hyper-V
- в логах 0, т.е. в логах безопасности нет отказа
- set logonserver = \\DC4
- время на клиенте правильное
- авторизация в шаре на этой же машине прозрачно - успех
- авторизация в RDP под другим пользователем - отказ
- авторизации в RDP с заходом в другую учетку на клиенте - отказ
- авторизация с другой тачки под этим пользователем - успех
- авторизация по IP в 50% случаев - успех
- удаление и добавление в список разрешенных для входа по RDP - отказ
- Источник времени гипервизора - local cmos clock - часы отстают на 5 минут
- Источник времени DC4 и TRM02 - VM IC Time Synchronization Provider - часы отстают на 5 минут
- Клиент - set logonserver = \\DC4
- Источник времени клиента - local cmos clock - идут верно
netdom query fsmoSelect * from Win32_ComputerSystem where DomainRole = 5Get-WmiObject -query "Select * from Win32_ComputerSystem where DomainRole = 5"NtpServer: 0.ru.pool.ntp.org,0x1 1.ru.pool.ntp.org,0x1 2.ru.pool.ntp.org,0x1 3.ru.pool.ntp.org,0x1Type: NTPCrossSiteSyncFlags: 2ResolvePeerBackoffMinutes: 15Resolve Peer BAckoffMaxTimes: 7SpecilalPoolInterval: 3600EventLogFlags: 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
Ох елки, решения так и не нашел, но скорее всего проблема в ноябрьских обновлениях, удалил обновления, тестируем.
Комментариев нет:
Отправить комментарий