The trust relationship between this workstation ошибка

В этой статье мы рассмотрим проблему нарушения доверительных отношений между рабочей станцией и доменом 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.

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

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

Когда компьютер вводится в домен Active Directory, для него создается отдельная учетная запись типа computer. У каждого компьютера в домене, как и у пользователей есть свой пароль, который необходим для аутентификации компьютера в домене и установления доверенного подключения к контроллеру домена. Однако, в отличии от паролей пользователя, пароли компьютеров задаются и меняются автоматически.

Несколько важных моментов, касающихся паролей компьютеров в AD:

• Компьютеры должны регулярно (по-умолчанию раз в 30 дней) менять свои пароли в AD.

  Совет. Максимальный срок жизни пароля может быть настроен с помощью политики Domain member: Maximum machine account password age, которая находится в разделе: Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> Security Options. Срок действия пароля компьютера может быть от 0 до 999 (по умолчанию 30 дней).

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

  Даже если компьютер был выключен более 30 дней, его можно включить, он нормально аутентифицируется на DC со старым паролем, и только после этого локальная служба
  Netlogon
  изменит пароль компьютера в своей локальной базе (пароль хранится в ветке реестра HKLMSECURITYPolicySecrets$machine.ACC) и затем в аккаунте компьютера в Active Directory.
• Пароль компьютера меняется на ближайшем DC, эти изменения не отправляются на контроллера домена с FSMO ролью эмулятора PDC (т.е. если компьютер сменил пароль на одном DC, то он не сможет авторизоваться на другом DC, до момента выполнения репликации изменений в AD).

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

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

1. Самая частая проблема. Компьютер был восстановлен из старой точки восстановления или снапшота (если это виртуальная машина), созданной раньше, чем был изменен пароль компьютера в AD. Т.е. пароль в снапшоте отличается от пароля компьютера в AD. Если вы откатите такой компьютер на предыдущее состояние, это компьютер попытается аутентифицироваться на DC со старым паролем.
2. В AD создан новый компьютер с тем же именем, или кто-то сбросил аккаунт компьютера в домене через консоль ADUC;
3. Учетная запись компьютера в домене заблокирована администраторам (например, во время регулярной процедуры отключения неактивных объектов AD);
4. Довольно редкий случай, когда сбилось системное время на компьютере.

Классический способ восстановить доверительных отношений компьютера с доменом в этом случае:

1. Сбросить аккаунт компьютера в AD;
2. Под локальным админом перевести компьютер из домена в рабочую группу;
3. Перезагрузить компьютер;
4. Перезагнать компьютер в домен;
5. Еще раз перезагрузить компьютер.

Этот метод кажется простым, но слишком топорный и требует, как минимум двух перезагрузок компьютера, и 10-30 минут времени. Кроме того, могут возникнуть проблемы с использованием старых локальных профилей пользователей.

Есть более элегантный способ восстановить доверительные отношения с помощью PowerShell без перевключения в домен и без перезагрузок компьютера.

Проверка и восстановление доверительного отношения компьютера с доменом с помощью PowerShell

Если вы не можете аутентифицироваться на компьютере под доменной учетной записью с ошибкой “Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом”, вам нужно войти на компьютер под локальной учетной записью с правами администратора. Также можно отключить сетевой кабель и авторизоваться на компьютере под доменной учетной записью, которая недавно заходила на этот компьютер, с помощью кэшированных учетных данных (Cached Credentials).

Откройте консоль PowerShell и с помощью командлета Test-ComputerSecureChannel проверьте соответствует ли локальный пароль компьютера паролю, хранящемуся в AD.

Test-ComputerSecureChannel –verbose

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

Чтобы принудительно сбросить пароль учётной записи данного компьютера в AD, нужно выполнить команду:

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

Для выполнения операции сброса пароля нужно указать учетную запись и пароль пользователя, у которого достаточно полномочий на сброс пароля учетной записи компьютера. Этому пользователя должны быть делегированы права на компьютеры в Active Directory (можно использовать и члена группы Domain Admins, но это не комильфо).

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

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

С помощью командлета Get-ADComputer (из модуля Active Directory Windows PowerShell) можно проверить время последней смены пароля компьютера в AD:

