Не удалось установить доверительные отношения с доменом: Ошибка «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» при выполнении входа в Windows 7

Ошибка «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» при выполнении входа в Windows 7

Проблема

При входе в систему на компьютере с Windows 7 в доменной среде появляется следующее сообщение об ошибке:

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

Решение

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

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

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

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

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

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

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

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

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

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

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

11. Перезагрузите компьютер.

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

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

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

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

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

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

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

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

Решение № 1 — Удалить учетную запись компьютера

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

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

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

Если вы попытаетесь исправить проблему доверия домена, удалив учетную запись компьютера Exchange Server, вы потеряете все данные конфигурации с сервера!

Не делай этого. Не на рядовом сервере, по крайней мере. Вместо этого читайте дальше.

Решение № 2 для доверительных отношений между этой рабочей станцией — Сброс учетной записи компьютера

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

1. Доступ к консоли Active Directory «Пользователи и компьютеры»;
2. Выберите контейнер Компьютеры;
3. Определите компьютер, который вам нужен для устранения неполадок;
4. Щелкните правой кнопкой мыши на этом компьютере;
5. Нажмите на команду Сбросить учетную запись;
6. В открывшемся окне с просьбой подтвердить сброс нажмите Да.

Это один из способов сброса учетной записи компьютера.

Второй относится к инструменту PowerShell, в идеале версии 2 или более поздней, через командлет Reset-ComputerMachinePassword.

Не удалось установить доверительные отношения для защищенного канала SSL/TLS — Контур.

В программе Контур.Экстерн Лайт при попытке соединения с сервером появляется сообщение: «Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS».

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

0. С 18 апреля домен *.kontur.ru получил новый сертификат сервера, соответствующий SHA-2. Пользователи Windows XP ниже Service Pack 3 и Windows Server 2003 ниже Service Pack 2 не смогут зайти ни в один из продуктов СКБ Контур, так как эти операционные системы не поддерживают алгоритм шифрования SHA-2.

1. Проверить дату, установленную на компьютере.

2. Убедиться, что в настройках учетной записи указан действующий адрес сервера (чаще всего это адрес: extern.kontur.ru). Проверить адрес сервера можно в адресной строке, войдя в Контур.Экстерн с браузера.

3. Проверить, какая версия КриптоПро установлена на рабочем месте. Выбрать меню «Пуск» > «Панель управления» > «КриптоПро CSP» (для ОС Windows Vista \ Windows Seven меню «Пуск» > «Панель управления» > «Программы и компоненты» > «КриптоПро CSP»). На вкладке Общие указана версия программы.

Если установлена версия КриптоПро 2.0, необходимо ее обновить (см. Как переустановить программу КриптоПро CSP?). На данный момент Контур.Экстерн Лайт работает с КриптоПро версий 3.0 и 3.6.

Была ли полезна информация?

Да Нет

Спасибо за ответ

Не нашли ответа на свой вопрос? Напишите нам!

Спросить эксперта

Сервис временно недоступен

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

Связано с тем что у компа в домене тоже есть
пароль. Правильно, комп он тоже человек.
Пароль этот меняется по инициативе локальной машиине раз в количество
дней, указанных в ключе
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
REG_DWORD:MaximumPasswordAge

Если ключ не раздается доменной политикой, его можно сменить.
Если жопа уже случилась, то это можно лечить неправильным путем: зайти
под локальной учеткой, выйти из домена, перезагрузиться, зайти под
локальной учеткой, войти в домен, перезагрузиться, войти под доменной
учеткой.
Еще один неправильный путь — на контроллере домена сделать Reset Account компьютеру.
Это то же самое, что выйти и войти в домен, те же две перезагрузки потребуются.

Есть более адекватный способ, но для него нужен либо PowerShell версией
старше 2, либо комплект RSAT

Если есть PowerShell —
Заходим под локальным админом. Открываем PowerShell

Reset-ComputerMachinePassword -Credential DOMAIN\domain_admin -Server
DOMAIN_CONTROLLER.DOMAIN

Не знаю, как это работает в PowerShell 1.0 (которая стоит по умолчанию в Windows 7), поскольку в ней нет параметра Credential.
Возможно она спрашивает под кем заходить, а может быть всегда использует залогиненного юзера. Во втором случае — увых, надо обновлять PS.

Если есть RSAT —
netdom resetpwd /server:DOMAIN_CONTROLLER.DOMAIN /userD:DOMAIN\domain_admin
/passwordD:domain_admin_password

Как выполнилось — можно сделать logoff и заходить в домен.

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

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

Разберем причины появления ошибок и методы их лечения.

В доменных сетях Windows всем компьютерам и учетным записям пользователей присваиваются свои идентификаторы безопасности (SID). В сущности, можно сказать, что каждый компьютер в домене также обладает своей учетной записью типа «компьютер». По аналогии с учетной записью пользователя, такая учетная запись тоже будет иметь пароль. Данный пароль создается и предъявляется компьютером контроллеру домена автоматически. Таким образом между рабочими станциями и контроллером домена и формируются те доверительные отношения, о которых упоминается в тексте ошибок.

