Ошибка «Нарушены доверительные отношения между этой рабочей станцией и основным доменом» означает, что доменный компьютер не смог подтвердить secure channel с Active Directory. Чаще всего локальный пароль учетной записи компьютера не совпадает со значением на контроллере домена, объект компьютера был изменен или устройство обращается не к тому контроллеру из-за DNS, времени, сети либо репликации.

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

Что подготовить до исправления

  • локальную учетную запись администратора с проверенным паролем;
  • ключ восстановления BitLocker, если диск зашифрован;
  • резервную копию важных локальных данных и настроек пользователя;
  • имя домена, имя компьютера и адрес доступного контроллера домена;
  • доменную учетную запись с правом восстановить канал или сбросить пароль компьютера;
  • доступ к консоли, гипервизору или out-of-band управлению для удаленного сервера;
  • понимание, является устройство обычным членом домена или контроллером домена.

Команды Test-ComputerSecureChannel предназначены для компьютеров-членов домена. Microsoft отдельно предупреждает, что на контроллерах домена этот cmdlet может возвращать ложный результат; для DC нужна отдельная диагностика AD, репликации и Netlogon. Не применяйте сценарий рабочей станции к контроллеру домена.

Сначала определите масштаб проблемы

Если ошибка появилась на одном ноутбуке после восстановления снимка или замены объекта компьютера, вероятнее локальный разрыв машинного пароля. Если одновременно перестали входить десятки устройств, сначала проверяйте контроллеры домена, DNS, время, сеть и репликацию. Массовый вывод компьютеров из домена только увеличит простой.

  • ошибка только у одного компьютера или у целого офиса;
  • другие доменные пользователи могут войти на этом устройстве;
  • работает ли вход с кэшированными учетными данными без сети;
  • доступен ли DC по имени и обнаруживается ли домен через DNS;
  • не восстанавливали ли VM из старого snapshot или backup;
  • не удаляли, не сбрасывали и не создавали ли заново объект компьютера в AD;
  • нет ли второго устройства с тем же именем;
  • исправна ли репликация между контроллерами в разных площадках.

Почему компьютер теряет доверие к домену

Машинный пароль не совпадает

У доменного компьютера есть собственная учетная запись и секрет, которым он подтверждает связь с контроллером. Windows периодически меняет машинный пароль. Если локальное значение и запись в Active Directory расходятся, Netlogon не может построить secure channel. Это возможно после отката виртуальной машины, неудачного восстановления, ручного сброса объекта или конфликтующей автоматизации.

Объект компьютера удален, отключен или заменен

Создание нового объекта с тем же именем не возвращает прежнее доверие: у объекта другая внутренняя идентичность и пароль. Аналогично действует отключение или сброс учетной записи компьютера без синхронного обновления на рабочей станции. Сначала выясните, кто и когда изменил объект.

DNS указывает не на доменные серверы

Active Directory зависит от DNS-записей SRV. Если клиент использует публичный DNS напрямую, получает старый адрес DC или подключается через VPN без доменной DNS-зоны, поиск контроллера и Kerberos могут завершиться ошибкой, похожей на потерю доверия. Публичные резолверы настраивают как forwarders на DNS-серверах, а не как основной DNS доменного клиента.

Время заметно расходится

Kerberos чувствителен к разнице времени. Неверная дата, сломанная иерархия NTP, пауза VM или ручная настройка часов мешают доменной аутентификации. До сброса машинного пароля проверьте часовой пояс, источник времени и фактическое расхождение с доменом.

Контроллер недоступен или репликация нарушена

Клиент может обратиться к DC, который не знает о последнем изменении объекта либо не может проверить канал из-за сети, firewall, VPN или сбоя Netlogon. Если восстановление работает при явном указании одного контроллера, но снова ломается с другим, нужно исправлять репликацию и топологию сайтов, а не повторять ремонт на компьютере.

Пошаговая диагностика

1. Войдите локальным администратором

Используйте локальную учетную запись в формате .\Administrator или ИМЯ-ПК\локальный_администратор. Если локальный пароль неизвестен, не начинайте эксперименты с выводом из домена: после перезагрузки можно потерять административный доступ. В управляемой среде заранее применяйте Windows LAPS для безопасного хранения локальных паролей.