Get-ADComputer –Identity spb-pc22121 -Properties PasswordLastSet

Также можно проверить наличие безопасного канала между компьютером и DC командой:

nltest /sc_verify:corp.winitpro.ru

Следующие строки подтверждают, что доверительные отношения были успешно восстановлены:

Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success

Восстановления доверия с помощью утилиты Netdom

В Windows 7/2008R2 и предыдущих версиях Windows, на которых отсутствует PowerShell 3.0, не получится использовать командлеты Test-ComputerSecureChannel и Reset-ComputerMachinePassword для сброса пароля компьютера и восстановления доверительных отношений с доменом. В этом случае для восстановления безопасного канала с контроллером домена нужно воспользоваться утилитой
netdom.exe
.

Утилита Netdom включена в состав Windows Server начиная с 2008, а на компьютерах пользователей может быть установлена из RSAT (Remote Server Administration Tools). Чтобы восстановить доверительные отношения, нужно войти в систему под локальным администратором (набрав “.Administrator” на экране входа в систему) и выполнить такую команду:

Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password

• Server – имя любого доступного контроллера домена;
• UserD – имя пользователя с правами администратора домена или делегированными правами на компьютеры в OU с учетной записью компьютера;
• PasswordD – пароль пользователя.

Netdom resetpwd /Server:spb-dc01 /UserD:aapetrov /PasswordD:Pa@@w0rd

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

Как вы видите, восстановить доверительные отношения междду компьютером и доменом довольно просто.

По самым разным причинам можно столкнуться с проблемой невозможности входа в систему на компьютере, включенном в домен. Если это происходит на обычном клиентском ПК — ничего не мешает вывести его из домена и добавить заново — проблема решается гарантированно. Но если дело касается сервера, на котором крутятся приложения, завязанные на AD — рисковать выводом сервера из домена не очень хочется. К счатью, способ «возврата» к нормальному состоянию есть.

Вообще, проблема с невозможностью залогиниться в домен с такой ошибкой, сопровождается записью в системном логе следующего содержания:

 This computer could not authenticate with DomainController’ a Windows domain controller for domain DOMAIN, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

Т.е., как обычно у майкрософта, ничего конкретного о способах решения в ошибке не сказано. Корни проблемы уходят в доменную авторизацию: по умолчанию, пароль для учетной записи компьютера имеет срок жизни в 30 дней. Если ОС не связывалась с доменом в течение этого срока или, например, вы восстановили из бэкапа 30-дневной давности сервер/виртуалку — вы не сможете залогиниться на него под доменной учетной записью. Для исправления этой ситуации необходимо:

1. Залогиниться на сервер под локальной учетной записью с администраторскими полномочиями;

2. Выполнить команду klist purge для очистки кэша Kerberos на сервере.

3. Выполнить команду  «netdom resetpwd /s:x.x.x.x  /ud:domainUser /pd:*», где x.x.x.x — IP-адрес контроллера домена, domainUser — учетная запись администратора домена с указанием имени домена.

4. После запроса пароля — ввести пароль от учетной записи администратора домена.

5. Перезагрузить сервер и залогиниться под учетной записью администратора домена.

Если это не помогло — вам поможет только вывод компьютера из домена и повторное его туда включение. Или техподдержка Майкрософта

Как установить доверительные отношения между компьютером и основным доменом

Здравствуйте Уважаемые читатели Хабрахабра! В просторах интернета каждый из нас может найти много отдельных статей о не прохождении аутентификации компьютера через домен-контроллер, если точнее сказать, компьютер подключенный к домену теряет связь с ним.

Итак, приступим к изучению этой проблемы.

У многих IT – инженеров, которые работают в больших и малых компаниях, имеются компьютеры с операционной системой Windows 7, 8.1 и т.п. и все эти компьютеры подключены к доменной сети (DC).

Данная проблема происходит из-за того, что сетевой протокол Kerberos не может синхронизироваться и пройти аутентификацию с компьютером (The trust relationship between this workstation and the primary domain failed), который подключен к домену. Тогда мы можем увидеть такую ошибку (см. фото ниже).

