Короткий ответ
Сообщение про «доверительные отношения» означает: пароль компьютерной учётки в AD и локальный секрет Netlogon разъехались. Если DC находится (nltest /dsgetdc), чините канал: Test-ComputerSecureChannel -Repair или nltest /sc_reset. Повторный join — запасной путь: он меняет SID компьютера и ломает часть локальных профилей/GPO фильтрацию.
Не делайте Repair, если DC locator не работает: вы смените локальный секрет и не запишете его в AD.
Симптомы и отличия
Текст Windows: доверительные отношения нарушены. Часто после:
- отката VM/снимка рабочей станции;
- долгого офлайна (пароль компьютера ротируется, по умолчанию порядка 30 дней);
- клонирования без sysprep;
- ручного reset учётки компьютера в ADUC без синхронизации с машиной.
Отличия от клиент не входит: там DC может быть не найден. Здесь DC обычно находится, но Netlogon не устанавливает канал. Отличия от недоступного DC: остальные компьютеры сайта входят.
Возможные причины
- Ротация пароля компьютера прошла в AD, машина была выключена.
- Администратор нажал Reset Account в ADUC.
- Два клона с одним именем: они перезаписывают пароль друг друга.
- Восстановление ПК из backup старше, чем пароль в AD.
- Репликация AD: вы сбросили пароль на DC01, машина ходит на DC02 со старым значением. Редко, но проверяемо.
Диагностика
Нужна локальная админская учётка (не доменная, если логон уже закрыт).
nltest /dsgetdc:contoso.example /force
nltest /sc_query:contoso.example
nltest /sc_verify:contoso.example
Test-ComputerSecureChannel -VerboseУспешный locator + failed channel = эта статья.
На DC (с другой админской станции):
Get-ADComputer 'WS-042' -Properties PasswordLastSet, Enabled, LastLogonDateСравните PasswordLastSet с моментом отката/клона.
Ищите дубли имён:
Get-ADComputer -Filter "Name -eq 'WS-042'"Должна быть одна учётка. Две OU с похожими именами — проверьте DN.
Решение
Repair канала (предпочтительный)
Машина должна резолвить DC. Учётка для Repair — с правом Reset Password на объект компьютера (типично Domain Admins или делегированная).
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
nltest /sc_verify:contoso.exampleАльтернатива:
nltest /sc_reset:contoso.exampleПерезагрузка после успешного verify — желательна.
Репликация после Reset Account в ADUC
Если кто-то нажал Reset Account, AD уже сменила пароль. Repair с машины должен записать согласованный секрет. Если репликация AD сломана, машина может попасть на DC без нового пароля — сначала репликация.
Join заново
Когда Repair невозможен (учётка удалена, SID-дубли):
- Сохраните список групп компьютера и локальные данные профиля.
Remove-Computer/ GUI с локальным админом.- Добавьте с тем же именем только если объект очищен или переиспользован осознанно.
- Верните группы компьютера.
Это не «быстрее Repair». Это другой SID компьютера.
Клоны
Оставьте один эталон, остальные — sysprep generalize до ввода в домен. Не лечите клоны бесконечным Repair.
Проверка
nltest /sc_query:contoso.example
nltest /sc_verify:contoso.example
gpresult /rВход доменного пользователя, который не кэшировался. Доступ к \\<домен>\netlogon.
Если не помогло
- Access denied на Repair: нет прав на объект или DC не тот.
- Канал зелёный, логон всё равно нет: профиль или блокировка пользователя — не канал.
- Сервер сам является DC: не применяйте эту процедуру к NTDS; «доверие» DC — другая диагностика.
Типовые сценарии восстановления
Ноутбук вернулся из отпуска. Пароль компьютера в AD уже ротировался. Locator жив, Repair с LAPS-админом обычно достаточен. После входа проверьте, что LAPS сам обновил локальный пароль, если политика это делает при логоне.
Сбросили учётку в ADUC «потому что не входила». Канал гарантированно сломан. Repair с машины обязателен. Сообщите, кто нажал Reset — иначе через неделю повторят.
Две VM из одного шаблона. В журнале Netlogon будут взаимные 5722. Выключите одну, Repair на оставшейся, вторую пересоздайте через sysprep. Пока обе в сети, лечение бессмысленно.
Restore файлов ПК из backup. Локальный секрет Netlogon откатился, AD — нет. Это тот же класс, что snapshot. Repair. Если backup старше 30+ дней и учётка компьютера пересоздавалась — может понадобиться join.
После любой ветки не забудьте GPO: компьютер мог пропустить политики, пока канал был мёртв. gpupdate /force и сверка gpresult /r с эталоном OU.
Если Repair пишет, что DC недоступен, вернитесь к DNS/сети. Продолжать Reset Account в этот момент — ухудшение.
Что проверить после Repair, кроме nltest
Откройте \\contoso.example\netlogon с этой машины. Отказ SMB при зелёном канале часто значит, что вы починили Netlogon, но DNS суффикс или firewall клиента режет 445. Это уже не доверие, но пользователь скажет «всё равно не работает».
Проверьте планировщик: задачи от SYSTEM, ходившие в AD, могли накопить ошибки. И службы, зависящие от компьютера (SCCM-агент, старый антивирус с машинным сертификатом) — их перезапуск после канала обязателен.
Если LAPS используется, после join заново пароль локального админа в AD может не совпасть с локальным, пока не отработает политика. Не оставляйте единственный вход «тот пароль, что был вчера».
Профилактика
- Запрет клонирования доменных ПК без sysprep.
- Не держать VM рабочих станций на snapshot месяцами.
- Не жать Reset Account «для профилактики».
- Мониторить всплеск 5722.
FAQ
Reset Account в ADUC — это то же, что Repair?
Нет. Reset Account ломает канал намеренно. Repair пытается согласовать секреты. Делать оба подряд без понимания — путь к повторному join.
Нужно ли удалять ПК из группы Domain Computers?
Нет для Repair. Domain Computers — стандартное членство.
Помогает ли переименование ПК?
Обычно нет и добавляет новый объект. Не используйте как лечение канала.
Что с локальными профилями после повторного join?
SID компьютера новый, пользовательский SID тот же. Часто профиль жив, но некоторые ACL и сетевые принтеры «отваливаются». Копируйте данные заранее.
Можно ли Repair удалённо через WinRM?
Да, если WinRM ещё пускает локального/кэшированного админа. Если логон домена мёртв, нужен другой канал: консоль, LAPS, дауншифтовый локальный админ.