2. Проверьте имя, сеть и DNS

hostname ipconfig /all nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local nltest /dsgetdc:example.local

В выводе ipconfig проверьте DNS-серверы активного адаптера. SRV-запрос должен возвращать актуальные контроллеры, а nltest — находить DC нужного домена. Не делайте вывод только по ping: ICMP может быть запрещен, а нужные службы доступны, либо наоборот.

3. Проверьте время

w32tm /query /status w32tm /query /source w32tm /stripchart /computer:dc01.example.local /dataonly /samples:5

Если источник времени неверный или расхождение существенно, сначала восстановите синхронизацию по политике вашей организации. Не назначайте каждому клиенту случайный внешний NTP: доменные компьютеры должны следовать иерархии времени Active Directory.

4. Проверьте secure channel

Test-ComputerSecureChannel -Verbose # Проверка через Netlogon nltest /sc_verify:example.local

Test-ComputerSecureChannel возвращает True, если канал исправен, и False при нарушении. Ошибка «домен не существует или с ним невозможно связаться» сначала указывает на DNS, сеть или доступность DC, а не обязательно на рассинхронизацию машинного пароля. Сохраните подробный вывод и время проверки.

5. Проверьте объект компьютера и события

  • объект существует в правильном OU, включен и имеет ожидаемое имя;
  • нет второго активного устройства с тем же именем;
  • дата изменения объекта согласуется с историей работ;
  • в System log клиента есть события Netlogon, Kerberos, GroupPolicy или Time-Service;
  • на DC нет массовых ошибок регистрации DNS, репликации и аутентификации;
  • выбранный DC относится к правильному сайту и имеет актуальные данные.

Как восстановить secure channel без вывода из домена

Если DNS, время и связь с DC исправны, а тест канала возвращает False, выполните штатный ремонт от имени локального администратора. Учетные данные запрашивайте через Get-Credential, не записывайте пароль в команду, скрипт или журнал. При необходимости явно укажите исправный контроллер.

$cred = Get-Credential 'EXAMPLE\domain-admin' Test-ComputerSecureChannel -Repair -Server 'dc01.example.local' -Credential $cred -Verbose

Команда перестраивает канал Netlogon. После успешного ответа повторите Test-ComputerSecureChannel без Repair и перезагрузите компьютер в согласованное окно. Затем проверьте доменный вход, Group Policy и доступ к ресурсам.

Сброс машинного пароля

Если Repair не помог, можно сбросить пароль учетной записи локального компьютера на выбранном DC. Это не пароль пользователя и не пароль локального администратора. Команда применяется на компьютере-члене домена при рабочей сети и корректной DNS-конфигурации.

$cred = Get-Credential 'EXAMPLE\domain-admin' Reset-ComputerMachinePassword -Server 'dc01.example.local' -Credential $cred Restart-Computer

После перезагрузки снова проверьте secure channel. Если операция проходит только через один DC, а после обращения к другому ошибка возвращается, остановитесь и диагностируйте репликацию Active Directory. Последовательный сброс через разные контроллеры способен скрыть первопричину и создать новые расхождения.

Когда действительно нужно переприсоединение к домену

Вывод в рабочую группу и повторное присоединение — последний вариант, когда объект поврежден, штатный ремонт не выполняется, а DNS, время, сеть и репликация проверены. До начала убедитесь в наличии локального администратора, резервной копии, ключа BitLocker и окна перезагрузки. Для удаленного устройства нужен доступ к консоли и рабочий путь до DC после перезапуска.

  1. Запишите текущее имя компьютера, OU, группы объекта и применяемые политики.
  2. Сохраните важные локальные данные и убедитесь, что профиль пользователя доступен.
  3. Выведите компьютер из домена штатной командой или интерфейсом с авторизованными учетными данными.
  4. Перезагрузите устройство и войдите локальным администратором.
  5. Проверьте DNS и связь с DC до повторного присоединения.
  6. Присоедините компьютер к домену и при необходимости переместите объект в правильный OU.
  7. Снова перезагрузите, проверьте доменный вход, профиль, GPO, сертификаты и доступы.