После чего мы ищем стороннюю программу, скачиваем ее, создаем загрузочную флешку и локального админа, далее логируемся через него и выходим с домена, добавляем компьютер в Workgroup-у и потом обратно подключаем этот компьютер к домену.

Используя Windows Batch scripting, я хочу создать bat file и автоматизировать процесс создания и добавления локального админа. Единственное, что нам будет необходимо, так это после создания данного файла запустить его.

Открываем наш текстовой редактор, вписываем команду, которая показана внизу.

net user admin Ww123456 /add /active:yes
	
WMIC USERACCOUNT WHERE "Name='admin'" SET PasswordExpires=FALSE
	
net localgroup Administrators admin /add 

net localgroup Users admin /delete 

netsh advfirewall set allprofiles state off

Пройдем все команды по пунктам для устранения неясных моментов.

• net user admin (вместо слова админ Вы можете добавить любое имя, которое Вас устраивает, по умолчанию ставится administrator, в моем случае это admin).
Далее мы видем пароль, который я там поставил Ww123456(Вы можете поставить любой запоминающийся для Вас пароль).

После мы видем /add /active:yes –добавить и активировать: ДА

• WMIC USERACCOUNT WHERE «Name=’admin’» SET PasswordExpires=FALSE – данная команда означает, что админ, который добавляется, имел постоянный пароль без срока действия (см. картинку ниже).

• Третий и четвертый пункт связаны между собой тем, что по умолчанию, когда создается локальный админ в пункте Member Of стоит Users (см. фото). Нам он не нужен (Users), потому что мы создаем полноправного администратора для нашей ОС. Поэтому четвертая команда — net localgroup Users admin /delete – удаляет Users, а предыдущая команда — net localgroup Administrators admin /add, добавляет администратора (см. фото).

• Последняя команда- netsh advfirewall set allprofiles state off, отключает брандмаузер Windows-a.
Иногда, чтобы установить какую-либо программу или дать какую-либо команду в Windows-e необходимо отключить firewall (После запуска скрипта Вы можете ввести команду- netsh advfirewall set allprofiles state on и включить его заново. У меня по умолчанию стоит off, так как я использую сторонний брандмаузер. Данный момент на усмотрение каждого лично).

Далее идем к нашему блокноту, нажимаем File, save as… (сохранить как…) вводим имя нашего скрипта( в моем случае: localadmin).Затем ставим точку (.) и пишем формат скрипта bat. Выбираем место, где сохранить данную запись и нажимаем save. Более детально показано на картинке.

Получается вот такой скрипт (см. фото).

Данный скрипт при запуске необходимо открывать от имени администратора:

• Нажимаем правую кнопку мыши и Run as administrator (см. фото).

После запуска скрипта у Вас должно появиться вот такое окошко (см. фото).

Если по каким-либо причинам выйдет ошибка, то в 90% таких случаев это связано с тем, что у Вас образ с которого Вы установили Windows, имеет нелицензионный характер, какие-либо repack или т.п. Скачивайте и используйте лицензионный и проверенный софт.

После удачного добавления локального админа, Вы можете этот скрипт запустить на всех рабочих машинах в Вашем офисе, в которых установлена ОС Windows.

Если у Вас когда-нибудь появится такая ошибка: The trust relationship between this workstation and the primary domain failed- Вам нужно будет только сделать switch user и где логин написать.admin (запомните! В начале до слеша ставится точка!), далее внизу вводите пароль, который Вы добавили в Ваш скрипт (в моем случае: Ww123456). После этого Вы заходите на рабочую ОС.

Осталось снять наш компьютер с домена и добавить в Workgroup-у. Вместо Workgroup-а вписываем любую букву (см. фото).

Далее вводится пароль администратора домена и компьютер просит нас о перезагрузке.
После перезагрузки ещё раз заходим под нашим локальным админом и дальше уже добавляем компьютер к нашему домену. Система в очередной раз требует перезагрузиться и Вуаля! Наш User опять может подключиться к домену без всяких проблем!

P.S – Данная система работает также для серверной части Windows, однако если Вы будете писать такой скрипт для серверов после отключения брандмаузера необходимо будет включить его еще раз (до — netsh advfirewall set allprofiles state off, после netsh advfirewall set allprofiles state on).

