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

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

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

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

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

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

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

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

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

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

Пароль учетной записи компьютера по умолчанию действует 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. С помощью оснастки ADUC – сбросить учёту компьютера в домене (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:Pa@@w0rd

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

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

Командлет 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin

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

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

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

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

Netdom resetpwd /Server:DomainController /UserD:Admin /PasswordD:Password /SecurePasswordPrompt

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

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

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

Nltest /query

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

Nltest /sc_reset:Domain

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

Nltest /sc_change_pwd:Domain

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

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

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

Nltest /query

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

netdom reset /d:Domain ComputerName

или

netdom reset /d:Domain ComputerName /server:DomainController /uo:Admin /po:Password

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

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

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

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

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

Заметим, что представленная далее инструкция подойдёт для компьютеров под управлением Windows 7, 8, XP или 10.

Причины возникновения ошибки

Не все знают, но после подключения к домену компьютеру присваивается уникальный номер, то есть идентификатор безопасности (в сокращении SID). Помимо этого, учётная запись ПК содержит пароль, который меняется или раз в 30 дней, или после длительного отсутствия входа в систему. Нередко человек неправильно выключает компьютер, из-за чего при последующем его запуске на экране появляется предложение восстановить контрольную точку. Если согласиться, то произойдёт откат операционной системы до более раннего состояния.

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

Варианты решения проблемы

Убрать сбой «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» не так сложно, как кажется. Главное – рассмотреть все представленные в нашей статье способы, чтобы не пропустить важной и полезной информации.

Удаление компьютера из домена

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

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

3. Теперь нажимаем по пункту «Свойства системы», а на открывшейся странице кликаем по строке «Изменить параметры». Также в зависимости от версии операционной системы название может быть другим, например, «Изменить настройки».

4. Переходим в подпункт «Имя компьютера». В данном разделе нажимаем по кнопке «Изменить» для внесения необходимых правок. Далее в строке «Является членом рабочей группы» вводим название самой группы и кликаем «Ок».

Обратите внимание, что если имя рабочей группы не менять, то кнопка «Ок» останется неактивной.

5. Подтверждаем перезагрузку компьютера нажатием по кнопке «Ок». Затем снова заходим в свойства системы, а конкретнее в раздел «Изменение имени компьютера или домена».
6. Далее в строке «Является членом домена» вводим нужное название домена.
7. Теперь нажимаем по кнопке «Ок», а после указываем данные от учётной записи пользователя, который авторизован в конкретном домене.
8. Соглашаемся с предложением перезагрузить компьютер (нажимаем «Ок»).

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

Использование утилиты Netdom

Заметим, что утилита Netdom входит в состав Windows Server начиная с 2008 года. Загрузить её на компьютер может любой пользователь, воспользовавшись составом пакета RSAT (Remote Server Administration Tools). Итак, не будет разглагольствовать, а перейдём непосредственно к инструкции:

1. Заходим в систему под учётной записью локального администратора. Для этого набираем запрос «.\Administrator» на экране входа в операционную систему.
2. Теперь в командную строку вводим команду Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password. Нажимаем по клавише Enter и проверяем информацию на дисплее. Чтобы компьютер не потерял составляющие компоненты команды, рекомендуем её скопировать, а после вставить.

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

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

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

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

Утилита PowerShell имеется в операционной системе Windows 8 и выше. Для более ранних версий необходима ручная установка. Также для корректной работы нужно загрузить на компьютер Net Framework 4 и выше. Если все требования соблюдены, то переходите к подробному руководству:

1. Заходим в систему под учётной записью администратора.
2. Запускаем утилиту PowerShell. Для этого переходим в меню «Пуск» и в поиске вводим название приложения. Далее запускаем первую программу из списка.
3. Теперь вписываем запрос Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin и также нажимаем Enter.

Стоит отметить, что содержание команды следующее:

• Server – название любого контроллера домена;
• Credential – название учётной записи администратора.

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

Отключение сетевого кабеля

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

Обратите внимание, что в большинстве случаев выполнить вход в систему невозможно.

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

Видеоинструкция

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

Заключение

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

Потеря доверительного отношения с доменом Windows и Active Directory — Блог

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

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

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

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

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

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

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

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

Есть несколько методов, которые позволяют это сделать, на самый простой, это вывести рабочую станцию из домена, а потом вновь её прописать. Для этого сначала выведем компьютер из домена, путем подключения к произвольной рабочей группе (Мой компьютер \ ПКМ \ Свойства \ Имя компьютера, имя домена и параметры рабочей группы \ Изменить параметры \ Изменить \ Является членом рабочей группы \ 123 \ ОК), а потом подключим обратно введя имя домена и перезагрузиться.

Данные действия следует выполнять под локальным администратором, так как под учеткой администратора домена вас может просто не пустить! В данной ситуации, если вы не знаете пароль от локального администратора, придется этот пароль сбросить. Об этом я уже рассказывал в уроке Сброс пароля учетной записи Windows XP Vista 7 2003 2008 и Сброс пароля администратора windows 7

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

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

Автор Белов Олег На чтение 5 мин. Просмотров 682 Опубликовано 03.09.2019

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

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

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

Недавно кто-то пожаловался на форумах сообщества Microsoft по поводу этой проблемы, сказав следующее:

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом; В чем может быть причина этой ошибки. Присоединение к домену решит эту проблему на несколько дней, а затем эта проблема снова появится. Есть ли какое-нибудь решение?

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

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

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

• Попробуйте войти локально как локальный администратор. После этого перейдите в инструмент Сеть Панель управления , выберите Изменить и введите имя рабочей группы, покинув домен. Затем перезагрузите компьютер и войдите в систему как локальный администратор.
• Попробуйте удалить существующую учетную запись компьютера в Диспетчер серверов , заново создать учетную запись компьютера, синхронизировать домен, а затем на клиенте снова присоединиться к домену.
• Сбросьте пароль локального администратора, а затем выйдите и войдите в систему как локальный администратор, чтобы проверить его. Затем вместо этого измените домен на члена рабочей группы, перезапустите, как будет предложено, войдите в систему как локальный администратор, а затем снова присоединитесь к домену.
• Войдите в AD, перейдите в область AD Домены и трасты . Найдите домен, щелкните по нему правой кнопкой мыши и перейдите к управлению. Затем найдите нужный компьютер на вкладке Компьютеры , щелкните его правой кнопкой мыши и выберите Сбросить учетную запись . После этого попробуйте войти в систему на клиентском компьютере, о котором идет речь.
• Удалите учетную запись компьютера из AD в оснастке Пользователи и компьютеры на рабочей станции DC или mgmt. Затем вручную добавьте учетную запись компьютера из оснастки Пользователи и компьютеры на рабочей станции DC или mgmt. Соблюдайте осторожность, чтобы при добавлении машины обратно в AD вводить имя пользователя домена для учетной записи, которая может войти на машину как участник пользователей, которые могут присоединить этот компьютер к домену. Затем перейдите на компьютер с проблемой, войдите с именем пользователя, затем добавьте его в домен с ПК

-ЧИТАЙТЕ ТАКЖЕ: случайно удалили учетную запись администратора? Вот как это исправить

Эти исправления также доступны для Windows 7 и Windows 10, поэтому обязательно попробуйте их:

1. Вставьте оригинальную установленную версию Windows Vista или Windows 7 DVD. Имейте в виду, что это должно соответствовать текущей установке. Это не сработает, если установочный DVD с Windows Vista x64 используется для установки Windows Vista x86 или наоборот. То же правило в Windows 7.
2. Перезагрузите компьютер и загрузитесь с DVD.
3. Выберите вариант Восстановить компьютер .
4. Запустите командную строку .
5. Введите C: или D: (в некоторых системах есть раздел восстановления на C 🙂 и нажмите ENTER .
6. Введите cd WindowsSystem32 и нажмите ENTER .
7. Введите copy Utilman.exe Utilman.exe.bak и нажмите ENTER .
   Введите copy cmd.exe utilman.exe и нажмите ENTER .
8. Введите выход , нажмите ENTER и перезапустите систему.
9. На экране входа в систему нажмите Ключ Windows + U и откройте окно cmd.exe.
10. Введите NET USER и нажмите ENTER . Типичный вывод, подобный этому, покажет:

    Учетные записи пользователей для РАБОЧЕЙ СТАНЦИИ ——————————————————————————
    Администратор ASPNET OwnerGuestКоманда успешно выполнена.

11. Чтобы изменить пароль пользователя с правами администратора, введите Пароль администратора NET USER . Измените пароль на желаемый пароль, например: 4dm! N123 и нажмите ENTER .
12. Теперь, вернувшись к экрану входа, войдите как Администратор. Если при входе учетная запись отключена произойдет сбой входа, попробуйте еще раз с другим именем пользователя. Пожалуйста, обратитесь к шагу 10, чтобы увидеть другие доступные учетные записи.
13. Находясь в Windows, щелкните правой кнопкой мыши на значке компьютера и выберите Свойства . Нажмите Расширенные настройки системы и в диалоговом окне Свойства системы выберите вкладку Имя компьютера и нажмите Изменить . кнопка. Выберите Рабочая группа в разделе Участник : и введите CONTOSO . После внесения изменений перезагрузите систему.
14. После перезагрузки системы снова войдите в систему и присоединитесь к домену CONTOSO, выполнив то же самое на шаге 13. Вместо выбора «Рабочая группа» выберите ДОМЕН . После внесения изменений перезагрузите компьютер и войдите в систему, используя свои учетные данные DOMAIN.

-ЧИТАЙТЕ ТАКЖЕ: почему вы должны выполнить обновление с Windows 8, 8.1 до Windows 10

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

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

Исправить проблему сбоя доверительных отношений без повторного присоединения домена — TheITBros

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

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

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

Или ошибка выглядит так:

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

Давайте попробуем понять, что означает эта ошибка и как ее исправить.

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

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

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

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

Наконечник . Вы можете настроить максимальный срок действия пароля учетной записи для компьютеров домена с помощью параметра GPO Член домена: Максимальный срок действия пароля учетной записи компьютера , который находится в следующем разделе редактора групповой политики: Конфигурация компьютера > Параметры Windows > Параметры безопасности > Локальные политики > Параметры безопасности .Вы можете указать количество дней от 0 до 999 (по умолчанию это 30 дней).

С помощью реестра можно настроить политику паролей учетной записи компьютера для отдельного компьютера. Для этого запустите regedit.exe и перейдите в раздел реестра HKLM \ SYSTEM \ CurrentControlSet \ Services \ Netlogon \ Parameters. Отредактируйте параметр MaximumPasswordAge и установите максимальный срок действия пароля компьютера в домене (в днях). Другой вариант — полностью отключить изменение пароля учетной записи компьютера, установив для параметра REG_DWORD DisablePasswordChange значение 1.

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

Срок действия паролей учетных записей компьютеров в Active Directory не истекает, поскольку политика паролей домена не применяется к объектам компьютеров AD. Ваш компьютер может использовать службу NETLOGON для автоматической смены пароля при следующем входе в домен, если его пароль старше 30 дней (обратите внимание, что пароль локального компьютера контролируется не AD, а самим компьютером).

Компьютер пытается изменить свой пароль на контроллере домена, и только после успешного изменения он обновляет свой локальный пароль (локальная копия пароля хранится в разделе реестра HKLM \ SECURITY \ Policy \ Secrets $ machine.ACC) .

Вы можете просмотреть время последней установки пароля для учетной записи объекта компьютера в домене AD с помощью командлета PowerShell Get-ADComputer (из модуля AD для Windows PowerShell). Запустите команду с именем компьютера:

 get-adcomputer -Identity Lon-Com212 -Properties PasswordLastSet 

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

В чем причина ошибки «Сбой доверительного отношения между этой рабочей станцией и основным доменом»?

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

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

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

Вы можете убедиться, что локальный пароль компьютера синхронизирован с паролем учетной записи компьютера в домене, управляемом с помощью командлета Test-ComputerSecureChannel . Вы можете использовать простую форму:

 Test-ComputerSecureChannel 

Или вы можете добавить параметр переключателя –Verbose :

 Test-ComputerSecureChannel -Verbose 

VERBOSE: Выполнение операции «Проверка компьютера» цель «Compname1».

True

VERBOSE: безопасный канал между локальным компьютером и доменом theitbros.com находится в хорошем состоянии.

Исправление доверительных отношений по домену Повторное присоединение

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

Самый очевидный способ старой школы восстановить доверительные отношения вашего компьютера в домене:

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

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

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

Наконечник . Чрезвычайно важно убедиться, что разница во времени между контроллером домена и клиентским компьютером составляет менее 5 минут.Чтобы правильно настроить синхронизацию времени в домене, см. Статью Настройка NTP в Windows с помощью GPO.

Reset-ComputerMachinePassword: как исправить неудачные доверительные отношения с помощью PowerShell?

Вы можете сбросить пароль компьютера с помощью командлета PowerShell Reset-ComputerMachinePassword. Это самый быстрый и удобный способ сбросить пароль компьютера, не требующий перезагрузки. В отличие от утилиты Netdom, PowerShell 3.0 или новее доступна во всех ОС Microsoft, начиная с Windows 8 / Server 2012.Вы можете установить его вручную (см. Здесь) в Windows 7, Server 2008 и Server 2008 R2 (также требуется Net Framework 4.0 или выше).

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

 Reset-ComputerMachinePassword -Server DomainController -Credential DomainAdmin 

• Server — имя любого контроллера домена;
• Учетные данные — пользователь домена (с разрешением на добавление компьютера в домен) или учетная запись администратора домена.

 Reset-ComputerMachinePassword -Server lon-dc01 -Credential corpdsmith 

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

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

Если вы получили сообщение об ошибке «Сервер RPC недоступен» или «Не удалось связаться с контроллером домена Active Directory (AD DC) для домена», попробуйте запустить командлет Reset-ComputerMachinePassword, проверьте настройки DNS на своем компьютере. и зоны DNS, следуя руководству, не удалось связаться с контроллером домена Active Directory.

Наконечник . Вы также можете восстановить безопасный канал между компьютером и доменом Active Directory с помощью командлета PowerShell Test-ComputerSecureChannel :

 Test-ComputerSecureChannel -Repair -Credential corpdsmith 

Использование Netdom resetpwd для исправления сбоя доверительных отношений без перезагрузки

dom Вы можете найти в Windows Server с версии 2008 года. Его можно установить на клиентский компьютер как часть пакета RSAT (Remote Server Administration Tools).Метод быстрый и эффективный. Чтобы использовать его, войдите в целевую систему с локальными учетными данными Administrator (!!!) (набрав «.Administrator» в окне входа в систему), откройте командную строку cmd.exe с повышенными привилегиями и выполните следующую команду:

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

• Server — имя любого контроллера домена
• UserD — имя пользователя с правами администратора домена или делегированными правами
• PasswordD — пароль администратора

 Netdom resetpwd / Server: lon-dc01 / UserD: dsmith / PasswordD: Str0NGestP @ $ 

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

Вы можете проверить безопасное соединение с доменом AD с помощью Netdom с помощью следующей команды:

 Netdom Verify WK_Salary12 /Domain:corp.contoso.com / UserO: dsmith / PasswordO: * 

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

Сброс безопасного канала Active Directory и пароля компьютера с помощью NLTEST

Кроме того, вы можете сбросить пароль компьютера в домене и безопасном канале с помощью встроенного инструмента Nltest :

 Nltest / sc_change_pwd: corp.Contoso.com 

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

Однако, в отличие от Netdom и Reset-ComputerMachinePassword, которые позволяют указывать учетные данные пользователя, Nltest работает в контексте текущего пользователя. Соответственно, если вы войдете в систему под локальной учетной записью и попытаетесь выполнить команду, вы получите сообщение об ошибке отказа в доступе.Из-за этого метод не всегда работает.

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

 nltest /sc_verify:corp.contoso.com 

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

Trusted DC Состояние состояния подключения = 0 0x0 NERR_Success

Состояние проверки доверия = 0 0x0 NERR_Success

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

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

. Указанное значение атрибута не является уникальным в лесу или разделе.Атрибут: servicePrincipalName Значение = TERMSRV / PDC
CN = PC1, OU = Computers, DC = theitbros, DC = com Winerror: 8647

Эта проблема указывает, что атрибут учетной записи компьютера SPN (имя участника-службы) в AD является заполнены неправильно или в домене несколько компьютеров с одинаковым значением атрибута servicePrincipalName.

Найдите проблемный компьютерный объект в консоли ADUC, перейдите на вкладку Attribute Editor и проверьте значение атрибута servicePrincipalName

Убедитесь, что ваш компьютерный объект имеет заполненное значение свойства SPN в следующем формате:

• HOST / computername1
• HOST / computername1.theitbros.com
• RestrictedKrbHost / computername1
• RestrictedKrbHost / computername1.theitbros.com
• TERMSRV / computername1
• TERMSRV / computername1.theitbros.com Атрибут FULLNAME из домена QualifiedDataDomainDDN

Имя домена. . Если эти записи SPN отсутствуют, вы должны создать их вручную.

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

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

 ldifde -f C: \ ps \ SPNList.txt -t 3268 -d DC = theitbros, DC = com -l serviceprincipalname -r (serviceprincipalname = *) 

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

Мне нравятся технологии и разработка веб-сайтов. С 2012 года я веду несколько собственных сайтов и делюсь полезным контентом о гаджетах, администрировании ПК и продвижении сайтов.

Последние сообщения Кирилла Кардашевского (посмотреть все).

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

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

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

Что заставляет компьютер домена терять доверительные отношения?

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

Два сценария, с которыми я сталкивался чаще всего, когда это происходит:

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

События Windows, связанные с выпадением компьютера из домена

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

Событие 3210 — Ошибка — NETLOGON

Этот компьютер не смог пройти аутентификацию с помощью \\ <ИМЯ DC>, контроллера домена Windows для домена , и поэтому этот компьютер может отклонять запросы на вход. Невозможность аутентификации может быть вызвана тем, что другой компьютер в той же сети использует то же имя или пароль для этой учетной записи компьютера не распознан.Если это сообщение появится снова, обратитесь к системному администратору.

Событие 8019 — Предупреждение — События DNS-клиента

Системе не удалось зарегистрировать записи ресурсов (RR) хоста (A или AAAA) для сетевого адаптера
с настройками:

<НАСТРОЙКИ ХОСТА>

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

Событие 130 — Предупреждение — Служба времени

NtpClient не смог установить одноранговый узел домена для использования в качестве источника времени из-за сбоя в установлении доверительных отношений между этим компьютером и доменом «» для безопасной синхронизации времени. NtpClient повторит попытку через 15 минут, а затем удвоит интервал повторных попыток. Ошибка была: отказ доверительных отношений между этой рабочей станцией и основным доменом. (0x800706FD)

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

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

В PowerShell 3.0 Microsoft представила командлет Test-ComputerSecureChannel . Это не говорит о названии, но этот командлет может не только проверить, действительно ли доверительные отношения домена компьютера, но и восстановить его, если это не так!

Использование Test-ComputerSecureChannel для проверки и восстановления доверительных отношений домена

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

PS C: \ Windows \ system32> Test-ComputerSecureChannel
Ложь

ОК.Мы подтвердили наши подозрения на основе событий Windows, которые мы видели в журнале. А теперь давайте поработаем над восстановлением доверия. Я собираюсь запустить Test-ComputerSecureChannel с параметром -Repair .

PS C: \ Windows \ system32> Test-ComputerSecureChannel -Repair
Test-ComputerSecureChannel: не удалось сбросить пароль безопасного канала для учетной записи компьютера в домене.
Операция завершилась неудачно за следующим исключением: неверное имя пользователя или пароль..
В строке: 1 символ: 1
+ Test-ComputerSecureChannel -Ремонт
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo: OperationStopped: (Win10A: String) [Test-ComputerSecureChannel], InvalidOperationExceptio
п
+ FullyQualifiedErrorId: FailToResetPasswordOnDomain, Microsoft.PowerShell.Commands.TestComputerSecureChannelComma
nd

Почему не удалось? Потому что, если вы помните ранее, когда я пытаюсь войти в систему с использованием пользователя домена, я получал сообщение об ошибке « Доверительные отношения между этой рабочей станцией и основным доменом не удалось. ”В настоящее время я вошел в систему, используя учетную запись локального администратора. Мне нужно использовать параметр -Credential и передать учетные данные для пользователя домена, у которого есть права на добавление компьютера в домен. Для этого я буду использовать Get-Credential и сохраню его в переменной с именем $ cred . Затем я передам эту переменную в командлет Test-ComputerSecureChannel .

Вот демонстрационное видео, а также команды и выходные данные ниже.

PS C: \ Windows \ system32> $ cred = Get-Credential

командлет Get-Credential в позиции 1 конвейера команд
Задайте значения для следующих параметров:
Учетные данные
PS C: \ Windows \ system32> Test-ComputerSecureChannel -Credential $ cred -Repair
Правда
PS C: \ Windows \ system32> Test-ComputerSecureChannel
Правда

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

Номер ссылки

PS C: \ Users \ aaron> Get-Help Test-ComputerSecureChannel

ИМЯ
Test-ComputerSecureChannel

ОБЗОР
Проверяет и восстанавливает безопасный канал между локальным компьютером и его доменом.

СИНТАКСИС
Test-ComputerSecureChannel [-Confirm] [-Credential ] [-Repair] [-Server ] [-WhatIf]
[<Общие параметры>]

ОПИСАНИЕ
Командлет Test-ComputerSecureChannel проверяет наличие канала между локальным компьютером и его доменом.
работает правильно, проверяя статус своих доверительных отношений.Если соединение не удается, вы можете использовать Ремонт
параметр, чтобы попытаться восстановить его. Test-ComputerSecureChannel возвращает $ True, если канал работает правильно и
$ False, если это не так. Этот результат позволяет использовать командлет в условных операторах функций и скриптов. Чтобы
Чтобы получить более подробные результаты тестирования, воспользуйтесь параметром Verbose.

Этот командлет работает так же, как NetDom.exe. И NetDom, и Test-ComputerSecureChannel используют службу NetLogon для
выполнять действия.ССЫЛКИ ПО ТЕМЕ
Интернет-версия: http://go.microsoft.com/fwlink/?LinkId=821645
КПП-Компьютер
Сбросить-ComputerMachinePassword
Перезапустить компьютер
Стоп-Компьютер

ЗАМЕЧАНИЯ
Чтобы просмотреть примеры, введите: «get-help Test-ComputerSecureChannel -examples».
Для получения дополнительных сведений введите: «get-help Test-ComputerSecureChannel -detailed».
Для получения технической информации введите: «get-help Test-ComputerSecureChannel -full».
Для получения интерактивной справки введите: «get-help Test-ComputerSecureChannel -online»

.

AD Устранение неполадок: сбой доверительных отношений между рабочей станцией и основным доменом — статьи TechNet — США (английский)

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

Каковы общие причины появления этого сообщения в клиентских системах?

У такого поведения может быть несколько причин.Ниже перечислены некоторые из них:

1. Один SID назначен нескольким компьютерам.
2. Если нарушен безопасный канал между контроллером домена и рабочими станциями
3. Если в атрибутах учетной записи компьютера не указано имя SPN или DNSHost
4. Устаревшие драйверы сетевой карты.

Как устранить эту проблему?

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

Один SID назначен нескольким компьютерам.

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

Разрешение

См. Ссылки ниже, в которых объясняется, как использовать Sysprep для изменения SID

http://www.techrepublic.com/blog/window-on-windows/how-do-i-change-the-sid-and-computer-name-of-a-cloned-virtual-machine/736

http://www.brajkovic.info/windows-server-2008/windows-server-2008-r2/how-to-change-sid-on-windows-7-and-windows-server-2008-r2-using -sysprep /

SID машины
Повторяющийся миф (почему Sysprep важен).

http: // blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx

Если безопасный канал между контроллером домена и рабочими станциями нарушен

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

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

Распространенная причина нарушения защищенного канала [пароль учетной записи компьютера] заключается в том, что пароль защищенного канала, хранящийся у члена домена, не совпадает с паролем, хранящимся в AD. Часто это вызвано восстановлением системы Windows (или возвращением к предыдущей резервной копии).
или снимок) на компьютере-члене, в результате чего в AD будет представлен старый (предыдущий) пароль учетной записи компьютера.

Разрешение

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

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

или.

Вы можете продолжить и сбросить учетную запись компьютера с помощью инструмента netdom.exe (http://support.microsoft.com/kb/216393)

netdom resetpwd / server: DC_NAME / userd: USERNAME / пароль: ПАРОЛЬ

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

http: // blogs.technet.com/b/asiasupp/archive/2007/01/18/typical-symptoms-when-secure-channel-is-broken.aspx

Если в атрибутах учетной записи компьютера не указано имя SPN или DNSHost

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

Разрешение

Чтобы проверить SPN и имя DNSHost, сделайте это на контроллере домена.

1. запуск —> Выполнить ——> Adsiedit.msc
2. Выберите раздел домена из вариантов.
3. Перейдите к учетной записи компьютера, на котором существует объект компьютера.
4. Щелкните правой кнопкой мыши объект компьютера ——-> перейдите в Свойства ———-> Редактор атрибутов
5. Найдите имя участника службы (SPN) и проверьте, существует ли запись (она состоит из
   Класс обслуживания , Хост , Порт и
   Имя службы )
   1. Формат — <класс обслуживания> / <хост>: <порт> / <имя службы>
   2. Требуются <класс обслуживания> и <хост> .Но
      <порт> и <имя службы> не являются обязательными.
6. Проверьте также атрибут DNSHost. Убедитесь, что он также существует с записью.

Формат — Computername.Domainname.com (например, Y12345.contoso.com)

Устаревшие драйверы

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

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

для получения дополнительной информации свяжитесь со мной по mohsen mottaghi

.Ошибка установки

Workflow Manager: Не удалось установить доверительные отношения для безопасного канала SSL / TLS — Статьи TechNet — США (английский)

При установке Workflow Host Manager вы можете получить следующую ошибку:

Обработка завершена

Проверка входных параметров и параметров конфигурации.

Установка автоматически сгенерированного сертификата.

Предоставление привилегии «Войти в качестве службы» учетной записи «Запуск от имени».

Запуск конфигурации рабочего процесса.

Настройка параметров выполнения рабочего процесса.

System.Management.Automation.CmdletInvocationException: провайдеру токенов не удалось предоставить токен безопасности при доступе к ‘ https: // host: 4446 / WorkflowDefaultNamespace / $ STS / Windows /’.
Поставщик токенов вернул сообщение: «Базовое соединение было закрыто: не удалось установить доверительные отношения для безопасного канала SSL / TLS.’. —> System.UnauthorizedAccessException: поставщик токенов не смог предоставить токен безопасности при доступе
‘ https: // host / WorkflowDefaultNamespace / $ STS / Windows /’. Поставщик токенов вернул сообщение: «Базовое соединение было закрыто: не удалось установить доверительные отношения для безопасности SSL / TLS.
канал. ‘. —> System.IdentityModel.Tokens.SecurityTokenException: провайдеру токенов не удалось предоставить токен безопасности при доступе к ‘ https: // host / WorkflowDefaultNamespace / $ STS / Windows /’.Поставщик токенов вернул сообщение: «Базовое соединение было закрыто: не удалось установить доверительные отношения для безопасного канала SSL / TLS.». —> System.Net.WebException: базовое соединение было закрыто: не удалось установить доверительные отношения для
безопасный канал SSL / TLS. —> System.Security.Authentication.AuthenticationException: удаленный сертификат недействителен в соответствии с процедурой проверки.

в System.Net.Security.SslState.StartSendAuthResetSignal (сообщение ProtocolToken, AsyncProtocolRequest asyncRequest, исключение исключения)

в System.Net.Security.SslState.StartSendBlob (входящий байт [], число Int32, asyncProtocolRequest asyncRequest)

в System.Net.Security.SslState.ProcessReceivedBlob (буфер Byte [], счетчик Int32, AsyncProtocolRequest asyncRequest)

в System.Net.Security.SslState.StartReceiveBlob (буфер Byte [], AsyncProtocolRequest asyncRequest)

в системе.Net.Security.SslState.StartSendBlob (входящий байт [], счетчик Int32, AsyncProtocolRequest asyncRequest)

в System.Net.Security.SslState.ProcessReceivedBlob (буфер Byte [], счетчик Int32, AsyncProtocolRequest asyncRequest)

в System.Net.Security.SslState.StartReceiveBlob (буфер Byte [], AsyncProtocolRequest asyncRequest)

в System.Net.Security.SslState.StartSendBlob (входящий байт [], число Int32, asyncProtocolRequest asyncRequest)

в системе.Net.Security.SslState.ProcessReceivedBlob (буфер Byte [], счетчик Int32, AsyncProtocolRequest asyncRequest)

в System.Net.Security.SslState.StartReceiveBlob (буфер Byte [], AsyncProtocolRequest asyncRequest)

в System.Net.Security.SslState.StartSendBlob (входящий байт [], количество Int32, AsyncProtocolRequest asyncRequest)

Эта ошибка вызвана отсутствием доверия между контекстом учетной записи (пользователя), запустившей установку, и службой Workflow Host Manager.Программа установки пытается отправить сообщение REST с помощью SSL. К сожалению, доверие цепочки сертификатов нарушено. Следующий
может вызвать эту ошибку:

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

2. Сертификат не является доверенным.

3. Ваш Fiddler запущен, а сертификат Fiddler не является доверенным.

.