Windows 7 проверяет подлинность кэшированных учетных данных при запуске

4840
Farray

проблема

У меня есть учетная запись пользователя домена Windows, которая автоматически блокируется на регулярной основе.

Устранение неполадок до сих пор

Единственное правило в домене, которое должно автоматически блокировать учетную запись, - это слишком много неудачных попыток входа в систему.

Я не думаю, что кто-то нечестивый пытается получить доступ к моей учетной записи. Проблема начала возникать после изменения моего пароля, поэтому я думаю, что это проблема сохраненных учетных данных. Кроме того, в системном журнале Просмотрщика событий я обнаружил предупреждения Security-Kerberos, в которых говорится:

Пароль, хранящийся в диспетчере учетных данных, недействителен. Это может быть вызвано тем, что пользователь изменил пароль с этого компьютера или другого компьютера. Чтобы устранить эту ошибку, откройте диспетчер учетных данных на панели управления и повторно введите пароль для учетных данных mydomain \ myuser.

Я проверил Диспетчер учетных данных, и все, что у него есть, это несколько TERMSRV/servernameучетных данных, хранящихся на удаленном рабочем столе. Я знаю, какие сохраненные учетные данные были неверными, но они были сохранены для доступа к удаленному рабочему столу на определенном компьютере и не использовались (по крайней мере, не мной) во время предупреждений. Security-KerberosПредупреждение появляется, когда система запуска (после обновления перезагрузки Windows), а также появилась сегодня утром, когда никто не вошли в машину.

Уточнение после ответа SnOrfus:

Был 1 набор неверных учетных данных, которые были сохранены для сервера терминалов. Остальные учетные данные известны как действительные (часто и недавно использовались без проблем). Я вошел в домен сегодня утром без проблем. Затем я запустил обновление Windows, которое перезагрузило компьютер. После перезагрузки я не смог войти (из-за блокировки аккаунта). После разблокировки и входа в домен я проверил Просмотр событий, который показал проблему с учетными данными после перезапуска.

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

Вопрос

Кто-нибудь знает, проверяет ли Windows 7 «случайным образом» проверку подлинности кэшированных учетных данных?

3

3 ответа на вопрос

1
Steven Evers

Нет, это не так. Я подозреваю, что может быть неправильно то, что у вас все еще сохранены предыдущие учетные данные. Попробуйте удалить сохраненные учетные данные из диспетчера учетных данных, а затем подключитесь и войдите в домен (это позволит повторно кэшировать ваши учетные данные).

После этого не должно быть никаких проблем.

Примечание. Существуют также методы, которые ваш системный администратор может использовать для истечения срока действия кэшированных учетных данных, но здесь это не так. Вы можете спросить, на всякий случай, хотя.

Понял, что там хранятся неверные учетные данные. Но он был сохранен для доступа к серверу терминалов ... зачем проверять его при запуске? Я удалил его, чтобы облегчить проблему блокировки, но корень проблемы все еще смущает меня. Farray 13 лет назад 0
0
Keltari

Некоторые проблемы с учетными данными могут быть связаны с неправильными настройками времени и Kerberos. Проверьте, работает ли машина, и убедитесь, что она пришла вовремя. Если нет, запустите w32tm /resyncЭто может помочь.

Более подробно об этом: Запуск `NET TIME` также скажет вам, какой источник клиент использует для обновления времени. Это ДОЛЖНО указывать на ваш сервер AD Canadian Luke 12 лет назад 0
0
David Remy

Недавно я столкнулся с этой проблемой и на нескольких компьютерах, и, хотя это старый вопрос, я подумал, что опубликую что-то, поскольку есть исправление.

Я обнаружил, что это проблема в 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

Похожие вопросы