Восстановить доверительные отношения между рабочей станцией и доменом AD

Если рабочая станция Windows теряет доверительные отношения с доменом Active Directory, компьютер не может установить безопасный канал с контроллером домена, а доменные пользователи не смогут авторизоваться на таком компьютере. В этой статье мы рассмотрим, причины выпадания компьютеров из домена и простой способ восстановить доверительные отношения компьютера с доменом без перезагрузок

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом

Если компьютер вылетел из домена, при попытке входе на такой компьютер под доменным пользователем появится ошибка:

The trust relationship between this workstation and the primary domain failed.

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом.

Также ошибка может выглядеть так:

The security database on the server does not have a computer account for this workstation trust relationship.

База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией.

Восстановить доверительные отношений компьютера с доменом с помощью PowerShell

Обычно, администраторы в такой ситуации просто выводят компьютер из домена и добавляют его в AD повторно. Это способ рабочий – но требует много времени и нескольких перезагрузок. Гораздо проще восстановить доверительные отношения рабочей станции с домена с помощью PowerShell.

Для восстановления доверительных отношений с доменом, нужно войти на компьютер локально с учетной записью с правами администратора. Это может быть локальный пользователь с правами администратора, или встроенный администратор Windows (можно сбросить пароль локального администратора , если вы его не знаете).

Для входа под локальным пользователем, нужно на экране пользователя указать его имя в формате: .localuser . Точка в начале указывает, что нужно использовать локальную базу учетных записей.

Откройте консоль PowerShell с правами администратора и проверьте наличие доверительных отношений компьютера с доменом AD:

Test-ComputerSecureChannel -Verbose

Если пароли не совпадают и компьютер не может установить доверительные отношения с доменом, команда вернет значение False – The Secure channel between the local computer and the domain remontka.com is broken .

Для восстановления доверительных отношений компьютера с доменом, выполните команду:

Test-ComputerSecureChannel -Repair -Credential remontkaadministrator -Verbose

Если компьютер сможет подключиться к DC, установить новый пароль для своей учетной записи и тем самым восстановить доверительные отношения с AD, появится сообщение:

True. The secure channel between the local computer and the domain contoso.com was successfully repaired.

Проверьте, что доверительные отношения были успешно восстановлены. Выполните команду Test-ComputerSecureChannel и убедится, что она возвращает True ( The Secure channel between the local computer and the domain remontka.com is in good condition ). Завершите сеанс и войдите на компьютер под доменным пользователем (перезагрузка не требуется).

Также для принудительного сброса и синхронизации пароля компьютера можно использовать команду:

Reset-ComputerMachinePassword -Server dc01.corp.remontka.com -Credential corpdomain_admin

В некоторых случаях команда восстановления доверительных отношений может возвращать ошибку:

The attempt to repair the secure channel between the local computer and the domain contoso.com has failed.

В этом случае нужно проверить, что домен доступен, а учетная запись вашего компьютера в домене существует, не отключена и у вас есть права на нее. Получить имя своего компьютера командой hostname , откройте консоль Active Directory Users and Computers ( dsa.msc ) и найдите учетную запись этого компьютера. В нашем примере она отключена. Включите ее.

Пароль учетной записи компьютера в домене Active Directory

Почему могут пропадать доверительные отношения между компьютером и доменом?

Когда компьютер вводится в домен Active Directory , для него создается отдельная учетная запись типа computer. У каждого компьютера в домене есть свой пароль, который необходим для аутентификации компьютера в домене и установления доверенного подключения к контроллеру домена. Этот пароль хранится локально на компьютере (в ветке реестра HKLMSECURITYPolicySecrets$machine.ACC ) и в базе AD и по-умолчанию меняется автоматически раз в 30 дней (задается настройками политики Domain member : Maximum machine account password age ).

Срок действия пароля компьютера не истекает в отличии от паролей пользователей. Смену пароля инициирует компьютер, а не контроллер домена.

Если хэш пароля, который компьютер отправляет контроллеру домена не совпадает с паролем учетной записи компьютера, компьютер не может установить защищённое подключение к DC.

Почему это может произойти?

1. Самая частая проблема. Компьютер был восстановлен из старой точки восстановления или снапшота (если это виртуальная машина), созданной раньше, чем был изменен пароль компьютера в AD. Т.е. пароль в снапшоте отличается от пароля компьютера в AD. Перед созданием снапшота рекомендуется принудительно выполнить смену пароля компьютера в домене: nltest.exe /sc_change_pwd:remontka.loc
2. Компьютер был склонирован без выполнения sysprep;
3. В AD создан новый компьютер с тем же именем, или кто-то сбросил аккаунт компьютера в домене через консоль ADUC;
4. Учетная запись компьютера в домене заблокирована администраторам (например, во время регулярной процедуры отключения неактивных объектов AD );
5. Довольно редкий случай, когда сбилось системное время на компьютере или Windows не может синхронизировать время с внешним источником .

Для тестовых ВМ, которые приходится часто восстанавливать из снапшотов с помощью параметра GPO можно отключить регулярную смену паролей (параметр Domain member : Disable machine account password changes в секции Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options).