Каждые 30 дней или при первом включении после длительного перерыва компьютер автоматически изменяет свой пароль. В теории всё красиво, и машина вроде бы не может ошибиться и «ввести» неправильный пароль. Однако иногда такое происходит по нескольким причинам.

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

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

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

Первый способ заключается в переустановке учетной записи в .

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

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

В данном случае -Server это имя контроллера домена, а -Credential это учетная запись администратора домена.

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

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

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

Принцип схож с тем, что мы видели в примере с PowerShell. /Server это контроллер домена, /UserD — учетная запись администратора домена, /PasswordD — пароль от учетной записи администратора домена. Вы также можете использовать параметр /SecurePasswordPrompt , чтобы скрыть пароль за звездочками. Перезагрузка также не требуется.

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

Запустим утилиту в командной строке и для начала проверим безопасное соединение с доменом:

Затем сбросим учетную запись компьютера в домене:

И, наконец, сбросим пароль компьютера:

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

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

В данном случае нам опять же поможет утилита Nltest . Снова проверяем безопасное соединение с доменом:

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

Во втором случае мы явно указываем контроллер домена, с которым хотим установить доверительные отношения.

Утилита порадует нас сообщением о том, что безопасный канал был сброшен и новое соединение установлено.

Итак, вот несколько способов восстановить доверительные отношения в домене. Надеюсь, что применять их вам придется как можно реже. 🙂

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

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

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

Или такая:

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

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

Пароль компьютера в домене AD

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

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

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

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

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

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

1. Сбросить пароль локального администратора
2. Вывести ПК из домена и включить его в рабочую группу
3. Перезагрузится
4. С помощью оснастки – сбросить учёту компьютера в домене (Reset Account)
5. Повторно включить ПК в домен
6. Еще раз перезагрузиться

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

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

Утилита Netdom

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

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

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

Netdom resetpwd /Server:sam-dc01 /UserD:aapetrov /PasswordD:[email protected]@w0rd

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

Командлет Reset-ComputerMachinePassword