Благодарю за внимание!

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

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

Как проявляется проблема: пользователь пытается авторизоваться на рабочей станции или сервере под своей учетной запись и после ввода пароля появляется ошибка:

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

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

Когда компьютер вводится в домен Active Directory, для него создается отдельная учетная запись типа computer. У каждого компьютера в домене, как и у пользователей есть свой пароль, который необходим для аутентификации компьютера в домене и установления доверенного подключения к контроллеру домена. Однако, в отличии от паролей пользователя, пароли компьютеров задаются и меняются автоматически.

Несколько важных моментов, касающихся паролей компьютеров в AD:

• Компьютеры должны регулярно (по умолчанию раз в 30 дней) менять свои пароли в AD.Совет. Максимальный срок жизни пароля может быть настроен с помощью политики Domain member: Maximum machine account password age, которая находится в разделе: Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> Security Options.  Срок действия пароля компьютера может быть от 0 до 999 (по умолчанию 30 дней).
• Срок действия пароля компьютера не истекает в отличии от паролей пользователей. Смену пароля инициирует компьютер, а не контроллер домена. На пароль компьютера не распространяется доменная политика паролей для пользователей. Даже если компьютер был выключен более 30 дней, его можно включить, он нормально аутентифицируется на DC со старым паролем, и только после этого локальная служба 
   изменит пароль компьютера в своей локальной базе (пароль хранится в ветке реестра HKLMSECURITYPolicySecrets$machine.ACC) и затем в аккаунте компьютера в Active Directory.
• Пароль компьютера меняется на ближайшем DC, эти изменения не отправляются на контроллера домена с FSMO ролью эмулятора PDC (т.е. если компьютер сменил пароль на одном DC, то он не сможет авторизоваться на другом DC, до момента выполнения репликации изменений в AD).

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

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

1. Самая частая проблема. Компьютер был восстановлен из старой точки восстановления или снапшота (если это виртуальная машина), созданной раньше, чем был изменен пароль компьютера в AD. Т.е. пароль в снапшоте отличается от пароля компьютера в AD. Если вы откатите такой компьютер на предыдущее состояние, это компьютер попытается аутентифицироваться на DC со старым паролем.
2. В AD создан новый компьютер с тем же именем, или кто-то сбросил аккаунт компьютера в домене через консоль ADUC;
3. Учетная запись компьютера в домене заблокирована администраторам (например, во время регулярной процедуры отключения неактивных объектов AD);
4. Довольно редкий случай, когда сбилось системное время на компьютере.

Классический способ восстановить доверительных отношений компьютера с доменом в этом случае:

1. Сбросить аккаунт компьютера в AD;
2. Под локальным админом перевести компьютер из домена в рабочую группу;
3. Перезагрузить компьютер;
4. Перезагнать компьютер в домен;
5. Еще раз перезагрузить компьютер.

Этот метод кажется простым, но слишком топорный и требует, как минимум двух перезагрузок компьютера, и 10-30 минут времени. Кроме того, могут возникнуть проблемы с использованием старых локальных профилей пользователей.

Есть более элегантный способ восстановить доверительные отношения с помощью PowerShell без перевключения в домен и без перезагрузок компьютера.

Проверка и восстановление доверительного отношения компьютера с доменом с помощью PowerShell

Если вы не можете аутентифицироваться на компьютере под доменной учетной записью с ошибкой “Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом”, вам нужно войти на компьютер под локальной учетной записью с правами администратора. Также можно отключить сетевой кабель и авторизоваться на компьютере под доменной учетной записью, которая недавно заходила на этот компьютер, с помощью кэшированных учетных данных (Cached Credentials).

Откройте консоль PowerShell и с помощью командлета Test-ComputerSecureChannel проверьте соответствует ли локальный пароль компьютера паролю, хранящемуся в AD.

Если пароли не совпадают и компьютер не может установить доверительные отношения с доменом, команда вернет значение False – 

.

Чтобы принудительно сбросить пароль учётной записи данного компьютера в AD, нужно выполнить команду:

Для выполнения операции сброса пароля нужно указать учетную запись и пароль пользователя, у которого достаточно полномочий на сброс пароля учетной записи компьютера. Этому пользователя должны быть делегированы права на компьютеры в Active Directory (можно использовать и члена группы Domain Admins, но это не комильфо).

После этого нужно еще раз выполнить команду 

 и убедится, что она возвращает True (

).

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

 – имя ближайшего DC, на котором нужно сменить пароль компьютера.

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

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

С помощью командлета Get-ADComputer (из модуля Active Directory Windows PowerShell) можно проверить время последней смены пароля компьютера в AD:

Комадлеты Test-ComputerSecureChannel и Reset-ComputerMachinePassword доступны, начиная с версии PowerShell 3.0. В Windows 7/2008 R2 придется обновить версию PoSh.

Также можно проверить наличие безопасного канала между компьютером и DC командой:

Следующие строки подтверждают, что доверительные отношения были успешно восстановлены:

Восстановления доверия с помощью утилиты Netdom

В Windows 7/2008R2 и предыдущих версиях Windows, на которых отсутствует PowerShell 3.0, не получится использовать командлеты Test-ComputerSecureChannel и Reset-ComputerMachinePassword для сброса пароля компьютера и восстановления доверительных отношений с доменом. В этом случае для восстановления безопасного канала с контроллером домена нужно воспользоваться утилитой 

.

Утилита Netdom включена в состав Windows Server начиная с 2008, а на компьютерах пользователей может быть установлена из RSAT (Remote Server Administration Tools). Чтобы восстановить доверительные отношения, нужно войти в систему под локальным администратором (набрав “.Administrator” на экране входа в систему) и выполнить такую команду:

• Server – имя любого доступного контроллера домена;
• UserD – имя пользователя с правами администратора домена или делегированными правами на компьютеры в OU с учетной записью компьютера;
• PasswordD – пароль пользователя.

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

Как вы видите, восстановить доверительные отношения междду компьютером и доменом довольно просто.

спасибо сайту: https://winitpro.ru/index.php/2014/09/18/vosstanovlenie-doveritelnyx-otnoshenij-bez-perevvoda-v-domen/

В статье показано как решить проблему потери доверительных отношений между ПК и основным контролером домена. При возникновении данной проблемы, доменный пользователь не может войти на ПК под своей учетной записью, при этом возникает ошибка: «The trust relationship between this workstation and the primary domain failed».

Не удалось установить доверительные отношения

Привет! Бывает такое, что требуется восстановить компьютер или сам контроллер домена из точки восстановления/снэпшота (если это виртуальная машина). И частенько это приводит к потере доверительных отношений между компьютером и доменом. Мы получаем ошибку:

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

Или в английском варианте: 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.

Для того, чтобы восстановить доверительные отношения можно пойти тремя способами. Давайте их рассмотрим ниже.

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

Решение

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

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

Откройте менюПуск, Нажмите и удерживайте (или щелкните правой кнопкой мыши) Компьютер > Свойства.

Нажмите кнопкуИзменить настройки рядом с названием компьютера.

На вкладке Имя компьютера щелкнитеИзменить.

Под заголовком Член группы выберите Рабочая группа, введите имя рабочей группы и нажмите OK.

В ответ на предложение перезагрузить компьютер нажмите кнопку OK.

На вкладке Имя компьютера снова выберитеИзменить.

Под заголовком Член группы выберите Домен, и введите имя домена.

НажмитеOK, и введите учетные данные пользователя, который авторизован в данном домене.

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

В первую очередь для любого из способов нужно войти в учетную запись. Можно войти в учетную запись локального администратора, если она включена. Если нет такой возможности, то можно отключить сеть, выдернув сетевой провод из компьютера и войти в учетную запись, под которой уже осуществлялся вход когда — то.

1. Вывести компьютер из домена и ввести обратно, для этого нужно:

• Перевести компьютер из домена в рабочую группу
• Удалить аккаунт компьютера из AD через оснастку Пользователи и компьютеры
• Перезагрузить компьютер
• Ввести компьютер в домен
• Перезагрузить компьютер

2. С помощью PowerShell

