Если рабочая станция 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 winitpro.ru is broken
.
Для восстановления доверительных отношений компьютера с доменом, выполните команду:
Test-ComputerSecureChannel -Repair -Credential winitpro\administrator -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 winitpro.ru is in good condition
). Завершите сеанс и войдите на компьютер под доменным пользователем (перезагрузка не требуется).
Также для принудительного сброса и синхронизации пароля компьютера можно использовать команду:
Reset-ComputerMachinePassword -Server dc01.corp.winitpro.ru -Credential corp\domain_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. У каждого компьютера в домене есть свой пароль, который необходим для аутентификации компьютера в домене и установления доверенного подключения к контроллеру домена. Этот пароль хранится локально на компьютере (в ветке реестра
HKLM\SECURITY\Policy\Secrets\$machine.ACC
) и в базе AD и по-умолчанию меняется автоматически раз в 30 дней (задается настройками политики Domain member: Maximum machine account password age).
Срок действия пароля компьютера не истекает в отличии от паролей пользователей. Смену пароля инициирует компьютер, а не контроллер домена.
Если хэш пароля, который компьютер отправляет контроллеру домена не совпадает с паролем учетной записи компьютера, компьютер не может установить защищённое подключение к DC.
Почему это может произойти?
- Самая частая проблема. Компьютер был восстановлен из старой точки восстановления или снапшота (если это виртуальная машина), созданной раньше, чем был изменен пароль компьютера в AD. Т.е. пароль в снапшоте отличается от пароля компьютера в AD. Перед созданием снапшота рекомендуется принудительно выполнить смену пароля компьютера в домене:
nltest.exe /sc_change_pwd:winitpro.loc - Компьютер был склонирован без выполнения sysprep;
- В AD создан новый компьютер с тем же именем, или кто-то сбросил аккаунт компьютера в домене через консоль ADUC;

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