Командлет появился в PowerShell 3.0, и в отличии от утилиты Netdom, уже имеется в системе, начиная с Windows 8 / Windows Server 2012. На Windows 7, Server 2008 и Server 2008 R2 его можно установить вручную (http://www.microsoft.com/en-us/download/details.aspx?id=34595), также требуется наличие Net Framework 4.0 или выше.

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

Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin

• Server – имя контроллера домена
• Credential – имя пользователя с правами администратора домена (или правами на OU с ПК)

Reset-ComputerMachinePassword -Server sam-dc01 -Credential corp\aapetrov

В открывшемся окне безопасности нужно указать пароль пользователя.

Совет . Эту же операцию можно выполнить с помощью другого командлета Powershell Test-ComputerSecureChannel:

Test-ComputerSecureChannel -Repair -Credential corp\aapetrov

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

nltest /sc_verify:corp.adatum.com

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

Trusted DC Connection Status Status = 0 0x0 NERR_Success

Trust Verification Status = 0 0x0 NERR_Success

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

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

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

Для восстановления доверительных отношений существует несколько способов. Рассмотрим их все по порядку.

Способ первый

Открываем оснастку «Active Directory Users and Computers» и находим в ней нужный компьютер. Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «Reset Account». Затем заходим на компьютер под локальной учетной записью и заново вводим его в домен.

Способ этот довольно громоздкий и небыстрый, т.к. требует перезагрузки, однако работает в 100% случаев.

Способ второй

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

Netdom Resetpwd /Server:SRV1 /UserD:Administrator /PasswordD:*

где SRV1 — контролер домена, Administrator — административная учетная запись в домене. Дополнительно можно указать параметр /SecurePasswordPrompt, который указывает выводить запрос пароля в специальной форме.

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

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

Еще с помощью Netdom можно проверить наличие безопасного соединения с доменом:

Netdom Verify WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*

Или сбросить учетную запись компьютера:

Netdom Reset WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*

где WKS1 — рабочая станция, которой сбрасываем учетку.

Способ достаточно быстрый и действенный, однако есть одно но: по умолчанию утилита Netdom есть только на серверах с установленной ролью Active Directory Domain Services (AD DS). На клиентских машинах она доступна как часть пакета удаленного администрирования Remote Server Administration Tools (RSAT).

Способ третий

Еще одна утилита командной строки — Nltest. На компьютере, который потерял доверие, выполняем следующие команды:

Nltest /query — проверить безопасное соединение с доменом;

Nltest /sc_reset:Contoso.com — сбросить учетную запись компьютера в домене;

Nltest /sc_change_pwd:Contoso.com — изменить пароль компьютера.

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

Способ четвертый

PowerShell тоже умеет сбрасывать пароль копьютера и восстанавливать безопасное соеднение с доменом. Для этого существует командлет Test-ComputerSecureChannel . Запущенный без параметров он выдаст состояние защищенного канала — True или False.

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

Test-ComputerSecureChannel -Server SRV1 -Credential Contoso\Administrator -Repair

где SRV1 — контролер домена (указывать не обязательно).

Для сброса пароля также можно также воспользоваться такой командой:

Reset-ComputerMachineChannel -Server SRV1 -Credential Contoso\Administrator

Способ быстрый и удобный, не требующий перезагрузки. Но и здесь есть свои особенности. Ключ -Credential впервые появился в PowerShell 3.0. Без этого параметра командлет, запущенный из под локального пользователя, выдает ошибку доступа. Получается что данный метод можно использовать только на Windows 8 и Server 2012, ведь для остальных ОС PowerShell 3.0 пока недоступен.

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

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

Смена пароля в домене происходит следующим образом:

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

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

Если настройки необходимо применить к группе компьютеров, то проще всего использовать групповую политику. Настройки, отвечающие за смену паролей, находятся в разделе Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options. Нас интересуют следующие параметры:

Disable machine account password change — отключает на локальной машине запрос на изменение пароля;

Maximum machine account password age — определяет максимальный срок действия пароля компьютера. Этот параметр определяет частоту, с которой член домена будет пытаться изменить пароль. По умолчанию срок составляет 30 дней, максимально можно задать 999 дней;

Refuse machine account password changes — запрещает изменение пароля на контролерах домена. Если этот параметр активировать, то контролеры будут отвергать запросы компьютеров на изменение пароля.

Для одиночной машины можно воспользоваться настройками реестра. Для этого в разделе есть два параметра:

DisablePasswordChange — если равен 1, то запрос на обновление пароля компьютера отключен, 0 — включен.

MaximumPasswordAge — определяет максимальный срок действия пароля компьютера в днях. При желании можно задать более 1 миллиона дней!!!

И в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters , только у контролеров домена, параметр:

RefusePasswordChange — если равен 1, то запрещает контролеру домена принимать запрос на изменение пароля. Этот параметр надо задать на всех контролерах в домене.

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

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

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

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

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

Как лечить?

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

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

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

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

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

На компьютере, где утрачены доверительные отношения:

nltest /server:Имя_сервера /sc_reset:ДОМЕН\Контроллер_домена

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

Обычной причиной этого (по моему опыту) является проблема DNS / DHCP

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

Когда ему предоставлен DC, машине придется проверять свой идентификатор SID и пароль учетной записи компьютера на записи DCs, чтобы доказать, что машина является той, на которую она претендует, а не только кубическая случайная машина с тем же именем (любой может назвать Компьютер «mymachine1» – но это не делает его тем, кем является ваш член домена).

Если ваш основной DNS недоступен для поиска DC, это может привести к задержкам – это означает, что учетная запись компьютера не аутентифицирована, – которые присутствуют в этом сообщении. Аналогично, если запрос DHCP занимает много времени из-за множественных перелетов или проблемы доступности сервера DHCP, это может привести к тем же симптомам

Другими причинами этого могут быть проблемы с репликацией постоянного тока, причем машина остается вдали от домена (выключена) в течение длительных периодов времени или недоступна RPC на клиенте или в DC.

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

• Прежде всего, убедитесь, что все ваши DNS настроены правильно. В идеале, ваш DNS будет находиться в ваших DC и будет реплицироваться с AD .. и ваши клиенты будут искать DC для DNS.
• Если у вас несколько контроллеров домена, проверьте, какой DC ваш компьютер регистрируется каждый раз, чтобы сузить поиск.
• Попробуйте вручную ввести известный хороший DC в качестве основного DNS-сервера на этом компьютере
• Проверьте версию объекта AD для этого аппарата на всех контроллерах домена, чтобы исключить проблемы с репликацией
• Вручную реплицируйте свои контроллеры домена, чтобы убедиться, что все ссылки на сайты
• Проверьте, не исчезла ли проблема со статическим IP-адресом
• Попробуйте PowerShell Command Test-ComputerSecureChannel –credential (Get-Credential) –Repair (запустите как администратор в PowerShell и Test-ComputerSecureChannel –credential (Get-Credential) –Repair ему учетные данные администратора)
• Попробуйте добавить домен / присоединиться к машине
• Проверьте правильность обработки всех групповых политик на этом компьютере (дайте ему фанковые обои с помощью объекта групповой политики, чтобы обеспечить его обработку)
• Является ли reimaging / перестраивает машину вне сферы действия?

Надеюсь, что-то здесь даст вам возможность спрыгнуть.

База данных диспетчера учетных записей на сервере не содержит записи

Обновлено 12.01.2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее про ошибку ID 2974 вы можете почитать на сайте Microsoft https://docs.microsoft.com/ru-ru/windows-server/identity/ad-ds/manage/component-updates/spn-and-upn-uniqueness

В моем случае сообщение об ошибке «База данных диспетчера учетных записей на сервере не содержит записи», появлялось потому, что после миграции у меня на старом месте осталась прошлая учетная запись компьютера и в новом месте она же присутствовала, что приводило к дублированию. У новой учетной записи компьютера, была обнаружена такая вещью, у нее не проставлялся атрибут 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. Перейдите по пути:

Конфигурация компьютера-Политики-Конфигурация Windows-Параметры безопасности-Локальные политики-Параметры безопасности-Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> Security Options (Computer Configuration-Windows Settings-Security Settings-Local Policies-Security Options)

По умолчанию стоит значение 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

ссылка на подробное описание данного обновления https://support.microsoft.com/ru-ru/help/3070083/duplicate-spn-check-on-windows-server-2012-r2-based-domain-controller

Ссылка на само обновление https://www.catalog.update.microsoft.com/Search.aspx?q=3070083

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

Ошибка «Доверительные отношения между этой рабочей станцией и основным доменом» при входе в Windows 7

Признак

При входе на компьютер под управлением Windows 7 в доменной среде появляется следующее сообщение об ошибке:

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

Разрешение

Чтобы решить эту проблему, удалите компьютер из домена, а затем подключите компьютер к домену.

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

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

3. Выберите Изменить настройки рядом с именем компьютера.

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

5. Под заголовком Member of выберите Workgroup , введите имя рабочей группы и затем выберите OK .

6. Когда вам будет предложено перезагрузить компьютер, выберите OK .

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

8. Под заголовком Member of выберите Domain , а затем введите имя домена.

9. Выберите ОК , а затем введите учетные данные пользователя, имеющего разрешения в домене.

10. Когда вам будет предложено перезагрузить компьютер, выберите OK .

11. Перезагрузите компьютер.

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

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

Эта ошибка возникает из-за «несоответствия пароля». В средах Active Directory каждая учетная запись компьютера также имеет внутренний пароль — если копия пароля учетной записи компьютера, хранящаяся на рядовом сервере, не синхронизируется с копией пароля, которая хранится на контроллере домена, то доверительные отношения будут сломан в результате.

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

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

1. Повторно подключите компьютер к домену
2. Восстановите доверие
3. Добавить контроллер домена в диспетчер учетных данных
4. Сбросить учетную запись компьютера

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

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

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

Чтобы повторно подключить компьютер к домену, выполните следующие действия:

• Войдите на клиентский компьютер с учетной записью локального администратора.
• Щелкните правой кнопкой мыши This PC и выберите Properties .
• Выберите Дополнительные параметры системы на левой панели, чтобы открыть окно Свойства системы .
• Щелкните вкладку Имя компьютера .
• Нажмите Изменить кнопку .
• В окне Изменение имени компьютера / домена выберите Рабочая группа под заголовком Член и введите имя рабочей группы.
• Нажмите ОК для подтверждения.
• Введите имя и пароль учетной записи с разрешением на удаление этого компьютера из домена.
• Нажмите ОК и перезагрузите компьютер в соответствии с запросом.
• Затем снова войдите на свой компьютер с учетной записью локального администратора и снова перейдите в окно Изменение имени компьютера / домена .
• Теперь проверьте Домен под Членом раздела на этот раз.
• Введите имя домена.
• Щелкните ОК .
• Теперь введите учетную запись и пароль учетной записи администратора домена.
• Нажмите ОК для подтверждения.
• Перезагрузите компьютер.

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

2] Восстановить доверие

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

• Нажмите клавишу Windows + X , чтобы открыть меню опытного пользователя.
• Коснитесь A на клавиатуре, чтобы запустить PowerShell в режиме администратора / с повышенными правами.
• В консоли PowerShell введите или скопируйте и вставьте команду ниже и нажмите Enter:

 $ credential = Get-Credential 

• I n введите имя пользователя и пароль учетной записи администратора домена в Windows. Запрос учетных данных PowerShell. всплывающее диалоговое окно входа в систему.
• Щелкните ОК .
• Затем введите или скопируйте и вставьте приведенную ниже команду в окно PowerShell и нажмите Enter:

 Reset-ComputerMachinePassword -Credential $ credential 

• После выполнения команды выйдите из PowerShell.
• Перезагрузите компьютер.

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

3] Добавить контроллер домена в диспетчер учетных данных

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

Чтобы добавить контроллер домена в диспетчер учетных данных, выполните следующие действия:

• Нажмите клавишу Windows + R , чтобы вызвать диалоговое окно «Выполнить».
• В диалоговом окне «Выполнить» введите control и нажмите Enter, чтобы открыть панель управления.
• Перейдите к Учетные записи пользователей > Диспетчер учетных данных .
• Выберите Учетные данные Windows .
• Щелкните Добавить учетные данные Windows .
• В диалоговом окне введите адрес веб-сайта или сетевого расположения и свои учетные данные.
• Нажмите ОК , чтобы сохранить изменения.
• Перезагрузите компьютер.

Теперь вы можете без проблем войти на свой компьютер в среде домена.

4] Сбросить учетную запись компьютера

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

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

• Нажмите клавишу Windows + R , чтобы вызвать диалоговое окно «Выполнить».
• В диалоговом окне «Выполнить» введите dsa.msc и нажмите Enter, чтобы открыть консоль «Пользователи и компьютеры Active Directory».
• Дважды щелкните имя домена, чтобы его развернуть.
• Выберите Компьютер .
• На правой панели щелкните правой кнопкой мыши учетную запись компьютера, которому не удалось подключиться к домену
• Выберите Сбросить учетную запись .
• Щелкните Да , чтобы подтвердить операцию.
• Перезагрузите компьютер.

Надеюсь, это поможет!

Как восстановить доверительные отношения Active Directory (и автоматизировать)

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

Обнаруживайте, сообщайте и предотвращайте небезопасные пароли учетных записей Active Directory в вашей среде с помощью совершенно бесплатного Password Auditor Pro от Specops. Загрузите его сегодня!

В этом руководстве вы узнаете все уловки, с которыми я сталкивался за 20 с лишним лет управления Active Directory, и способы автоматизации с помощью PowerShell.

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

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

К сожалению, я и другие системные администраторы не нашли ни одного решения, которое работало бы в 100% случаев. Вот почему я написал это руководство.

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

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

Когда новый компьютер добавляется в Active Directory, создается учетная запись компьютера с паролем. По умолчанию этот пароль действителен в течение 30 дней. Через 30 дней он автоматически меняется.

Просмотр существующих политик

Вы можете просмотреть политику домена, открыв консоль управления групповой политикой (GPMC). Внутри консоли управления групповыми политиками щелкните политику домена по умолчанию , и перейдите к Computer Configuration -> Windows Settings -> Security Settings > Local Policies > Security Options .

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

На компьютере, присоединенном к AD, откройте regedit и перейдите в раздел реестра HKLM \ SYSTEM \ CurrentControlSet \ Services \ Netlogon \ Parameters и найдите значение MaximumPasswordAge , как показано ниже.

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

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

Процесс изменения пароля учетной записи компьютера

Когда что-то работает нормально, при использовании службы Netlogon Windows компьютер автоматически инициирует смену пароля. Это происходит во время перезагрузки компьютера или когда объект-компьютер должен пройти аутентификацию в AD.

Используя службу Netlogon Windows, локальный компьютер инициирует последовательность изменения пароля. Компьютер сначала инициирует смену пароля на контроллере домена. В случае успеха он затем пытается изменить локальный пароль, чтобы он соответствовал ключу реестра HKLM \ SECURITY \ Policy \ Secrets .ACC .

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

Однако проблема возникает, когда:

• компьютер меняет учетную запись компьютера AD, но не может изменить локальный пароль.
• компьютер повторно создает образ без запуска sysprep
• ОС переустанавливается и пытается пройти аутентификацию со старой включенной учетной записью компьютера AD
• … и т. Д. ?

Проверка проблемы

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

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

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

nltest (инструмент командной строки)

nltest — это старый инструмент командной строки, который проверяет доверительные отношения для компьютера. Этот инструмент устанавливается при установке RSAT или доступен непосредственно на контроллере домена.

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

 > nltest / sc_verify:   

ПРЕДУПРЕЖДЕНИЕ. Этот метод не рекомендуется, поскольку nltest работает только в том пользовательском контексте, в котором он был запущен.Если у компьютера нарушено доверие и вы вошли в систему как локальный пользователь, он попытается подключиться к домену, используя учетные данные локального пользователя. Это приводит к ошибке отказа в доступе.

netdom (инструмент командной строки)

netdom — еще один инструмент командной строки, который можно использовать для проверки доверительных отношений. Этот инструмент также устанавливается при установке RSAT или доступен непосредственно на контроллере домена.

Вы можете подтвердить доверие с помощью netdom verify , указав:

• имя имени компьютера для проверки
• FQDN домена
• имя пользователя для аутентификации запроса
• пароль учетной записи пользователя

Пример ниже:

 > netdom проверьте MYCOMPUTER / домен: домен.local / UserO: abertram / PasswordO: *  

Если указать значение * для параметра PasswordO , netdom запросит пароль.

Test-ComputerSecureChannel (PowerShell)

Один из лучших способов решить проблему «доверительные отношения между этой рабочей станцией и основным доменом не удалось» — использовать командлет Test-ComputerSecureChannel . Этот командлет PowerShell входит в состав Windows 10 и проще в использовании.

Командлет Test-ComputerSecureChannel работает локально на компьютере с Windows 10. При интерактивном входе в компьютер откройте консоль PowerShell и запустите Test-ComputerSecureChannel без каких-либо параметров. Он вернет True или False в зависимости от того, действительно ли доверие.

  PS51> Test-ComputerSecureChannel
Правда  

Вы также можете указать конкретный контроллер домена для подтверждения синхронизации паролей с помощью параметра Server .

  PS51> Test-ComputerSecureChannel -Server 'DC.domain.local'
Ложь  

Этот командлет прост в использовании и имеет параметр Восстановить , но мы сохраним его демонстрацию для раздела исправлений.

Если вы знаете пароли локального администратора тех компьютеров, которые хотите проверить, и на них включено PowerShell Remoting, вы также можете использовать командлет Invoke-Command . Используя командлет Invoke-Command , вы можете удаленно запустить Test-ComputerSecureChannel на одном или нескольких компьютерах одновременно.

  PS51> Invoke-Command -ComputerName PC1, PC2, PC3 -ScriptBlock {Test-ComputerSecureChannel}  

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

Теперь, когда вы знаете, как удаленно проверить доверительные отношения, вот фрагмент кода, который вы можете использовать для проверки всех ваших компьютеров AD! В этом скрипте я сначала проверяю, подключен ли компьютер. В противном случае он вернет Offline . Если это так, он запустит Test-ComputerSecureChannel на каждом компьютере и либо вернет True , либо False .

  $ localCredential = Get-Credential
 
@ (Get-AdComputer -Filter *). Foreach ({
 
   $ output = @ {ComputerName = $ _. Name}
 
   if (-not (Test-Connection -ComputerName $ _. Name -Quiet -Count 1)) {$ output.Status = 'Offline'
   } еще {
       $ trustStatus = Invoke-Command -ComputerName $ _. Name -ScriptBlock {Test-ComputerSecureChannel} -Credential $ localCredential
       $ output.Status = $ trustStatus
   }
 
   [pscustomobject] $ output
 
})  

Знать и понимать проблему — это первый шаг, но как ее исправить? Теперь вы знаете, что вам нужно получить учетную запись компьютера, хранящуюся на локальном компьютере, так же, как учетную запись компьютера, хранящуюся в AD.

Есть много разных «решений» этой проблемы. Эти решения могут быть выполнены через графический интерфейс, через PowerShell или старые инструменты командной строки.

1. Сброс пароля учетной записи компьютера в AD
2. Сброс пароля учетной записи локального компьютера
3. Отключение и повторное присоединение к компьютеру с Windows
4. Полное удаление учетной записи компьютера и повторное присоединение к компьютеру с Windows

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

Устранение проблемы: сброс паролей компьютеров

netdom (инструмент командной строки)

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

В этом примере:

• DC — имя контроллера домена
• abertram — имя учетной записи пользователя Active Directory с правами на сброс учетной записи компьютера
• * — это имя-заполнитель для пароля учетной записи пользователя, которое будет запрашивать пароль.

 > netdom resetpwd / s: DC / ud: abertram / pd: *  

Сброс-ComputerMachinePassword (PowerShell)

Один из лучших способов исправить доверительные отношения — использовать командлет Reset-ComputerMachinePassword . Этот командлет запускается на локальном компьютере и инициирует последовательность сброса пароля. Синтаксис не может быть проще.

  PS51> Reset-ComputerMachinePassword  

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

В приведенном ниже примере будет запрашиваться имя пользователя и пароль AD и попытаться сбросить пароль на локальном компьютере и контроллере домена DC .

  PS51> Reset-ComputerMachinePassword -Server DC -Credential (Get-Credential)  

Это также можно запустить удаленно с помощью команды Invoke-Command , если на компьютере доступно удаленное взаимодействие PowerShell. Ниже я получаю имя пользователя и пароль для учетной записи локального администратора на компьютере.Я также получаю учетные данные с правами на сброс пароля учетной записи AD на этом компьютере. Затем я передаю $ domainCredential в удаленный сеанс, используя $, используя конструкцию .

  $ localAdminCredential = Get-Credential
$ domainCredential = Get-Credential

PS51> Invoke-Command -Computername MYCOMPUTER -Credential $ localAdminCredential -ScriptBlock {Reset-ComputerMachinePassword -Server DC -Credential $ using: domainCredential}  

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

Массовый сброс паролей учетных записей локального компьютера

Хотите исправить ошибку «доверительные отношения между этой рабочей станцией и основным доменом не удалось» сразу на большом количестве компьютеров? Без проблем. Используя удобный цикл foreach , мы также можем запустить пакет Reset-ComputerMachinePassword одновременно.

  $ localAdminCredential = Get-Credential
$ domainCredential = Get-Credential
 
@ (Get-AdComputer -Filter *).для каждого({
 
   $ output = @ {ComputerName = $ _. Name}
 
   if (-not (Test-Connection -ComputerName $ _. Name -Quiet -Count 1)) {$ output.Status = 'Offline'
   } еще {
       $ pwChangeOutput = Invoke-Command -Computername $ _. Имя -Credential $ localAdminCredential -ScriptBlock {Reset-ComputerMachinePassword -Server DC -Credential $ using: domainCredential}
       $ output.PasswordChangeOutput = $ pwChangeOutput
   }
 
   [pscustomobject] $ output
 
})  

Test-ComputerSecureChannel -Repair (PowerShell)

Другой способ инициировать процесс смены пароля — запустить Test-ComputerSecureChannel , но на этот раз использовать опцию Repair .Насколько я могу судить, этот процесс идентичен использованию Reset-ComputerMachinePassword . На компьютерной консоли используйте параметр Repair и параметр Credential .

  PS51> Test-ComputerSecureChannel -Repair -Credential (Get-Credential)  