Для выполнения этого способа PowerShell должен быть не ниже 3 версии, для того чтобы проверить версию, нужно запустить PowerShell и выполнить команду

По умолчанию в Windows 7 стоит 2 версия и если вы работаете в этой версии Windows нужно будет обновить PowerShell. Для этого устанавливается обновление KB3191566, при попытке его установить может возникать ошибка, о том что невозможно установить это обновление, чтобы избавиться от этой ошибки существует программа wufuc, которую нужно просто установить. После этого можно будет установить обновление.

Для восстановления доверительных отношений нужно запустить PowerShell от имени администратора и выполнить команду

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

Можно выполнить команду для проверки доверительных отношений

Если она вернула True, значит доверительные отношения восстановлены, если false, то нет.

Восстановление доверительных отношений в домене

Бывает такая ситуация, что компьютер не может пройти проверку подлинности в домене. Вот несколько примеров:

• После переустановки ОС на рабочей станции машина не может пройти проверку подлинности даже с использованием того же имени компьютера. Поскольку в процессе новой установки ОС генерируется SID-идентификатор и компьютер не знает пароль учетной записи объекта компьютера в домене, он не принадлежит к домену и не может пройти проверку подлинности в домене.
• Компьютер полностью восстановлен из резервной копии и не может пройти проверку подлинности. Возможно, после архивации объект компьютера изменил свой пароль в домене. Компьютеры изменяют свои пароли каждые 30 дней, а структура Active Directory помнит текущий и предыдущий пароль. Если была восстановлена резервная копия компьютера с давно устаревшим паролем, компьютер не сможет пройти проверку подлинности.
• Секрет LSA компьютера давно не синхронизировался с паролем, известным домену. Т.е. компьютер не забыл пароль — просто этот пароль не соответствует реальному паролю в домене. В таком случае компьютер не может пройти проверку подлинности и безопасный канал не будет создан.

Основные признаки возможных неполадок учетной записи компьютера:

• Сообщения при входе в домен указывают, что компьютеру не удалось установить связь с контроллером домена, отсутствует учетная запись компьютера, введен неправильный пароль учетной записи компьютера или потеряно доверие (безопасная связь) между компьютером и доменом.
• Сообщения или события в журнале событий, указывающие аналогичные ошибки или предполагающие неполадки паролей, доверительных отношений, безопасных каналов либо связи с доменом или контроллером домена. Одна из таких ошибок — отказ проверки подлинности с кодом ошибки 3210 в журнале событий компьютера.
• Учетная запись компьютера в Active Directory отсутствует.

Необходимо переустановить учетную запись компьютера. В сети есть рекомендации по такой переустановки: удалить компьютер из домена, чтобы потом повторно присоединить его. Да, это работает, но данный вариант не рекомендуется делать по причине того, что теряется SID-идентификатор и членство компьютера в рабочей группе.

Поэтому необходимо сделать так :

Открыть оснастку Active Directory, выбрать «Пользователи и компьютеры», щелкнуть объект компьютера правой кнопкой мыши и применить команду «Переустановить учетную запись». После этого компьютер следует заново присоединить к домену и перезагрузиться.

Чтобы перезагрузка после сброса безопасного канала не требовалось, нужно использовать либо команду Netdom, либо Nltest.

C помощью учетной записи, относящейся к локальной группе «Администраторы»:

netdom reset Имя_машины /domain Имя_домена /Usero Имя_пользователя /Passwordo

Ошибка the trust relationship between this workstation and the primary domain failed

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

Тут то же сервер не может связаться с контроллером домена, если вы зайдете на него консольно, то в журнале событий вы можете обнаружить критическую ошибку:

ID 5776 NETLOGON: Failed to create/open file system32confignetlogon.ftl with the following error: There is not enough space on the disk.

Как видно Windows просто не смогла открыть файл netlogon.ftl, за который отвечает служба NETLOGON, которая так же участвует в авторизации пользователя в систему. /В системе мониторинга, я так же нашел провал по свободному дисковому пространству.

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

Рассмотрим несколько способов исправить проблему отсутствия доверительных отношений между рабочей станцией и доменом

Способ №1. Выход из домена с последующим входом

