Вредоносное ПО (malware) - это назойливые или опасные программы,...
Рано или поздно, но администраторам доменной сети на базе продуктов Microsoft приходится сталкиваться с двумя похожими ошибками: «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» и «База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией» . Помимо данных сообщений также наблюдается невозможность зайти в компьютер под доменными учетными записями.
Разберем причины появления ошибок и методы их лечения.
В доменных сетях Windows всем компьютерам и учетным записям пользователей присваиваются свои идентификаторы безопасности (SID). В сущности, можно сказать, что каждый компьютер в домене также обладает своей учетной записью типа «компьютер». По аналогии с учетной записью пользователя, такая учетная запись тоже будет иметь пароль. Данный пароль создается и предъявляется компьютером контроллеру домена автоматически. Таким образом между рабочими станциями и контроллером домена и формируются те доверительные отношения, о которых упоминается в тексте ошибок.
Каждые 30 дней или при первом включении после длительного перерыва компьютер автоматически изменяет свой пароль. В теории всё красиво, и машина вроде бы не может ошибиться и «ввести» неправильный пароль. Однако иногда такое происходит по нескольким причинам.
Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом
Самой распространенной причиной является откат операционной системы Windows на более ранее состояние. Естественно, чем раньше была создана точка восстановления, тем больше вероятность появления ошибки. В данном случае после восстановления компьютер примется предъявлять контроллеру домена устаревший пароль, а контроллер уже содержит новый.
Ошибка может возникнуть и в случае нахождения в домене двух станций с одинаковыми именами. Такая ситуация может возникнуть, например, если дать новому компьютеру имя выведенной из эксплуатации машины, а затем снова включить старый компьютер, забыв его переименовать.
С возможными причинами разобрались. Теперь о решении проблемы. Способов несколько, но все они так или иначе заключаются в переустановке учетной записи компьютера или сбросе его пароля.
Первый способ заключается в переустановке учетной записи в .
После этого необходимо зайти на компьютер под локальным администратором и вывести рабочую станцию из домена в рабочую группу (компьютер → свойства → дополнительные параметры системы → имя компьютера → изменить).
Вторым способом является сброс пароля через . Оговоримся однако, что нам потребуется 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Во втором случае мы явно указываем контроллер домена, с которым хотим установить доверительные отношения.
Утилита порадует нас сообщением о том, что безопасный канал был сброшен и новое соединение установлено.
Итак, вот несколько способов восстановить доверительные отношения в домене. Надеюсь, что применять их вам придется как можно реже. 🙂
Одной из периодических ошибок, с которыми приходится сталкиваться системному администратору это ошибка «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом». Данная ошибка появляется, когда пользователь пытается выполнить вход в систему, вводит логин и пароль, а в итоге получает это сообщение. В большинстве случаев это связано с откатом системы до более раннего состояния.
В чем же причина подобного поведения? Дело в том, что учетной записи компьютера подключенного к домену присваивается идентификатор безопасности (SID) на уровне которого осуществляется доступ к домену, а так же пароль, который автоматически меняется каждые 30 дней без участия пользователя.
Так вот, в момент восстановления контрольной точки, система может быть восстановлена на момент, когда действовал еще старый пароль и при подключении к домену, пароль на рабочей станции и контроллере домена будут различные, что и вызовет ошибку «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом». В данной ситуации, необходимо сделать так, чтобы эти пароли совпадали!
Не смотря на это, доступ к рабочей станции все же можно получить, для этого нужно отключить сетевой кабель от компьютера и вновь ввести пароль. В результате чего, данные для проверки просто некуда будет отправлять, и система вас впустит, так как пароль от учетной записи вы ввели правильно. После чего, подключаем кабель и работаем. Но, это не решение проблемы, так как каждый раз потребуется выполнять данные манипуляции, а так же определенные функции не будут работать.
Есть несколько методов, которые позволяют это сделать, на самый простой, это вывести рабочую станцию из домена, а потом вновь её прописать. Для этого сначала выведем компьютер из домена, путем подключения к произвольной рабочей группе (Мой компьютер \ ПКМ \ Свойства \ Имя компьютера, имя домена и параметры рабочей группы \ Изменить параметры \ Изменить \ Является членом рабочей группы \ 123 \ ОК ), а потом подключим обратно введя имя домена и перезагрузиться.
Данные действия следует выполнять под локальным администратором, так как под учеткой администратора домена вас может просто не пустить! В данной ситуации, если вы не знаете пароль от локального администратора, придется этот пароль сбросить. Об этом я уже рассказывал в уроке Сброс пароля учетной записи Windows XP Vista 7 2003 2008 и Сброс пароля администратора windows 7
Хотя, некоторые рекомендуют, для решения возникновения ошибки «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» в будущем, вообще отключить службу восстановления при загрузке, чтобы откат не выполнялся в автоматическом режиме. Но, здесь бы я отнесся с осторожностью и выполнял данное отключение в крайнем случае, дабы не уменьшить себе количество средств для восстановления работоспособности при возможных сбоях в работе. В любом случае, если откат выполняется периодически, тут лучше не службу отключать, а разобраться в сути проблемы!
Бывает такая ситуация, что компьютер не может пройти проверку подлинности в домене. Вот несколько примеров:
- После переустановки ОС на рабочей станции машина не может пройти проверку подлинности даже с использованием того же имени компьютера. Поскольку в процессе новой установки ОС генерируется SID-идентификатор и компьютер не знает пароль учетной записи объекта компьютера в домене, он не принадлежит к домену и не может пройти проверку подлинности в домене.
- Компьютер полностью восстановлен из резервной копии и не может пройти проверку подлинности. Возможно, после архивации объект компьютера изменил свой пароль в домене. Компьютеры изменяют свои пароли каждые 30 дней, а структура Active Directory помнит текущий и предыдущий пароль. Если была восстановлена резервная копия компьютера с давно устаревшим паролем, компьютер не сможет пройти проверку подлинности.
- Секрет LSA компьютера давно не синхронизировался с паролем, известным домену. Т.е. компьютер не забыл пароль - просто этот пароль не соответствует реальному паролю в домене. В таком случае компьютер не может пройти проверку подлинности и безопасный канал не будет создан.
Основные признаки возможных неполадок учетной записи компьютера:
- Сообщения при входе в домен указывают, что компьютеру не удалось установить связь с контроллером домена, отсутствует учетная запись компьютера, введен неправильный пароль учетной записи компьютера или потеряно доверие (безопасная связь) между компьютером и доменом.
- Сообщения или события в журнале событий, указывающие аналогичные ошибки или предполагающие неполадки паролей, доверительных отношений, безопасных каналов либо связи с доменом или контроллером домена. Одна из таких ошибок - отказ проверки подлинности с кодом ошибки 3210 в журнале событий компьютера.
- Учетная запись компьютера в Active Directory отсутствует.
Как лечить?
Необходимо переустановить учетную запись компьютера. В сети есть рекомендации по такой переустановки: удалить компьютер из домена, чтобы потом повторно присоединить его. Да, это работает, но данный вариант не рекомендуется делать по причине того, что теряется SID-идентификатор и членство компьютера в рабочей группе.
Поэтому необходимо сделать так :
Открыть оснастку Active Directory, выбрать "Пользователи и компьютеры", щелкнуть объект компьютера правой кнопкой мыши и применить команду "Переустановить учетную запись". После этого компьютер следует заново присоединить к домену и перезагрузиться.
C помощью учетной записи, относящейся к локальной группе "Администраторы":
netdom reset Имя_машины /domain Имя_домена /Usero Имя_пользователя /Passwordo {Пароль | *}
На компьютере, где утрачены доверительные отношения:
nltest /server:Имя_сервера /sc_reset:ДОМЕН\Контроллер_домена
В этой статье мы коснемся проблемы нарушения доверительных отношений между рабочей станцией и доменом, мешающей пользователю авторизоваться в системе. Рассмотрим причину проблемы и простой способ восстановления доверительных отношений по безопасному каналу.
Как проявляется проблема: пользователь пытается авторизоваться на рабочей станции или сервере под своей учетной запись и после ввода пароля появляется ошибка:
Не удалось восстановить доверительные отношения между рабочей станцией и доменом
Или такая:
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 дней).
Если пароль компьютера просрочен, он автоматически меняется при следующей регистрации в домене. Поэтом, если вы не перезагружали компьютер несколько месяцев, доверительные отношения между ПК и доменом сохраняются, а пароль компьютера будет сменен при следующей перезагрузке.
Доверительные отношения разрываются, если компьютер пытается аутентифцироваться в домене под неверным паролем. Обычно это происходит, когда компьютер или из снапшота виртуальной машины. В этом случае пароль машины, хранящийся локально, и пароль в домене могут не совпадать.
«Классический» способ восстановить доверительные отношения в этом случае::
- Сбросить пароль локального администратора
- Вывести ПК из домена и включить его в рабочую группу
- Перезагрузится
- С помощью оснастки – сбросить учёту компьютера в домене (Reset Account)
- Повторно включить ПК в домен
- Еще раз перезагрузиться
Этот метод самый простой, но слишком топорный и требует как минимум двух перезагрузок и 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
Командлет появился в 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
Как вы видите, восстановить доверительные отношения в домене довольно просто.