У windows server а нет этой рабочей станции в базе доверительных отношений

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

Содержание:

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом
Восстановить доверительные отношений компьютера с доменом с помощью PowerShell
Пароль учетной записи компьютера в домене 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 (можно сбросить пароль локального администратора, если вы его не знаете).

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

Для входа под локальным пользователем, нужно на экране пользователя указать его имя в формате:
.\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

Test-ComputerSecureChannel repair - восстановить подключение компьютера к домену, сбросить пароль

Если компьютер сможет подключиться к 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).

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

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

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

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

Самая частая проблема. Компьютер был восстановлен из старой точки восстановления или снапшота (если это виртуальная машина), созданной раньше, чем был изменен пароль компьютера в AD. Т.е. пароль в снапшоте отличается от пароля компьютера в AD. Перед созданием снапшота рекомендуется принудительно выполнить смену пароля компьютера в домене:
nltest.exe /sc_change_pwd:winitpro.loc
Компьютер был склонирован без выполнения sysprep;
В AD создан новый компьютер с тем же именем, или кто-то сбросил аккаунт компьютера в домене через консоль ADUC;

Картинка с сайта: winitpro.ru
Учетная запись компьютера в домене заблокирована администраторам (например, во время регулярной процедуры отключения неактивных объектов AD);
Довольно редкий случай, когда сбилось системное время на компьютере или Windows не может синхронизировать время с внешним источником.

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

Источник

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Учетные записи компьютеров, также, как и учетные записи пользователей, являются участниками безопасности домена. Каждому участнику безопасности автоматически присваивается идентификатор безопасности (SID) на уровне которого осуществляется доступ к ресурсам домена.

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

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

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

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

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

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

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

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

Пользователи и компьютеры Active Directory

Это самый простой, но не самый быстрый и удобный способ. Открываем на любом контроллере домена оснастку Пользователи и компьютеры Active Directory, находим необходимую учетную запись компьютера и, щелкнув правой кнопкой мыши, выбираем Переустановить учетную запись.

Затем входим на потерявшем доверительные отношения компьютере под локальным администратором и выводим машину из домена.

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

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

Утилита Netdom

Данная утилита входит в состав Windows Server начиная с редакции 2008, на пользовательские ПК ее можно установить из состава пакета RSAT (Средства удаленного администрирования сервера). Для ее использования войдите на целевой системе локальным администратором и выполните команду:

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

Разберем опции команды:

Server — имя любого доменного контроллера
UserD — имя учетной записи администратора домена
PasswordD — пароль администратора домена

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

Командлет PowerShell 3.0

В отличие от утилиты Netdom, PowerShell 3.0 входит в состав системы начиная с Windows 8 / Server 2012, для более старых систем его можно установить вручную, поддерживаются Windows 7, Server 2008 и Server 2008 R2. В качестве зависимости требуется Net Framework не ниже 4.0.

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

Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin

где:

Server — имя любого контроллера домена
Credential — имя домена / учетной записи администратора домена

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

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

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

Дополнительные материалы:

Службы каталогов. Часть 1 — Общие понятия
Службы каталогов. Часть 2 — Реализации служб каталогов
Службы каталогов. Часть 3 — Структура Active Directory
Active Directory — от теории к практике. Часть 1 — общие вопросы
Active Directory — от теории к практике. Часть 2 — разворачиваем доменную структуру
Active Directory — от теории к практике. Часть 3 — настройка DHCP
Active Directory — от теории к практике. Часть 4 — перенос учетных записей в домен
Настраиваем высокодоступный DHCP-сервер в Windows Server 2012
Быстрое развертывание Active Directory с отказоустойчивой конфигурацией DHCP
Синхронизация времени Active Directory с внешним источником
Обновление схемы Active Directory
Управление ролями FSMO при помощи Ntdsutil
Управление ролями FSMO с помощью PowerShell
Восстанавливаем доверительные отношения в домене
Очистка метаданных контроллера домена в Active Directory

Источник

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

Решение 1: «В лоб»

«Сбросить» пароль локального администратора
«Выгнать» ПК из домена и включить его в рабочую группу
С помощью оснастки Active Directory Users and Computers «сбросить» учётную запись компьютера в домене
Повторно «вогнать» ПК в домен

Как видите, это долго, нудно и требуется несколько ребутов.

Решение 2: С использованием утилиты NotDom
В PowerShell
Netdom resetpwd /Server:DС-01 /UserD:Admin /PasswordD:*
где DC-01— имя контроллера домена, Admin — реквизиты учетной записи пользователя с правами администратора домена. Пароль в данном случае вводится после ввода команды непечатаемыми символами. Если хотите ввести пароль сразу в командную строку (вот только зачем?), впишите его вместо *.

Решение 3: С использованием PowerShell
Заходим на проблемный комп под учеткой локального администратора («выгонять» комп из домена не нужно), открываем консоль PowerShell и пишем там:
Reset-ComputerMachinePassword -Server DC-01 -Credential Domain\Admin
где DC-01— имя контроллера домена, Domain\Admin — реквизиты учетной записи пользователя с правами администратора домена.
В открывшемся окне указываем пароль этой учетной записи.

И не забывайте, что PowerShell нужно запускать с правами администратора.

Источник

В обслуживаемой организации у некоторых сотрудников эпизодически возникала ошибка:

По наблюдениям, возникала данная ошибка у сотрудников чаще всего после отпусков, либо длительных командировок. Исследование показало, что это связано с несоответствием вариантов паролей, хранящихся на рабочей станции и домене, при долгом отсутствии компьютера в корпоративной сети, не происходили обновления OS и обновление пароля для компьютера. При появлении компьютера в корпоративной сети после простоя происходило обновление пароля и установка обновление ОС. При следующем запуске ОС может запросить восстановление системы что приводит к откату состояния системы и как следствие возврат к предыдущему паролю для компьютера, у домена для данного компьютера остаётся сохранён новый пароль.

Пути решения

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

Решение 1 — Повторное введение в домен

Самый простой способ в соответствии со статьёй рекомендации с support.microsoft
При удалении компьютера из домена и повторном введении в домен, компьютер получает новый SID и теряет членство в группах.
Возможен вариант без изменения имени компьютера на контролере домена открываем оснастку «Active Directory Users and Computers» выбираем нужный компьютер после чего в контекстном меню выбираем «Reset Account», теперь на компьютере под учётной записью локального администратора заново вводим компьютер в домен (данный вариант был использован нами при решении проблемы, простой и надёжный как советский консервный ключ).
Данный способ работает всегда.

Минусы:
Необходимость активной учётной записи локального администратора или личное присутствие.
При удалении компьютера из домена необходимо будет повторно добавлять для него необходимые группы.

Решение 2 — Использование командлета PowerShell

PowerShell должен быть версии 3 (начиная с Windows 8/Server 2012 входит в состав системы, для более ранних версий можно установить отдельно https://www.microsoft.com/en-us/download/details.aspx?id=34595), необходимо войти под локальным администратором и запустить с правами администратора.

Reset-ComputerMachinePassword -Server DC -Credential Domain\Admin

—Server DC вместо DC имя вашего контролера домена (если контроллеров домена несколько, то можно указать любой, желательно из того же сегмента сети)
—Credential Domain / Admin вместо Domain/Admin указать данные домена и пользователя с правом добавления в домен.
После удачного завершения команды не выводит никаких сообщений, выходим из локальной учётной записи и заходим на компьютере в доменную учётную запись, перезагрузка не требуется.

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

Test-ComputerSecureChannel -Repair -Credential domain\user

Вместо Domain\User Укажите Ваш домен и пользователя с правом добавления в домен.

Минусы:
НеобходимPowerShell 3.0 доступный по умолчанию только с версии Windows 8/Server 2012
Запуск программы необходимо выполнить от локального администратора.

Решение 3 — утилита Nltest

Как и в случае с Nlщиками бесполезна в данной ситуации, но может быть полезна при других проблемах и для проверки защищенного сеанса между компьютером и контролером домена, а так же для проверки после ввода компьютера в домен. Итак данная утилита есть на всех современных и не только версиях Windows (в том числе и серверных). На компьютере, что потерял доверие, выполняем следующие команды:

Nltest /query

для проверки безопасного соединения с доменом;

Nltest/sr_reset:YOUDOMAIN

сбрасываем учётную запись компьютера в домене;

Nltest/sc_change_pwd:YOUDOMAIN

Изменяем пароль компьютера в Вашем домене.

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

Минусы:
Хоть и данная утилита есть на любом компьютере, запускается она от пользователя под которым Вы вошли в систему и нет возможности ввести данные для авторизации.

Решение 4 — утилита Netdom

Увы с ней тоже не все так гладко, её нет по умолчанию на любом компьютере, на Windows Server она доступна начиная с версии 2008, на рабочие компьютер можно установить из пакета RSAT (средство удалённого администрирования сервера). Для её использования так же необходимо зайти на целевую систему под локальным администратором и выполнить следующие действия:

Netdom resetpwd /Server:DC /UserD:Admin /PasswordD:Password

где:
DC – имя любого доменного контролера.
Admin – учётная запись администратора домена
Password – пароль администратора домена

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

Минусы:
Необходимо запустить командную строку от имени локального администратора.
Данную утилиту необходимо заранее установить на компьютер, а при потере доверительных отношений с доменом у Вас не будет возможности установить ПО от имени доменного администратора или учётной записи с необходимыми правами.

Источник

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

Решение тут одно. Вывести машину из домена и ввести обратно. Когда в день эта ситуация стала повторятся больше одного раза, да и просто надоело, задумался о профилактике. И вот тут интернет промолчал. После некоторого времени уныния, а уныние, как известно — грех, было решено копать. В результате

~~пыток~~

раскопок, была получена причина 99% случаев (и я подозреваю что оставшийся 1% просто не признался в той же самой причине). Причина — это служба восстановления при загрузке, которая включается при некорректном завершении работы. На первом же экране диалога служба спрашивает пользователя восстанавливать систему или нет. В случае положительного ответа система откатывается до более раннего состояния и, возможно, бьется sid машины. Как бы то ни было, домен пускать к себе пользователей с такой машину после такой операции не станет. Надеяться на пользователя в таком вопросе бесполезно. Можно просить его отказываться, в случае возникновения такой ситуации, но пользователь с очень большой вероятностью нажмет кнопку «восстановить» а потом разведет руками, мол бес попутал. В общем надо пакетно отключить службу восстановления при загрузке на n-машинах.

Локально решение выглядит, как консольная команда:

reagentc.exe /disable

Для сети потребуется утилита PsExec из пакета Microsoft Sysinternals PsTools, описание утилиты и сам пакет лежат тут

psexec.exe кладем в одну папку с нашим командным файлом (назовем его broff.cmd)
внутри broff.cmd пишем:

::Получаем список компьютеров в сети, чистим от мусора и кладем в net.lst
net.exe view  /domain:megafon >>net.tmp
for /f "tokens=1,2 delims= " %%i in (net.tmp) do (Echo %%i>>net1.tmp)
for /f "tokens=1,2 delims=\" %%i in (net1.tmp) do (Echo %%i>>net.lst)
DEL *.TMP

::Проходимся по списку и отключаем boot recovery
for /f "tokens=1,2 delims= " %%F in (net.lst) do (
start psexec \\%%F  reagentc.exe /disable)

Вот и все. Пользователь больше нам не враг.

Источник