Комментарии 36
Вместо того чтоб найти причину проблемы, приходится делать костыль.
У нас тоже такая проблема, решается путём отключения интернет кабеля/адаптера wifi (если он выключается физически). После пользователь заходит под своей учётной записью.
Тогда уже выводишь / вводишь обратно в домен- ребут и все проблема решена.
Но все же хочется узнать почему такое происходит и как вылечить данную проблему
У нас тоже такая проблема, решается путём отключения интернет кабеля/адаптера wifi (если он выключается физически). После пользователь заходит под своей учётной записью.
Тогда уже выводишь / вводишь обратно в домен- ребут и все проблема решена.
Но все же хочется узнать почему такое происходит и как вылечить данную проблему
очень часто такое происходит из-за долго отсутствия клиента offline (восстановление системы как пример) если я правильно помню 60ть дней
Это происходит из-за истечения срока Kerberos ticket-a. Shaz правильно написал об этом. И еще можно восстанавливат, через PowerShell как показано далее по ссылке — https://m.youtube.com/watch?v=3M-UwCWUPdw
Мое видение причины проблемы.
Каждый компьютер в домене имеет пароль(пароль есть не только у пользователя), который переодически меняется(это происходит автоматически). Если пароль на компьютере по какой либо причине не совпадает с паролем в базе Active Directory, наблюдается сбой доверительных отношений. Чаще всего это происходит при восстановлении системы. Видимо при восстановлении системы пароль компьютера откатывается к предыдущему значению, которое не совпадает с текущем паролем в Active Directory, что и обуславливает проблему.
Каждый компьютер в домене имеет пароль(пароль есть не только у пользователя), который переодически меняется(это происходит автоматически). Если пароль на компьютере по какой либо причине не совпадает с паролем в базе Active Directory, наблюдается сбой доверительных отношений. Чаще всего это происходит при восстановлении системы. Видимо при восстановлении системы пароль компьютера откатывается к предыдущему значению, которое не совпадает с текущем паролем в Active Directory, что и обуславливает проблему.
На сколько помню, такая пробема может возникать по причине истечения срока действия билета kerberos для ПК.
Особенно если этот ПК долгое время был неактивен. Один из вариантов решения — увеличить через GPO срок жизни этих билетов.
Особенно если этот ПК долгое время был неактивен. Один из вариантов решения — увеличить через GPO срок жизни этих билетов.
Восстанавление связи рабочей машины с доменом возможно также через PowerShell, посмотрите далее по ссылке https://m.youtube.com/watch?v=3M-UwCWUPdw.
Откройте для себя LAPS и Test-ComputerSecureChannel -Repair.
а зачем было отключать локального админа? Если не делать эту глупость, то проблема решается за 1 минуту и 1 перезагрузку.
Если имеется ввиду администратор, которого Вы видите на фото, то это был тестовый компьютер для написания данного поста. Из-за этого он был отключен.
Вообще-то, с семерки и выше, локальный администратор всегда залочен, его надо вручную разблокировать.
Вообще да, builtin Администратор залочен, но что мешает групповыми политиками добавлять локальную учетку, к пример Admin и добавлять её в группу локальных администраторов и, таким образом, иметь локальную учетку с админскими правами даже на случай вылета компа из домена?
P.S. Хотя то, что я описал — тоже костыль, LAPS в данном случае самое верное решение.
P.S. Хотя то, что я описал — тоже костыль, LAPS в данном случае самое верное решение.
Вообще-то, с восьмёрки и выше первая учётная запись во время установки ОС создаётся с админскими правами.
Поэтому при ручной установке её надо убивать сразу после ввода в домен.
А есть причина это делать? Администратор сам задаёт как имя, так и пароль для этой учётной записи.
Чтобы не оставалось административной учётки с одинаковым паролем (или вообще без него) на куче компьютеров.
Даже если случится чудо и хелпдеск начнёт придумывать сложный пароль для каждой установки, то их учёт превратится в ад с неминуемыми ошибками. Зачем рисковать при наличии простого и удобного решения?
Даже если случится чудо и хелпдеск начнёт придумывать сложный пароль для каждой установки, то их учёт превратится в ад с неминуемыми ошибками. Зачем рисковать при наличии простого и удобного решения?
Ставить систему руками и придумывать пароль вообще моветон. Создал образ и задал админу сложный пароль, и никаких проблем. А вся эта шизофрения с LAPS, отключением локальных учеток и прочее, к безопасности не имеет никакого отношения, если нет шифрования жесткого диска. 99% компаний это не нужно, а оставшийся процент умеет и знает что делать.
Моветон использовать один пароль более чем для одного объекта, а вектор атаки тут вполне реальный: стоит зайти под локальным админом на зараженную машину и малварь захватит всю сеть.
А если зайти под доменным админом, этого не произойдет? ну-ну
nltest обычно не нужны нужны доменные реквизиты, а для включения в домен не обязательно быть админом домена.
В домене локального админа через командный файл создавать? Это как гланды колоноскопом смотреть. Учите групповые политики
Итак, приступим к изучению этой проблемы.
Спасибо за статью, но у вас в ней отсутствует именно изучение проблемы, подобными костылями пользуется большенство Windows-админов, ящитаю. Хотелось бы узнать почему такая проблема возникает и предотвратить подобные ситуации в будущем.
xSeries Спасибо за коммент. Не хочу повторяться, но выше в комментариях написано возникновение этой проблемы.
Так в чём корень проблемы и как её устранить?
Домен-контроллер это такая особенная разновидность домена?
Тоже частовато встечаюсь с этой проблеммой. Есть простой способ восстановить учетную запись компьютера. Если на компьютере, который вылетел с домена, есть незаблокированный локальный администратор, то можно запустить следующую команду на произвольном компьютере:
где ip_address — ip адресс компьютера, который вылетел с домена,
local_admin — локальный администратор,
local_admin_password — пароль локального администратора,
domaincontroller — fqdn контроллера домена
domain_admin — администратор домена,
domain_password — пароль администратора домена.
При этом не требуется даже перезагрузка компьютера.
wmic /NODE:ip_address/user:"ip_address\local_admin" /password:"local_admin_password" process call create "cmd.exe /C Netdom resetpwd /Server:domaincontroller /UserD:domain_admin /PasswordD:domain_password"
где ip_address — ip адресс компьютера, который вылетел с домена,
local_admin — локальный администратор,
local_admin_password — пароль локального администратора,
domaincontroller — fqdn контроллера домена
domain_admin — администратор домена,
domain_password — пароль администратора домена.
При этом не требуется даже перезагрузка компьютера.
А вот прекрасная статья на технете, как ввести\вернуть рабочую станцию в домен, если сам домен недоступен.
https://technet.microsoft.com/en-us/library/offline-domain-join-djoin-step-by-step(v=ws.10).aspx
https://technet.microsoft.com/en-us/library/offline-domain-join-djoin-step-by-step(v=ws.10).aspx
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как установить доверительные отношения между компьютером и основным доменом