В небольшой сети машин (<1000) у нас есть пользователь, учетная запись которого блокируется через неопределенный интервал после смены пароля.
У нас возникли серьезные трудности с поиском источника недействительных попыток входа в систему, и я был бы очень признателен, если бы некоторые из вас смогли продумать свой мыслительный процесс и выполнить проверки, которые необходимо выполнить для решения проблемы.
Все, что я знаю наверняка, это то, что учетная запись блокируется несколько (5+) раз в день, я даже не могу быть уверен, что это из-за неудачных попыток входа в систему, поскольку нет записей об ошибках, пока учетная запись не заблокирована.
Пока я пробовал;
Я не понимаю, что попробовать. Я буду рад попробовать любые ваши предложения по диагностике проблемы. Думаю, мой вопрос сводится к простой просьбе;
Мне нужен способ получения источника (приложения / хоста) недействительных попыток входа в систему, которые приводят к блокировке учетной записи.
Я не уверен, возможно ли это вообще, но подозреваю, что я могу попробовать еще кое-что.
Большое спасибо,
Вид на город
РЕДАКТИРОВАТЬ - РЕШЕНО
TL; DR - Программа чтения RSS-каналов, настроенная на Client Box со старыми учетными данными, привела к тому, что программа непрерывной сборки (в которую читатель пытался войти) заблокировала учетную запись, поскольку каждые 5 минут выполнялась неудачная попытка входа в систему.
Стратегия
Я просмотрел журналы ключевых элементов инфраструктуры, которые у нас есть, и нашел нужное имя пользователя. Было ясно, что было много неудачных попыток для программного обеспечения непрерывной сборки. Затем это был случай выполнения захвата Wirehark между двумя блоками, чтобы попытаться выяснить, откуда мы получаем запросы. Мы убивали процессы, пока не нашли нужный.
Спасибо всем за помощь, теперь это звучит так просто!
FWIW (возможно, не так уж и много - просто выкидываю туда вещи), когда у нас была аналогичная проблема с доменом AD, мы, наконец, использовали этот набор инструментов это выследить преступника.
В одном случае это оказалась рабочая станция учебного зала в другом здании, в которую они вошли, но не вышли, несколько недель назад - и с тех пор ею не пользовались.
К сожалению, во многих случаях в журнале событий безопасности будет записано событие с идентификатором 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
Перезапустите службу входа в сеть, чтобы это вступило в силу. Подробная информация будет записана в:% 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)
Обратите внимание, что если у вас несколько контроллеров домена, при перезапуске службы входа в сеть на одном компьютере, который делает попытки входа в систему, может переключиться на другой контроллер домена, поэтому будьте готовы включить это на нескольких контроллерах постоянного тока. Если у вас есть многодоменная среда с дочерними доменами, вам, возможно, придется отследить это от дочернего домена до корневого домена и другого дочернего домена, прежде чем будет обнаружена машина-нарушитель. Машина-нарушитель может быть чем угодно, это не обязательно должна быть рабочая станция Windows. Это может быть многофункциональный сетевой принтер / копировальный аппарат или почтовый клиент, который пытается установить аутентифицированное SMTP-соединение с вашим сервером Exchange.
Похоже, вы перепробовали почти все. Я бы подумал, что в журнале безопасности указана рабочая станция, которая пыталась подключиться.
Видел это у некоторых пользователей с виртуальными машинами, которые подключили диск на физическом сервере, а затем виртуальная машина использовала старые учетные данные и забавно блокировала учетную запись. Поскольку виртуальная машина была отключена на две смены пароля, пользователи не думали проверять. Однако журнал безопасности дал нам имя компьютера.
Интересно услышать здесь решение