3

проблема

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

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

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

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

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

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

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

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

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

Вопрос

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

3 ответа3

1

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

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

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

0

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

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

0

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .