Компьютеры теряют доверие к DC в Active Directory

Частая потеря доверительных отношений в домене Active Directory часто связана с рассинхронизацией паролей компьютерных учётных записей, сбоем репликации между контроллерами или ошибками аутентификации Kerberos — в результате пользователи видят «домен недоступен». Первичные проверки: синхронизация времени, состояние репликации AD/DNS, корректность SRV‑записей в dns active directory и анализ Netlogon/Kerberos‑логов; полезны команды Test-ComputerSecureChannel, Reset-ComputerMachinePassword, nltest и repadmin.

Содержание

• Почему домен недоступен: ключевые причины потери доверия
• Диагностика: проверка времени, Netlogon, Kerberos и dns active directory
• Глубокая диагностика: команды и что смотреть в логах
• Возможные причины (сценарии) и как их подтвердить
• Исправления: быстрые решения и массовые корректировки
• Профилактика и мониторинг
• Источники
• Заключение

Почему домен недоступен: ключевые причины потери доверия

Коротко: когда клиент не может установить защищённый канал с контроллером домена, появляется сообщение «домен недоступен» или «доверительные отношения нарушены». Причины часто пересекаются, поэтому искать надо системно. Чаще всего виноваты:

• Рассинхронизация пароля компьютерной учётной записи (machine account password) — особенно после клонирования/восстановления из снапшота или при конфликтной репликации.
• Проблемы репликации между двумя контроллерами (задержки, USN‑rollback, блокировки), из‑за чего один контроллер «знает» старый пароль, а другой — новый. Смотрите репликацию и состояние контроллеров как первое дело (Microsoft — Domain controller not functioning correctly).
• Временной сдвиг (Kerberos чувствителен к расхождению часов по умолчанию ±5 минут).
• DNS: отсутствующие или неверные SRV‑записи, «split‑brain» DNS или неправильно настроенные зоны (dns active directory). Даже если ping проходит, SRV/LDAP/Kerberos‑разрешение может быть некорректным (Domain join networking errors).
• Ошибки Kerberos (например, проблемы с токеном из‑за большого числа групп — MaxTokenSize) — см. заметки о Kerberos в AD (Kerberos authentication problems).
• Сторонние сетевые устройства/фаерволы/IDS/сетевые политики, которые разрывают соединения по динамическим RPC‑портам или блокируют порты Kerberos/LDAP.
• Неправильные настройки Site/Subnet в Active Directory: клиент может выборочно обращаться к «удалённому» контроллеру с неконсистентными данными.
• Виртуализация: восстановление DC или клиента из снапшота (USN rollback) — критичная и распространённая причина.

Ссылка на рекомендации по восстановлению доверительных отношений от Microsoft: Доверие между доменом Windows NT и доменом Active Directory.

Диагностика: проверка времени, Netlogon, Kerberos и dns active directory

План быстрых проверок (в порядке приоритетности):

1. Время и источник времени

• На PDC‑эмуляторе и на проблемных клиентах: w32tm /query /status.
• Быстрый тест синхронизации:

w32tm /stripchart /computer:DC01.domain.local /samples:5 /period:2

• Если PDC не синхронизирован с надёжным NTP — исправьте источник.

2. Secure channel и тесты с клиента

• PowerShell:

Test-ComputerSecureChannel -Verbose
# или попытка починить
$cred = Get-Credential "DOMAIN\Admin"
Test-ComputerSecureChannel -Repair -Credential $cred

• Если не помогает:

Reset-ComputerMachinePassword -Server "DC01.domain.local" -Credential $cred

• Аналог в консоли: nltest /sc_query:domain.local и nltest /sc_verify:domain.local.

3. DNS и SRV‑записи

• Проверка SRV:

nslookup
> set type=SRV
> _ldap._tcp.dc._msdcs.domain.local

• Убедитесь, что оба контроллера зарегистрированы и доступны и что зоны — AD‑integrated.

4. Репликация AD

• На контроллере:

repadmin /replsummary
repadmin /showrepl * /csv
dcdiag /test:replications /v

• Если есть ошибки — решать их прежде, чем массово сбрасывать пароли машин.

5. Логи Netlogon и Kerberos

• Включите подробный Netlogon‑лог (перезапустите Netlogon) и смотрите %windir%\debug\netlogon.log. Microsoft советует смотреть Netlogon и Kerberos журналы при неполадках с контроллером (Domain controller not functioning correctly).
• В журнале безопасности и в журналах «System»/«Directory Service» ищите сообщения о неудачной аутентификации/отказе подключения.

6. Проверка портов и сетевых путей

• На клиенте/сервере:

Test-NetConnection -ComputerName DC01.domain.local -Port 88
Test-NetConnection -ComputerName DC01.domain.local -Port 389
Test-NetConnection -ComputerName DC01.domain.local -Port 445

• Проверьте, не разрывает ли сеть динамические RPC‑порты (49152–65535).

Если dcdiag не показал ошибок, это не исключает проблем с Netlogon/Kerberos на уровне сессий — они часто видны только в логах Netlogon/Kerberos и в трассировках трафика.

Глубокая диагностика: команды и что смотреть в логах

Набор команд и пояснения, что искать:

• Общая проверка контроллеров и репликации:

repadmin /replsummary
repadmin /showrepl DC01
dcdiag /v /c /d /e

Что искать: накопленные ошибки репликации, отставания по High‑USN, ошибки исходящих/входящих соединений.

• Проверка secure channel с клиента:

Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Если Test-ComputerSecureChannel возвращает false, это признак рассинхронизации пароля компьютера.

• Сброс пароля учётной записи компьютера:

Reset-ComputerMachinePassword -Server "DC01.domain.local" -Credential (Get-Credential)
# или с netdom
netdom resetpwd /s:DC01 /ud:DOMAIN\Admin /pd:*

После сброса — перезагрузите клиент.

• Диагностика DNS/SRV:

nslookup -type=SRV _ldap._tcp.dc._msdcs.domain.local
nslookup DC01.domain.local

Ищите: оба DC показываются, алиасы корректны, IP соответствуют реальным.

• Netlogon и Kerberos логи

• Включите детальный Netlogon: измените DBFlag в реестре или временно перезапустите Netlogon с включённым логированием; смотрите %windir%\debug\netlogon.log.

• Анализируйте ошибки Kerberos (AS/TGS failures) в журнале безопасности и в C:\Windows\System32\winevt\Logs\ — при ошибках Kerberos будут сообщения о неудачных запросах/преаутентификации.

• Проверка SPN/дубликатов:

setspn -X
setspn -L HOST/CLIENTNAME

Дубликаты SPN могут ломать Kerberos и приводить к сбоям аутентификации.

• Сетевая трассировка (при необходимости)

• Снимите трафик Wireshark на клиенте и DC, фильтруя по kerberos, ldap, tcp.port==389/88. Ищите TCP‑RST, повторные попытки AS/TGS и ошибки KRB_AP_ERR.

• Быстрая проверка времени:

w32tm /query /status
w32tm /monitor

Ищите расхождения > 5 минут.

Если вы видите, что проблемы случаются пачками и иногда «само проходит», обратите внимание на сценарии с сетевыми разрывами, DNS‑scavenging, либо на процессы, которые периодически сбрасывают или меняют пароли учётных записей (скрипты, процедуры клонирования, неподходящие GPO).

Возможные причины (сценарии) и как их подтвердить

1. Пароль компьютерной учётной записи устарел/несинхронизирован

• Как подтвердить: Test-ComputerSecureChannel = false, Netlogon лог на клиенте показывает отказ при установке сессии. Сброс пароля на клиенте решает проблему.

2. Репликация между двумя контроллерами нестабильна или есть USN‑rollback

• Как подтвердить: repadmin /replsummary показывает ошибки, dcdiag выдаёт предупреждения, в Directory Service есть очевидные ошибки репликации. USN‑rollback часто сопровождается специфичными ошибками в журнале системных событий на DC.

3. Временные рассинхронизации (NTP/PDC)

• Как подтвердить: w32tm /query /status показывает разные источники/смещение > 5 мин.

4. DNS: не зарегистрированы SRV/неверный приоритет/«split brain»

• Как подтвердить: nslookup SRV возвращает только один DC или некорректные IP; клиенты «прыгают» между неконсистентными записями.

5. Kerberos: переполненный токен (много групп), SPN/делегирование, или ошибки KDC

• Как подтвердить: ошибки Kerberos в журнале безопасности; изучение статьи Microsoft по проблемам Kerberos (Kerberos authentication problems).

6. Виртуальные машины: восстановление из снапшота/клонирование DC или клиента

• Как подтвердить: недавние операции снапшотов; специфические ошибки File Replication/AD в журналах.

7. Сетевые устройства или политики (фильтрация RPC/эпhemeral портов)

• Как подтвердить: Test‑NetConnection показывает успешный ping, но сетевые сессии по RPC/Kerberos разрываются; сетевые логи на фаерволе показывают RST.

8. Сторонние процессы (скрипты, tools) массово сбрасывают пароли учетных записей компьютеров