Наиболее простым способом решения проблемы «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» (рекомендуемым, в частности, компанией «Макрософт») является выход компьютера (или «рабочей станции») из домена, с его последующим подключением к данному домену. Выполните следующее:

1. Войдите в систему (ОС Виндовс) под учёткой локального администратора;
2. Наведите курсор на иконку «Мой компьютер» на рабочем столе, нажмите ПКМ, выберите «Свойства»;
3. В открывшемся окне рядом с названием ПК нажмите на кнопку «Изменить» (Изменить параметры);
4. Откроется окно, где на вкладке «Имя компьютера» нажмите внизу на кнопку «Изменить»;
5. В опции «Является членом» (или «Член группы») выберите настройку «Рабочая группа», введите какое-либо название группы и нажмите на ОК;

Способ №2. Задействуйте PowerShell

Ещё одним вариантом решить проблему доверительных отношений в домене является задействование функционала «PowerShell» в Виндовс 10. Выполните следующее:

• Войдите в учётку локального администратора на Виндовс 10;
• В строке поиска панели задач наберите PowerShell, сверху отобразится найденный результат;
• Наведите на него курсор, нажмите ПКМ, выберите опцию запуска от имени администратора, подтвердите запуск, нажав на «Да»;
• В открывшейся оболочке наберите и нажмите на ввод;

• Закройте «PowerShell» и перезагрузите ПК;
• Выполните вход в Виндовс 10 используя аккаунт пользователя домена.

Способ №3. Временно отключите сетевой кабель

Неплохо зарекомендовал себя кастомный способ, предложенный пользователями. При возникновении подобной проблемы на вашем ПК рекомендуется отключить от ПК сетевой кабель и попытаться войти в свою учётку под старым паролем (при отключении кабеля такое может стать возможным). Затем подключите сетевой кабель, выйдите из домена, и потом вновь попробуйте обратно войти в домен. Если вход удастся, перезагрузите ваш ПК.

Обновлено 28.03.2022

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз я вас научил делать резервные копии с помощью утилиты Robocopy, это было очень полезно. В сегодняшней заметке я покажу, как решается проблема с вылетевшим из домена компьютером, который при логине выводит ошибку «База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера«. Думаю, что многие с ней сталкивались, но не все ее решали и понимали откуда эта проблема берется.

Описание проблемы

Давайте я подробнее опишу рабочее окружение. И так есть лес Active Directory, в котором есть родительский домен, дочерний и транзитивный отдельный домен в рамках леса. Поступила задача мигрировать и доверительного домена объект компьютера в дочерний домен. Для этого была использована утилита ADMT 3.2. Сама миграция учетной записи компьютера прошла штатно. Далее я сменил принадлежность к домену Active Directory нового компьютера, у меня ввод был успешен, но было предупреждение, что якобы есть проблемы на уровне DNS-сервера. После перезагрузки и попытке на него залогиниться появилась вот такая ошибка:

В английской версии, это выглядит вот так:

Как решить проблему с доверительными отношениями

И так давайте рассуждать, тут есть два сценария, когда вы можете увидеть эту ошибку:

• Во первых, это когда у вас компьютер или сервер не включались более 30 дней и не обращались к контроллеру домена, так как по умолчанию, каждые 30 дней все учетные записи компьютеров меняют свой пароль безопасности для канала между ними и контроллером домена
• Во вторых, это когда у вас на уровне леса есть два компьютера с одинаковыми именами, которые мешают друг другу и конфликтуют

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

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

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

• Утилита Netdom
• Nltest
• Командлет Reset-ComputerMachinePassword

Если эти манипуляции не помогают, то у вас сто процентов конфликт имен на уровне леса. Первым делом я вам советую открыть логи на контроллере домена. Там вы со сто процентной уверенностью обнаружите ошибку с кодом ID 2974. Как видите в моем случае ошибка указывает на servicePrincipalName HOST/имя компьютера, именно из-за него конфликт.

В моем случае сообщение об ошибке «База данных диспетчера учетных записей на сервере не содержит записи», появлялось потому, что после миграции у меня на старом месте осталась прошлая учетная запись компьютера и в новом месте она же присутствовала, что приводило к дублированию. У новой учетной записи компьютера, была обнаружена такая вещью, у нее не проставлялся атрибут AD servicePrincipalName. Чтобы в этом удостовериться откройте редактор атрибутов Active Directory подключитесь к контексту именования по умолчанию и найдите свой объект компьютера. Перейдите в его свойства.