Обязательно всегда используйте здесь параметр Credential . Если вы этого не сделаете, как и в случае с утилитой nltest , она попытается использовать локальную учетную запись и не будет работать.

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

Перетащите эту команду в удобный цикл foreach , который мы использовали, и Боб — ваш дядя!

  $ localAdminCredential = Get-Credential
$ domainCredential = Get-Credential
 
@ (Get-AdComputer -Filter *). Foreach ({
 
   $ output = @ {ComputerName = $ _. Name}
 
   if (-not (Test-Connection -ComputerName $ _. Name -Quiet -Count 1)) {$ output.Status = 'Offline'
   } еще {
       $ repairOutput = Invoke-Command -Computername $ _.Имя -Credential $ localAdminCredential -ScriptBlock {Test-ComputerSecureChannel -Repair -Credential $ using: domainCredential}
       $ output.RepairOutput = $ repairOutput
   }
 
   [pscustomobject] $ output
 
})  

Устранение проблемы: повторное присоединение к домену

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

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

Вы могли :

• войти на компьютер через локальную административную учетную запись
• перейти к Свойства системы
• нажать Изменить
• установить его в рабочую группу
• перезагрузить
• установить обратно в домен

Обратите внимание, как я упомянуть можно было .Не делай этого. Если вы можете автоматизировать PowerShell, это потеря вашего времени.

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

Использование CIM

Вы можете присоединиться к домену с помощью PowerShell (и отсоединиться от него) с помощью класса Win32_ComputerSystem CIM. В этом классе есть два метода, которые позволяют отключиться и присоединить компьютер к домену с именем UnJoinDomainOrWorkgroup () и JoinDomainOrWorkGroup .

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

  $ computername = 'PITA'

$ instance = Get-CimInstance -ComputerName $ computername -ClassName 'Win32_ComputerSystem'

$ invCimParams = @ {
    MethodName = 'UnjoinDomainOrWorkGroup'
    Аргументы = @ {FUnjoinOptions = 0; Username = "Administrator"; Password = "mypassword"}
}
$ instance | Invoke-CimMethod @invCimParams  

Обратите внимание на параметр FUnjoinOptions выше.Я решил указать здесь 4. При этом выполняется поведение по умолчанию при отключении компьютера вручную. Эта опция отключает учетную запись компьютера в Active Directory (если он может ее найти). Если вы не хотите, чтобы такое поведение происходило, вы можете использовать здесь опцию 0.

После отключения компьютера вы можете повторно присоединиться к домену с помощью метода JoinDomainOrWorkGroup () .

  $ computername = 'PITA'

$ instance = Get-CimInstance -ComputerName $ computername -ClassName 'Win32_ComputerSystem'

$ invCimParams = @ {
    MethodName = 'JoinDomainOrWorkGroup'
    Аргументы = @ {FJoinOptions = 3; Имя = mydomain.local; Username = "mydomain \ domainuser"; Password = "mypassword"}
}
$ instance | Invoke-CimMethod @invCimParams  

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

СОВЕТ. Вы также можете отсоединить и повторно присоединить сразу несколько компьютеров с помощью этого метода, указав несколько компьютеров с помощью параметра ComputerName в Get-CimInstance .

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

Вы также можете использовать встроенные командлеты PowerShell для отключения и присоединения компьютера к домену с помощью PowerShell. Вы можете использовать командлеты Remove-Computer и Add-Computer .

Чтобы отключить компьютер с помощью PowerShell, войдите в консоль компьютера и используйте командлет Remove-Computer . Предоставьте учетные данные домена с разрешениями на отключение от компьютера. Вы также можете указать параметр Restart для принудительного перезапуска после разъединения и Force , чтобы не запрашивать подтверждение.

  PS51> Remove-Computer -UnjoinDomaincredential (Get-Credential) -Restart -Force  

После перезагрузки компьютера вы можете использовать командлет Add-Computer для присоединения компьютера к домену с помощью PowerShell. Командлет Add-Computer можно использовать удаленно, указав параметр ComputerName . Вы также будете использовать учетные данные локального пользователя для подключения и учетные данные домена для аутентификации в домене.

Просканируйте свою Active Directory на наличие более 750 миллионов известных утечек паролей с помощью бесплатного сканирования Password Auditor, доступного только для чтения, от Specops.

  $ localCredential = Get-Credential
$ domainCredential = Get-Credential

Добавить компьютер -ComputerName PITA -LocalCredential $ localCredential -DomainName domain.local -Credential $ domainCredential -Restart -Force  

Автоматическое отключение и повторное присоединение к домену

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

• Отключитесь от компьютера
• Перезагрузитесь и дождитесь восстановления
• Присоединитесь к компьютеру
• Перезагрузитесь и дождитесь восстановления

Вы можете попробовать этот скрипт через GitHub.

Сводка

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

Дополнительная литература

