Существует странная и сбивающая с толку (для меня и для пользователей) проблема, мешающая аутентификации. Я не знаю, как долго это происходит, но я считаю, что это будет довольно долго. Только недавно с помощью инструмента блокировки учетной записи я понял, что эти проблемы с аутентификацией иногда вызваны сбоями в системе, а не ошибкой пользователя.
Что происходит, так это то, что пользователь проходит аутентификацию правильно, но система отклоняет его пароль. Я хочу повторить: они входят в систему с правильным именем пользователя, паролем и доменом. Это не жирная аппликатура; это не проблема клиента; это не ошибка пользователя; это не просроченный пароль; это не относится к какой-либо услуге.
Поведение, когда пользователь правильно аутентифицируется, заключается в том, что контроллер домена сбрасывает счетчик «неудачных попыток входа» обратно в 0. В случае сбоя он увеличивает его и устанавливает время «последнего сбоя». Но когда возникает этот сбой, ничего не происходит; попытка аутентификации отклоняется, но счетчик не увеличивается на 1 и не сбрасывается, а время последней ошибки не изменяется.
Проблема возникает на нескольких устройствах и в разных службах. Сегодня у меня был ученик, который не смог войти в систему на нескольких компьютерах, а также в веб-почте. Я сравнил журналы событий с компьютера и контроллера домена; Я не вижу разницы между событиями, когда пользователь был ошибочно отклонен (и количество отказов не увеличивалось), и когда она была отклонена правильно, потому что я намеренно заставил ее ошибиться с паролем.
Я сделал это сам, пытаясь войти в только что созданную учетную запись студента (используя известную схему паролей). У меня такое случалось с пользователями многих служб, которые проходят аутентификацию через AD. Это случилось с персоналом, преподавателями и студентами. Насколько я могу судить, это проблема аутентификации непосредственно на контроллерах домена; что-то шаткое с учетной записью, но не один из типичных виновников просроченного пароля, отключения и т. д.
Сброс пароля устраняет проблему. Проблема просто уходит. Но частота возникновения проблемы (около 8-10 случаев только на этой неделе, максимум из 100 сбросов сетевых паролей) заставляет меня думать, что это серьезная проблема.
Я не знаю, как давно возникает эта проблема. Без использования инструмента блокировки учетной записи я бы никогда не увидел, что счетчик ошибок не увеличивается, и, следовательно, предположил бы, что пользователь ошибался, зная пароль. У меня было много случаев, когда пользователи клялись, что знают свой логин, и это «сработало вчера». Я не знаю, сколько раз это было правдой, если вообще. Даже после того, как я получил инструмент, проблема возникла несколько раз и возникла несколько месяцев, прежде чем я решил, что это реальная проблема. Я действительно поверил в это только после того, как на самом деле это случилось со мной, когда я набрал начальный пароль ученика и увидел, что счетчик отказов не растет.
Наша среда AD в основном находится на Windows server 2008. Некоторые контроллеры домена все еще являются Server 2003. Среда представляет собой единый домен. Если есть какие-либо другие технические подробности, необходимые для устранения неполадок, сообщите мне.
редактировать: Как показывает принятый ответ, это действительно была ошибка пользователя. Событие, которое «доказало» мне, что это настоящая проблема, произошло, когда я вошел в новую учетную запись, и это не удалось, не увеличив счетчик неверных паролей. У нас есть стандарты для новых учетных записей и для сброса паролей. Скорее всего, другой администратор проигнорировал стандарт и сбросил пароль этого пользователя на другой. Когда я попытался войти в систему под новым пользователем, и неверный пароль не увеличился (но я был отклонен), я подумал, что это доказательство проблемы. Многие пользователи Google не смогли найти страницу, описывающую ситуации, при которых количество неверных паролей не увеличивается ... надеюсь, этот ответ поможет кому-то другому в будущем.
У вас включена история паролей? Если введенный пароль совпадает с одним из двух последних паролей учетной записи, аутентификация будет отклонена, но badPwdCount не будет увеличиваться. Я пытаюсь обдумать оставшуюся часть вашего описания, но это, по крайней мере, объясняет «недостающий» приращение неверного пароля.
Перечитывая ваш вопрос, похоже, что административный сброс паролей всегда дает положительные результаты, верно? Также интересно, на какой ОС стоит ваш PDCe (2003, 2008). Существуют ли какие-либо брандмауэры, потенциально блокирующие доступ к PDCe (или любым другим DC в этом отношении)? Имейте в виду, что в то время как изменения пароля конечного пользователя передаются от клиента к локальному DC через протокол kpasswd (TCP / 464), уведомление PDCe об изменении пароля осуществляется через вызов RPC. Порты назначения будут изменены с 2003 на 2008 год.
Это похоже на проблему либо с вашей репликацией, либо с контроллером домена с ролью эмулятора PDC.
Ты можешь бежать netdom query fsmo на каждом DC и сравнить результаты с каждого? Убедитесь, что все они думают, что один и тот же сервер выполняет роль эмулятора PDC. Затем взгляните на вывод dcdiag и посмотрим, что там говорится. Также проверьте репликацию с помощью repadmin /showrepl против каждого DC.
Если бы мне пришлось делать совершенно слепое предположение, я бы сказал, что существует либо несоответствие в том, кто, по мнению контроллеров домена, владеет ролью эмулятора PDC, либо сервер, который когда-то ее держал, был неправильно списан и роль никогда не перемещалась.
Это не проблема, это особенность: Внесены улучшения для доменов на функциональном уровне Windows Server 2003 и выше. Когда неверный пароль совпадает с одной из двух последних записей в истории паролей, атрибут badPwdCount не увеличивается, а атрибут badPasswordTime не обновляется. Это означает, что обычные пользователи могут сделать больше попыток, прежде чем они будут заблокированы. Их попытки ввода неверных паролей, скорее всего, будут паролями, которые они использовали недавно.
Значение атрибута lockoutObservationWindow такое же. Но поскольку badPasswordTime не обновляется при каждой попытке неверного пароля, в некоторых случаях это влияет на количество попыток, разрешенных пользователям. BadPwdCount с большей вероятностью будет сброшен, когда пользователь попытается ввести старый пароль.
Эту новую функцию иногда называют историей паролей n-2. Самый последний предыдущий пароль обозначается как n-1. Следующими по времени являются n-2. Не все типы аутентификации используют эту новую функцию. Протоколы проверки подлинности Kerberos и NTLM поддерживают историю паролей n-2. Эти протоколы используются, когда для интерактивного входа в систему используется пароль или смарт-карта. Другие протоколы, такие как RADIUS и PEAP, могут увеличивать или не увеличивать badPwdCount при попытке ввода неверного пароля. Некоторые протоколы не пересылают попытки ввода неверного пароля в эмулятор PDC. Это может объяснить, почему пользователи телефонов могут быть заблокированы, если телефон неоднократно пытается аутентифицироваться с использованием неверного пароля.
Кроме того, система может знать о двух предыдущих паролях в истории только в том случае, если pwdHistoryLength составляет не менее 3. С этим параметром пользователь может менять 3 пароля, поэтому предыдущие 2 сохраняются в истории паролей. Если pwdHistoryLength равно 2, пользователь может переключаться между двумя паролями. В этом случае единственная попытка ввода пароля, которая не увеличивает значение badPwdCount, - это предыдущая. Система не сохраняет второй самый последний пароль.