Недавно я столкнулся с этой проблемой и на нескольких компьютерах, и, хотя это старый вопрос, я подумал, что опубликую что-то, поскольку есть исправление.
Я обнаружил, что это проблема в Windows 7, 8.1 и 10 (до 1607).
Проблема заключается в диспетчере учетных данных, но не в диспетчере учетных данных пользователей, а в системной учетной записи.
Поиск проблемы
Я столкнулся с этим с помощью объекта групповой политики, который делает копию файла с удаленного сервера. Все работало до тех пор, пока пользователь не изменил свой пароль домена, после чего мы начали блокировать учетные записи.
Раскопав его, я обнаружил событие 4098 в журнале приложений, в котором говорится следующее. Это было создано при каждом обновлении объекта групповой политики, независимо от того, было ли оно зарегистрированным пользователем с помощью gpupdate или фоновым обновлением.
Элемент предпочтения компьютера «deploy.config» в объекте групповой политики «File-Copy-GPO» не был применен, поскольку произошел сбой с кодом ошибки «0x8007052e Ошибка входа: неизвестное имя пользователя или неверный пароль». Эта ошибка была подавлена.
Копая дальше, я обнаружил событие EventID 14 в системном журнале, в котором говорится следующее. Учетная запись пользователя была заблокирована, поэтому я знал, что на правильном пути.
Пароль, хранящийся в диспетчере учетных данных, недействителен. Это может быть вызвано тем, что пользователь изменил пароль с этого компьютера или другого компьютера. Чтобы устранить эту ошибку, откройте диспетчер учетных данных на панели управления и повторно введите пароль для учетных данных.
В этот момент я впервые открыл диспетчер учетных данных, хотя, когда я продолжал проверять его у разных пользователей, в том числе у того, который блокировал, я не мог его найти. Это заставило меня задуматься о том, что я должен проверить диспетчер учетных данных систем, когда я смотрел вечер, даже когда никто не входил в систему в интерактивном режиме.
Решение
Использование psexec -i -s -d cmd
из командной строки с повышенными привилегиями, а затем в командной строке системной учетной записи, которая открыта работает, rundll32 keymgr.dll,KRShowKeyMgr
показал мне, что я искал. Для сервера, на котором размещался файл, который пытался скопировать объект групповой политики, имелись сохраненные учетные данные с использованием соответствующей учетной записи пользователя.
Ресурсы
Пытаясь найти информацию по этому вопросу, я наткнулся на этот вопрос, а также на следующие две страницы. Я надеюсь, что это поможет кому-то еще в будущем.
http://btburnett.com/2014/05/windows-domain-account-lockout-mystery.html
https://social.technet.microsoft.com/Forums/windows/en-US/e1ef04fa-6aea-47fe-9392-45929239bd68/securitykerberos-event-id-14-credential-manager-causes-system-to-login- к сети-с-инвалид? форум = w7itprosecurity