Обязательно ознакомьтесь с другими публикациями по теме!

Как исправить проблемы с доверием домена в Active Directory — Redmondmag.com

Инструкции по Windows Server

Как исправить проблемы с доверием домена в Active Directory

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

Хотя операция восстановления прошла успешно, она имела непредвиденные последствия. После восстановления все другие серверы в домене отображали сообщение об ошибке при входе в систему. В этом сообщении об ошибке говорилось, что доверительные отношения между рабочей станцией и основным доменом не установлены. Вы можете увидеть фактическое сообщение об ошибке в , рисунок 1 .

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

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

Причина этого связана с тем, как некоторые приложения используют Active Directory. Возьмем, к примеру, Exchange Server. Exchange Server хранит сообщения в базе данных почтовых ящиков, находящейся на сервере почтовых ящиков.Однако это единственные важные данные, которые хранятся локально на сервере Exchange. Все данные конфигурации сервера Exchange хранятся в Active Directory. Фактически, можно полностью восстановить отказавший сервер Exchange с нуля (кроме базы данных почтовых ящиков), просто используя данные конфигурации, хранящиеся в Active Directory.

Причина, по которой я упоминаю этот конкретный пример, заключается в том, что данные конфигурации сервера Exchange хранятся в объекте компьютера для этого сервера.Помня об этом, представьте, что доверительные отношения были случайно нарушены, и вы решили решить проблему, удалив учетную запись компьютера Exchange Server и повторно присоединив компьютер к домену. Поступая так, вы потеряете всю информацию о конфигурации для этого сервера. Что еще хуже, все равно останутся потерянные ссылки на учетную запись компьютера, разбросанные в другом месте в Active Directory (вы можете увидеть эти ссылки с помощью инструмента ADSIEdit). Другими словами, избавление от учетной записи компьютера может вызвать довольно серьезные проблемы для ваших приложений.

Лучше всего просто сбросить учетную запись компьютера. Для этого откройте консоль «Active Directory — пользователи и компьютеры» и выберите контейнер «Компьютеры». Щелкните правой кнопкой мыши компьютер, с которым у вас возникли проблемы. В контекстном меню выберите команду «Сбросить учетную запись», как показано на рис. , рис. 2 . Когда вы это сделаете, вы увидите запрос с вопросом, уверены ли вы, что хотите сбросить учетную запись компьютера. Нажмите Да, и учетная запись компьютера будет сброшена.

Если вам интересно, учетные записи компьютеров также можно сбросить с помощью PowerShell (версии 2 или выше). Для этого используется командлет Reset-ComputerMachinePassword.

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

Об авторе

Брайен Поузи — 20-кратный MVP Майкрософт с многолетним опытом работы в ИТ. В качестве внештатного писателя Поузи написал тысячи статей и написал несколько десятков книг по широкому кругу тем в области информационных технологий. До того, как стать фрилансером, Поузи был ИТ-директором национальной сети больниц и медицинских учреждений.Он также работал сетевым администратором в некоторых из крупнейших страховых компаний страны и в Министерстве обороны Форт-Нокса. В дополнение к его продолжающейся работе в сфере информационных технологий, Пози последние несколько лет активно тренировался в качестве кандидата в коммерческие ученые и космонавты, готовясь к полету в миссии по изучению полярных мезосферных облаков из космоса. Вы можете следить за его обучением космическим полетам на его веб-сайте.

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

Мы используем Netmotion для наших полицейских ноутбуков, и когда мы пытаемся войти в систему, мы получаем эту ошибку « Сбой доверительных отношений между этой рабочей станцией и основным доменом» , и после этого мы можем войти в систему только как локальный администратор.Мы позвонили в Netmotion по этому поводу, и они еще не дали нам решения по этому вопросу. Мы работаем с ними около 2 недель над этим вопросом. Мы запускаем Windows 7. и мы можем видеть, где ноутбук перешел к серверу netmotion и подключился к нему, но от сервера netmotion к контроллеру домена, который кажется, где происходит сбой соединения. однако из того, что мы обходим netmotion при входе в систему и подключаемся к netmotion после входа в систему ПОЛЬЗОВАТЕЛЯ ДОМЕНА, мы можем подключиться к netmotion, но не с экрана входа в систему.

Также мы опробовали 2 новых ноутбука прямо из коробки и установили netmotion, но по-прежнему имели ту же ошибку

 netdom trust  TrustingDomainName **  / d:  TrustedDomainName  / verify ** 

  ** ПРИМЕЧАНИЕ:  В приведенной выше команде  TrustingDomainName  указывает DNS-имя проверяемого домена, а  TrustedDomainName  указывает DNS-имя доверенного домена 

  netdom trust   TrustingDomainName  ** / d:   TrustedDomainName   / add / realm / PasswordT: **  NewRealmTrustPassword  

  ** ПРИМЕЧАНИЕ:  В приведенной выше команде  TrustingDomainName  указывает DNS-имя проверяемого домена, а  TrustedDomainName  указывает DNS-имя доверенного домена 

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

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