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

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

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

Минусы:
Необходимо запустить командную строку от имени локального администратора.
Данную утилиту необходимо заранее установить на компьютер, а при потере доверительных отношений с доменом у Вас не будет возможности установить ПО от имени доменного администратора или учётной записи с необходимыми правами.