Отслеживание не отслеживаемых блокировок учетных записей AD


5

Пользователь (назовем его «username») постоянно блокируется, и я не знаю почему. Еще один неверный пароль регистрируется каждые 20 минут на точке.

DC эмулятора PDC работает под управлением Server 2008 R2 Std. Событие с кодом 4740 зарегистрировано для блокировки, но имя компьютера вызывающей стороны пустое:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          5/29/2015 4:18:14 PM
Event ID:      4740
Task Category: User Account Management
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      FQDNofMyPDCemulatorDC
Description:
A user account was locked out.

Subject:
    Security ID:        SYSTEM
    Account Name:       MyPDCemulatorDC$
    Account Domain:     MYDOMAIN
    Logon ID:       0x3e7

Account That Was Locked Out:
    Security ID:        MYDOMAIN\username
    Account Name:       username

Additional Information:
    Caller Computer Name:   

Исходный контроллер блокировки работает под управлением Server 2003 под управлением IAS (RADIUS). Его журнал безопасности содержит соответствующее событие для блокировки учетной записи, но, конечно же, в нем также отсутствует источник (имя вызывающего компьютера):

Event Type: Success Audit
Event Source:   Security
Event Category: Account Management 
Event ID:   644
Date:       5/29/2015
Time:       4:18:14 PM
User:       NT AUTHORITY\SYSTEM
Computer:   MyRadiusDC
Description:
User Account Locked Out:
    Target Account Name:    username
    Target Account ID:  MYDOMAIN\username
    Caller Machine Name:    
    Caller User Name:   MyRadiusDC$
    Caller Domain:      MYDOMAIN
    Caller Logon ID:    (0x0,0x3E7)

Ведение журнала отладки NetLogon включено на исходном контроллере блокировки, а в журнале (C: \ WINDOWS \ debug \ Netlogon.log) показаны неудачные входы в систему из-за неверного пароля, но не из источника (вы можете увидеть, где написано «откуда», а затем между двумя пробелами, между пробелами должен быть источник попытки входа в систему):

05/29 16:18:14 [LOGON] MYDOMAIN: SamLogon: Network logon of MYDOMAIN\username from  Entered
05/29 16:18:14 [LOGON] MYDOMAIN: SamLogon: Network logon of MYDOMAIN\username from  Returns 0xC000006A

Журналы IAS (C: \ WINDOWS \ system32 \ LogFiles \ IN ######. Log) не показывают никаких подключений RADIUS от этого пользователя за последние 2 дня.

Я не знаю, где, черт возьми, пойти отсюда, кроме как проклинать Microsoft, пока я не задохнусь. У кого-нибудь есть идеи, которые могут быть более продуктивными? :-D


1
Можете ли вы включить аудит отказов для попыток аутентификации? Полное событие будет иметь немного больше деталей, чем журнал отладки netlogon, но все равно может не помочь. Это всегда было РАДИУСОМ, когда я сталкивался с отсутствующим источником, для чего это стоит.
Шейн Мэдден

Спасибо! Клянусь, я проверил это некоторое время назад, но, возможно, кто-то изменил это (слишком много администраторов домена). Конечно, в нашем GPO по умолчанию для контроллеров домена отключен аудит сбоев. Я включу его (после соответствующего процесса управления изменениями) и надеюсь получить дополнительную информацию.
Феанор

1
У него есть какое-либо мобильное устройство (телефон, планшет), настроенное с его учетной записью, которое продолжает пытаться войти в него?
Дан

Я проверил и подтвердил, что у него 0 устройств Exchange ActiveSync. Однако это очень распространенная причина блокировок, поэтому я уверен, что такое устройство приведет к блокировке учетной записи с сервера клиентского доступа Exchange, а не к пустому источнику. Я автоматически идентифицирую их и сообщаю в службу поддержки, какие устройства показывают попытки несанкционированного доступа в журналах Exchange CAS IIS.
Феанор

Очевидно, есть хитрость в получении правильной информации в журнале: jackstromberg.com/2013/03/… конкретно: support.microsoft.com/en-us/kb/109626/en-us
Мэри,

Ответы:


1

Я только что закончил разговор с Microsoft об этом, так что, надеюсь, следующая информация поможет :)

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

Служба EAPHost, которую я нахожу, не имеет фантастической регистрации аутентификации (на самом деле это ужасно - файл трассировки), поэтому, если по какой-либо причине аутентификация завершается неудачно в EAPHost, попытка аутентификации регистрируется с использованием несколько общих идентификаторов событий аутентификации в журнале событий и ничего все в журналах IAS.

Мы обнаружили, что недавно построенный сервер RADIUS регистрирует гораздо больше информации в журналах IAS, чем наша производственная система. Я прошел переконфигурированное ведение журнала через журнал конфигурации, чтобы включить учетную информацию (отметьте все поля в мастере!), Перезапустил службу и обнаружил, что все отсутствующие события IAS теперь регистрируются, включая MAC-адреса и SSID, в файлы журнала IAS.

Надеюсь, что это может помочь :)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.