LDAP учетная запись периодически блокируется после изменения пароля – Поиск источника недействительных попыток

В небольшой сети машин (<1000) у нас есть пользователь, чья учетная запись блокируется через неопределенный интервал после изменения пароля.

Мы испытываем серьезные трудности с поиском источника недействительных попыток входа в систему, и я буду очень признателен, если кто-то из вас сможет пройти через свой мыслительный процесс и проверки, которые вы бы выполнили для решения проблемы.

Все, что я точно знаю, это то, что учетная запись блокируется несколько (более 5) раз в день, я даже не могу быть уверенным, что это связано с неудачными попытками входа, так как нет записей о неудачах до блокировки учетной записи.

На данный момент я попробовал;

• Выйти из всех служб, о которых мы можем подумать, и войти заново с новым паролем
• Просканировать компьютер пользователя на предмет нестандартного программного обеспечения, которое могло бы выполнять LDAP-запросы
• Проверить все установленные службы на наших рабочих машинах, чтобы убедиться, что ни одна из них не пытается работать под этой учетной записью
• Вернуть пользователя к старому паролю (проблема сохраняется, так что, возможно, изменение пароля — это ложный след)
• Wireshark на машине, где выполняется множество LDAP-аутентификаций – Отказы происходят только после того, как учетная запись уже заблокирована
• Очистить кэш учетных данных в – Панель управления -> Учетные записи пользователей -> Дополнительно
• Посмотреть на локальную

Я в замешательстве, что пробовать дальше. Я готов попробовать любые ваши предложения, чтобы диагностировать проблему. Я думаю, что мой вопрос сводится к простой просьбе;

Мне нужна техника для определения источника (приложение/хост) недействительных попыток входа, из-за которых блокируется учетная запись.

Я не уверен, возможно ли это, но подозреваю, что есть еще что-то, что я могу попробовать.

Большое спасибо,

CityView

ИЗМЕНЕНИЕ – РЕШЕНО

Кратко – Читалка RSS, настроенная на клиентском компьютере со старыми учетными данными, вызвала блокировку учетной записи программным обеспечением для непрерывной сборки (в которое читалка пыталась войти), так как каждые 5 минут происходила неудачная попытка входа.

Стратегия

Я просмотрел журналы для ключевых компонентов инфраструктуры, grep-ая по рассматриваемому имени пользователя. Было очевидно, что было много неудачных попыток для программного обеспечения непрерывной сборки. Затем мы выполнили захват Wireshark между двумя машинами, чтобы попытаться определить, откуда приходят запросы. Мы убивали процессы, пока не нашли нужный.

Спасибо всем за помощь, сейчас это звучит так просто!

К сожалению, существует множество обстоятельств, когда в журнале событий безопасности будет событие с ID 680, которое будет выглядеть так, а имя рабочей станции будет пустым.

680,AUDIT FAILURE,Security,Fri Feb 25 14:29:37 2011,NT AUTHORITY\SYSTEM,Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0    Logon account:  jdoe    Source Workstation:     Error Code: 0xC0000064    

Один из способов получить больше информации — это включить подробное журналирование netlogon. На контроллерах домена, где записываются события, создайте следующее значение реестра:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"DBFlag"=dword:24401F04

Перезапустите службу netlogon, чтобы это вступило в силу. Подробная информация будет записана в: %systemroot%\debug\netlogon.log и netlogon.bak. Журнал будет перекатываться и переименовываться в .bak около 19 МБ. После одного из событий сделайте копию двух файлов с контроллера домена, где произошло событие, и откройте их в текстовом редакторе, чтобы найти имя пользователя.

Если повезет, он будет содержать что-то подобное:

02/12 10:54:39 [LOGON] ACMI: SamLogon: Transitive Network logon of (null)\jdoe from  (via EXCHANGE2) Entered
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: jdoe: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:0 DC:0
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: Username jdoe is hq.acme.com\jdoe (found On GC)

Обратите внимание, что если у вас несколько контроллеров домена, при перезапуске службы netlogon на одном из них машина, которая делает попытки входа, может переключиться на другой контроллер домена, так что будьте готовы включить это на более чем одном контроллере домена. Если у вас есть многоуровневая доменная структура с дочерними доменами, возможно, вам придется отследить это от дочернего домена к корневому домену и другому дочернему домену, прежде чем найти проблемную машину. Проблемной машиной может оказаться все что угодно, она не обязательно должна быть рабочей станцией на Windows. Это может быть многофункциональный сетевой принтер/копир, или почтовый клиент, который пытается установить аутентифицированное SMTP-соединение с вашим сервером Exchange.

Для вашего сведения (возможно, это не имеет значения – просто хочу поделиться опытом), когда у нас была аналогичная проблема с AD-доменом, в конечном итоге мы использовали этот набор инструментов для поиска нарушителя.

В одном случае оказалось, что это была рабочая станция из учебного класса в другом здании, в которую они вошли, но не вышли, недели назад – и она не использовалась с тех пор.

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

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

Буду рад услышать решение этой проблемы.