не помогло.
Netdom отработал, но ошибка осталась.
Точно помог командлет из совета.
Который Test-ComputerSecureChannel
Спасибо большое за статью.
Похоже для древних динозавров (WinServer 2003) подойдёт только первый способ.
Название темы «Восстановление доверительных отношений без повторного ввода в домен»
одно из решений : Вывести ПК из домена и включить его в рабочую группу
странно..
Привет. Гарантировано работает. Проверял на себе. DC — winserv 2003, машина win 8.1 и что-то там побилось.
Из статьи все способы не работают. Пауэршел ругается и не дает сбросить пароль компьютера, врукопашную вывел/завел в домен все отработало штатно.
При попытке выполнить операцию неверное имя пользователя или пароль. Хотя с этими данными на контроллер домена вхожу.
Укажите, какую команду точно вы вводите для восстановления доверительных отношений.
Столкнулся с данной проблемой на виртуальном полигоне после восстановления контроллера домена из снапшота. Помог способ с утилитой netdom. Спасибо!
А удаленно командлет можно запустить, или надо обязательно ногами идти, чтобы под локальным админом залогиниться?
По идее можно через Enter-PSSession под локальной учетной с правами админа:
Enter-PSSession -ComputerName comp101 -Credential comp101\localadminВыполнение Enter-PSSession невозможно при потере доверительных отношений, пробовал, выходит ошибка. Подключиться по RDP невозможно, так как на удаленное подключение стоит галка проверки LNA, снять которую можно только под админом. А компьютер за 600 км от меня. Так что замкнутый круг.
Доброго дня!
Подскажите, как восстановить доверительные отношения с отключенным аккаунтом локального администратора (пароль от него есть)?
Тут наверно только загрузиться с любого загрузочного диска и включить аккаунта администратора (если другого нет).
Если есть физический доступ к компютеру…
1. Отключаем сетевой кабель.
2. Входим в ОС под «старыми данными» доменного пользователя
3. Подключаем сетевой кабель
4. Включаем локального админа/Меняем пароль если утерян.
5. Входим под учеткой локального админа
6. Выводим/Вводим в домен компьютер
Спасибо, Автор, за помощь! И разреши подробнее разъяснить написанное тобой:
команда для PowerShell будет
Reset-ComputerMachinePassword -Server dc-XXX -Credential YYY\PetrovAA
Имя КД Учётка админа домена
под локальным админом на команду Test-ComputerSecureChannel –verbose выдает что все нормуль
ПОДРОБНО: Выполнение операции «Test-ComputerSecureChannel» над целевым объектом «comp01».
True
ПОДРОБНО: Безопасный канал между локальным компьютером и доменом test.local находится в хорошем состоянии.
в cmd на команду C:\>Nltest /sc_verify:test.local
Ошибка в I_NetLogonControl: Status = 5 0x5 ERROR_ACCESS_DENIED
доступ запрещен, почему?
С ходу не отвечу. Пробовали перегрузить компьютер и поглядеть ошибки в логах?
Из-под админа делали?
Спасибо большое. Помогло
Супер, спасибо!
Сэкономил кучу времени 😉 Взял на заметку, записал в записную книжку.
Test-ComputerSecureChannel — Выдает True, однако ошибку The security database on the server does not have a computer account for this workstation trust relationship. — это не исправляет, почему?
У вас один домен или есть и другие домены в лесу?
Попробуйте принудительно сбросить пароль командой:
Reset-ComputerMachinePassword -Server dc01.corp.winitpro.ru -Credential corp\domain_adminРебут, и затем посмотрите что выдают команды:
Get-ADComputer –Identity tut_vash_computername -Properties PasswordLastSetи
nltest /sc_verify:corp.winitpro.ruБольшое спасибо, помогло
Вот еще интересная ситуация, привезли ноут который в домен лет пять не смотрел. При входе под любой доменной учеткой «База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией.» Т.к. там диск был полуживой, решил переустановить винду на новый SSd. Учетную запись ноута в домене грохнул. Имя присвоил тоже. И после переустановки та же ошибка. Все шаги проделаны. Все тесты показывают, что доверительные отношения true. Ну и после переименования ноута завалил в домен без проблем. Т.е. есть где то в AD «база данных диспетчера»……
можно слегка извратиться. Большинство доменов называют типа domain.local или domain.LAN. Заходим в оснастку для переименования компьютера, вкладка «имя компьютера» -> «Изменить» -> и там, где указано полное имя домена, меняем его на NetBIOS-имя (удаляем .local или .LAN). Жмём ОК, вводим логин пароль админа, после удачного завершения операции отказываемся от немедленной перезагрузки (домен фактически тот же!)
В свойствах системы (теперь это дополнительные параметры системы), на вкладке Имя компьютера, есть кнопка Идентификация. С ее помощью можно вернуть комп в домен.
Помогло, спасибо)
Здравствуйте!
А как найти причину постоянных вылетов из домена раз в 30 дней? Если за связность отвечает RODC, который работает в двумя PDC (у меня нет к ним доступа).
Судя по описанию, нужно добавить компьютер в группу Allowed RODC Password Replication
For the client computer to be able to establish a secure channel with the RODC, its current credentials must be cached on the RODC._https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754218(v=ws.10)?redirectedfrom=MSDN
Зачем так усложнять, что-то прописывать из повер шел. 1 Заходите в локального админа. 2 в свойствах моего компьютера (там где переименовать ПК) нажимаете идентификация. 3 далее далее готово. 4 после вводите имя пользователя который потерялся, пароль, адрес своего домена 5 домен компьютер находит, соглашаетесь. 6 в конце предложит добавить пользователя (делать этого не надо т.к он есть на сервере) 7 после всего потребуется перезагрузка. После этого доверительные отношения будут восстановлены
Петр, большое спасибо!
дружище ты не прав, люди не дураки. такая фишка которую ты описал не делается на серверах, там нет этой кнопrи идентификации, по крайней мере на windows server 2019 std
спасибо огромное, после статьи выявил что ошибка доверительных отношений проявилась, когда создали 2 компа с одинаковым именем и ввели в домен, ещё раз огромное спасибо
Спасибо помогло! интересно почему такая возникла ошибка , все работало и на тебе, хорошо что в инете есть добрые люди которые это все описали и выяснили что делать и поделились )