Тут вы видите, что атрибут servicePrincipalName пустой, и если вы попытаетесь его заполнить, то получите ошибку, пока не уберете дубль.

Думаю что все умеют искать компьютеры в Active directory, но то же самое можно сделать и другими методами.

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

Можно так же и через командную строку, через утилиту dsquery * —filter servicePrincipalName=* —attr Name.

После того, как вы обнаружили ваш дублирующий компьютер в базе данных AD, то удаляем его. После этого, чтобы без перезагрузок и вывода и повторного ввода в домен, нового компьютера сделайте вот что. Находясь в свойствах учетной записи компьютера через ADSIEdit, зайдите внутрь свойства атрибута servicePrincipalName. Там вам нужно в ручном режиме создать записи:

• HOST/dns имя компьютера
• HOST/полное FQDN имя
• RestrictedKrbHost/dns имя компьютера
• RestrictedKrbHost/полное FQDN имя
• TERMSRV/dns имя компьютера
• TERMSRV/полное FQDN имя

После этих внесений, в идеале перезагрузить этот компьютер, но работать будет и без этого. Еще одно дополнение, если вы хотите увеличить период смены пароля у учетных записей компьютеров, то это можно сделать с помощью групповой политики, отредактировав текущую или создав новую. Я вам предлагаю вам отредактировать политику Default Domain Controllers Policy. Перейдите по пути:

По умолчанию стоит значение 30, можете легко поменять, я например, установлю 90 дней.

Отключение режима проверки уникальности имени участника-пользователя и имя участника-службы

Бывают случаи, что по ряду причин нет возможности удалить дублирующий объект. Для таких сценариев компания Microsoft выпустила обновление для Windows Server 2012 R2 и выше, которое позволяет на контроллерах домена, управлять поведением обнаружения дубликатов.

С помощью этого обновления корпорация Майкрософт предоставляет переключатель уровня леса выключить или включить проверку на уникальность посредством атрибута dSHeuristics.

Ниже приведены поддерживаемые dSHeuristics значения.

• dSHeuristic = 1: AD DS позволяет добавлять имена участников-пользователя (UPN)
• dSHeuristic = 2: AD DS позволяет добавлять имена участников повторяющихся службы (SPN)
• dSHeuristic = 3: AD DS позволяет добавление повторяющихся имен SPN и UPN
• dSHeuristic = любое другое значение: службы AD DS применяет проверка уникальности имен SPN и UPN

Ошибка the trust relationship between this workstation and the primary domain failed

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

Тут то же сервер не может связаться с контроллером домена, если вы зайдете на него консольно, то в журнале событий вы можете обнаружить критическую ошибку:

Как видно Windows просто не смогла открыть файл netlogon.ftl, за который отвечает служба NETLOGON, которая так же участвует в авторизации пользователя в систему. /В системе мониторинга, я так же нашел провал по свободному дисковому пространству.

Что такое netlogon.ftl ?

И так Windows хранит список входа в разделе реестра DomainCache. В реестре, это путь:

Windows заполняет ключ реестра DomainCache из файла с именем C:WINDOWSsystem32confignetlogon.ftl

Раздел реестра DomainCache обновляется из netlogon.ftl в процессе загрузки компьютера и всякий раз, когда устанавливается подключение к удаленному рабочему столу. Сам же файл netlogon.ftl заполняется из Active Directory службой netlogon. В AD есть раздел defaultNamingContext в контейнере System. Он заполняется из типов объектов TrustedDomain. Посмотреть, что будет заполнено из базы Active Directory можно командой:

Так, что если локальная система не сможет прочитать содержимое файла netlogon.ftl, то ошибка с доверительными отношениями вам обеспечена. Вот так вот просто решается ошибка с отсутствием в базе данных Active Directory учетной записи компьютера для регистрации. С вами был Иван Семин, автор и создатель компьютерного портала Pyatilistnik.org.