• Как подтвердить: временные окна совпадают с задачами/скриптами, в логах изменения пароля видно от имени администратора.

Исправления: быстрые решения и массовые корректировки

Быстрый починить для отдельной машины (в порядке проб):

1. На клиенте (локально, под локальным администратором):

$cred = Get-Credential "DOMAIN\Admin"
Test-ComputerSecureChannel -Repair -Credential $cred
# если не помогло
Reset-ComputerMachinePassword -Server "DC01.domain.local" -Credential $cred
Restart-Computer

2. Если клиент не подключается к домену при попытке пере‑присоединения:

• Сбросьте учетную запись компьютера в Active Directory Users and Computers (ПКМ → Reset Account), затем на клиенте выполните Reset-ComputerMachinePassword или попробуйте снова зайти в домен.

3. Массовый ремонт (скрипт):

• С помощью PowerShell Remoting или SCCM можно выполнить Test-ComputerSecureChannel -Repair на списке машин. Пример:

$creds = Get-Credential "DOMAIN\Admin"
$computers = Get-Content C:\lists\computers.txt
Invoke-Command -ComputerName $computers -ScriptBlock {
 param($c)
 Test-ComputerSecureChannel -Repair -Credential $c
} -ArgumentList $creds -Credential $creds

(Учтите права и доступность WinRM.)

4. На контроллерах:

• Принудительно синхронизируйте репликацию: repadmin /syncall /AeD и проверьте repadmin /replsummary.
• Перерегистрируйте DNS на контроллерах: ipconfig /registerdns и перезапустите Netlogon.
• Убедитесь, что PDC‑эмулятор корректно синхронизирует время.

5. Если подозреваете USN‑rollback или проблемный DC:

• Не пытайтесь «ремонтировать» вручную без плана — USN‑rollback часто требует выведения контроллера из службы и восстановления из нормальной резервной копии или переустановки. Читайте руководство Microsoft и готовьте план восстановления (Domain controller not functioning correctly).

6. Если Kerberos/MaxTokenSize — временное решение:

• Увеличьте MaxTokenSize в реестре на клиенте/сервере или оптимизируйте членства в группах; подробности в документе Microsoft (Kerberos authentication problems).

Замечание: удаление компьютера из домена и повторный join — крайний вариант. Часто безопаснее сбросить пароль учётной записи и выполнить Reset-ComputerMachinePassword.

Профилактика и мониторинг

• Настройте мониторинг репликации AD (repadmin /replsummary), Netlogon/Керберос ошибок и событий, которые указывают на потерю доверия.
• Убедитесь, что PDC‑эмулятор синхронизируется с надёжным NTP; остальные контроллеры и клиенты синхронизируются с PDC.
• Сделайте зоны DNS AD‑integrated, настройте корректную политику очистки (scavenging) и контролируйте динамическую регистрацию SRV.
• Запретите восстановление DC из снапшотов; используйте поддерживаемые методы резервного копирования/восстановления.
• Документируйте процедуры клонирования/имиджирования рабочих станций так, чтобы не было конфликтов machine account password.
• Разверните периодическую проверку secure channel (скрипт/задача), если в прошлом были массовые отказы.
• При масштабных проблемах подумайте о внедрении централизованного решения для управления паролями машин (LAPS для локальных админ‑паролей — не для machine account, но хорошая практика безопасности).

Источники

• Доверие между доменом Windows NT и доменом Active Directory невозможно установить или не работает должным образом - Windows Server | Microsoft Learn
• Контроллер домена работает неправильно - Windows Server | Microsoft Learn
• Восстанавливаем доверительные отношения в домене - Записки IT специалиста
• Восстановление доверительных отношений между рабочей станцией и доменом AD | Windows для системных администраторов
• Устранение неполадок сети при присоединении компьютеров под управлением Windows к домену - Windows Server | Microsoft Learn
• Руководство по устранению неполадок при присоединении к домену Active Directory - Windows Server | Microsoft Learn
• Проблемы проверки подлинности Kerberos - Windows Server | Microsoft Learn

Заключение

Коротко: если компьютеры периодически теряют доверие, начните с трёх базовых вещей — время, репликация AD/DNS и secure channel. Проверьте синхронизацию времени PDC, убедитесь в корректности SRV‑записей dns active directory, включите Netlogon/Kerberos‑логирование и прогоните Test-ComputerSecureChannel/Reset-ComputerMachinePassword или nltest/repadmin. Если репликация или USN‑rollback — сначала исправляйте контроллеры; массовый сброс паролей машин без решения репликации только отложит проблему. Схема действий и команды в тексте помогут локализовать причину и выбрать безопасный путь восстановления.