Не удаляйте старый профиль пользователя. После повторного входа Windows может создать временный или новый профиль, если SID, права каталога или ProfileList обработаны неправильно. Исправляйте привязку профиля отдельно и только после резервного копирования.

Особые случаи

Виртуальная машина восстановлена из snapshot

Снимок мог вернуть старый машинный пароль и состояние системы. Зафиксируйте время snapshot, выбранный DC и изменения после восстановления. После ремонта запретите использование старого снимка как постоянного способа отката доменных машин и настройте корректное резервное копирование.

Компьютер долго не подключался к офисной сети

Долгое отсутствие само по себе не обязано ломать доверие. Проверьте, не сбрасывался ли объект, не переиспользовалось ли имя и доступен ли домен через VPN до входа пользователя. Ошибка часто появляется не из-за возраста ноутбука, а из-за изменений, выполненных пока он был офлайн.

Клон или образ развернут с тем же именем

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

Ошибка возникла сразу у многих устройств

Проверьте состояние DC, DNS, синхронизацию времени, Sites and Services, репликацию и последние изменения firewall или VPN. Не запускайте массовый Test-ComputerSecureChannel -Repair, пока не доказано, что проблема на клиентах. Иначе ремонт может создать нагрузку и скрыть общий отказ инфраструктуры.

Как проверить результат

  • Test-ComputerSecureChannel возвращает True на компьютере-члене домена;
  • nltest /sc_verify подтверждает канал с ожидаемым доменом;
  • nltest /dsgetdc находит контроллер правильного сайта;
  • вход доменного пользователя проходит после перезагрузки при доступной сети;
  • gpupdate выполняется без ошибок поиска DC и проверки учетной записи;
  • открываются доменные ресурсы, требующие Kerberos или NTLM по вашей политике;
  • в System log не появляются новые ошибки Netlogon и Time-Service;
  • результат сохраняется при обращении к другим исправным DC после репликации.

Успешный вход с кэшированными данными не доказывает исправность домена. Проверяйте secure channel и доступ к контроллеру отдельно. Аналогично, один ответ True не закрывает инцидент, если ошибка повторяется после смены сети или выбора другого DC.

Типичные ошибки при восстановлении доверия

  • сразу удалять компьютер из домена без локального администратора;
  • сбрасывать объект компьютера в AD и не обновлять секрет на клиенте;
  • указывать публичный DNS на доменном компьютере;
  • проверять доступность DC только командой ping;
  • игнорировать время и репликацию между контроллерами;
  • запускать Test-ComputerSecureChannel на контроллере домена;
  • вставлять доменный пароль открытым текстом в скрипт;
  • ремонтировать десятки клиентов при общем сбое DNS или DC;
  • клонировать уже присоединенную к домену машину без подготовки;
  • удалять пользовательский профиль после повторного присоединения.

Как предотвратить повторение

  • доменным клиентам назначается только корпоративный DNS с корректными forwarders;
  • иерархия времени AD контролируется и не переопределяется случайными NTP-настройками;
  • репликация, DNS и службы контроллеров домена имеют мониторинг и оповещения;
  • локальные административные пароли управляются через Windows LAPS;
  • объекты компьютеров не удаляются автоматически без периода карантина и журнала изменений;
  • VM и образы восстанавливаются по документированной процедуре;
  • имена устройств уникальны, а повторное использование контролируется;
  • ремонт secure channel выполняется адресно и фиксируется в системе изменений;
  • для удаленных ноутбуков предусмотрен VPN до входа и доступ к доменной DNS-зоне.

Когда нужна помощь с Active Directory

Если компьютер потерял доверие к домену, я могу проверить DNS, время, поиск DC, secure channel, машинный пароль, объект компьютера, Netlogon и репликацию, затем восстановить связь без лишнего пересоздания профиля. Для оценки пришлите версию Windows, роль устройства, имя домена и DC в обезличенном виде, вывод Test-ComputerSecureChannel -Verbose, nltest /dsgetdc, w32tm /query /status и коды событий без паролей, ключей BitLocker и персональных данных.