Pull to refresh

Comments 36

Вместо того чтоб найти причину проблемы, приходится делать костыль.
У нас тоже такая проблема, решается путём отключения интернет кабеля/адаптера wifi (если он выключается физически). После пользователь заходит под своей учётной записью.
Тогда уже выводишь / вводишь обратно в домен- ребут и все проблема решена.
Но все же хочется узнать почему такое происходит и как вылечить данную проблему
UFO landed and left these words here
очень часто такое происходит из-за долго отсутствия клиента offline (восстановление системы как пример) если я правильно помню 60ть дней
Это происходит из-за истечения срока Kerberos ticket-a. Shaz правильно написал об этом. И еще можно восстанавливат, через PowerShell как показано далее по ссылке — https://m.youtube.com/watch?v=3M-UwCWUPdw
Мое видение причины проблемы.
Каждый компьютер в домене имеет пароль(пароль есть не только у пользователя), который переодически меняется(это происходит автоматически). Если пароль на компьютере по какой либо причине не совпадает с паролем в базе Active Directory, наблюдается сбой доверительных отношений. Чаще всего это происходит при восстановлении системы. Видимо при восстановлении системы пароль компьютера откатывается к предыдущему значению, которое не совпадает с текущем паролем в Active Directory, что и обуславливает проблему.
Вместо вывода из/ввода в домен используйте Идентификацию (Network ID на картинке). То же самое, но быстрее.
На сколько помню, такая пробема может возникать по причине истечения срока действия билета kerberos для ПК.
Особенно если этот ПК долгое время был неактивен. Один из вариантов решения — увеличить через GPO срок жизни этих билетов.
Восстанавление связи рабочей машины с доменом возможно также через PowerShell, посмотрите далее по ссылке https://m.youtube.com/watch?v=3M-UwCWUPdw.
Есть что-то ужасное в том, чтобы снимать видео про ввод «Test-ComputerSecureChannel -Repair» в консоли PowerShell.
Если человек тратит свое время, чтобы поделиться знаниями с кем-нибудь, то в этом нет ничего зазорного и ужасного, знания лишними не бывают! А для тех кто знает, повторение-мать учения.
Я к тому что в виде текста такая информация намного удобнее чем видео на две минуты.
а зачем было отключать локального админа? Если не делать эту глупость, то проблема решается за 1 минуту и 1 перезагрузку.
Если имеется ввиду администратор, которого Вы видите на фото, то это был тестовый компьютер для написания данного поста. Из-за этого он был отключен.
Вообще-то, с семерки и выше, локальный администратор всегда залочен, его надо вручную разблокировать.
Вообще да, builtin Администратор залочен, но что мешает групповыми политиками добавлять локальную учетку, к пример Admin и добавлять её в группу локальных администраторов и, таким образом, иметь локальную учетку с админскими правами даже на случай вылета компа из домена?

P.S. Хотя то, что я описал — тоже костыль, LAPS в данном случае самое верное решение.
Вообще-то, с восьмёрки и выше первая учётная запись во время установки ОС создаётся с админскими правами.
Поэтому при ручной установке её надо убивать сразу после ввода в домен.
А есть причина это делать? Администратор сам задаёт как имя, так и пароль для этой учётной записи.
Чтобы не оставалось административной учётки с одинаковым паролем (или вообще без него) на куче компьютеров.

Даже если случится чудо и хелпдеск начнёт придумывать сложный пароль для каждой установки, то их учёт превратится в ад с неминуемыми ошибками. Зачем рисковать при наличии простого и удобного решения?
Ставить систему руками и придумывать пароль вообще моветон. Создал образ и задал админу сложный пароль, и никаких проблем. А вся эта шизофрения с LAPS, отключением локальных учеток и прочее, к безопасности не имеет никакого отношения, если нет шифрования жесткого диска. 99% компаний это не нужно, а оставшийся процент умеет и знает что делать.
Моветон использовать один пароль более чем для одного объекта, а вектор атаки тут вполне реальный: стоит зайти под локальным админом на зараженную машину и малварь захватит всю сеть.
А если зайти под доменным админом, этого не произойдет? ну-ну
nltest обычно не нужны нужны доменные реквизиты, а для включения в домен не обязательно быть админом домена.
nltest /sc_reset аналогичен Test-ComputerSecureChannel -Repair.
В домене локального админа через командный файл создавать? Это как гланды колоноскопом смотреть. Учите групповые политики
Итак, приступим к изучению этой проблемы.

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

Так в чём корень проблемы и как её устранить?

Домен-контроллер это такая особенная разновидность домена?
Тоже частовато встечаюсь с этой проблеммой. Есть простой способ восстановить учетную запись компьютера. Если на компьютере, который вылетел с домена, есть незаблокированный локальный администратор, то можно запустить следующую команду на произвольном компьютере:
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 — пароль администратора домена.
При этом не требуется даже перезагрузка компьютера.
Спасибо Вам большое, вот это классный солушн! Well Done!
А вот прекрасная статья на технете, как ввести\вернуть рабочую станцию в домен, если сам домен недоступен.
https://technet.microsoft.com/en-us/library/offline-domain-join-djoin-step-by-step(v=ws.10).aspx
Only those users with full accounts are able to leave comments. Log in, please.