В один прекрасный день от офицера службы информационной безопасности поступает интересное письмо. На почтовых серверах в Security log появляются странные события о сбое в процессе аутентификации:
Log Name: Security Source: Microsoft-Windows-Security-Auditing Event ID: 4625 Task Category: Logon Level: Information Keywords: Audit Failure User: N/A Computer: mailserver1.domain.com Description: An account failed to log on. Subject: Security ID: SYSTEM Account Name: MAILSERVER1$ Account Domain: DOMAIN Logon ID: 0x3E7 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: Account Domain: Failure Information: Failure Reason: Account currently disabled. Status: 0xC000006E Sub Status: 0xC0000072 Process Information: Caller Process ID: 0x1c64 Caller Process Name: C:WindowsSystem32inetsrvw3wp.exe Network Information: Workstation Name: MAILSERVER1 Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: Authz Authentication Package: Kerberos Transited Services: - Package Name (NTLM only): - Key Length: 0
Вопрос – что это и что с этим делать?
Из интересного, на что стоит сразу обратить внимание – учётная запись, для которой произошёл сбой аутентификации в событии не указывается. Следовательно придётся исследовать что же это за учётная запись использовалась. Второе – для аутентификации использовался Керберос. Следовательно первая зацепка есть. Включаем дополнительное логгирование для Керберос на сервере, на котором ловим ошибки, как это описывается тут. По завершении процесса необходимо будет не забыть выключить дополнительное логгирование.
После включения параллельно с событием в Security Log начало появляться следующее событие в Event Log:
Log Name: System Source: Microsoft-Windows-Security-Kerberos Event ID: 3 Task Category: None Level: Error Keywords: Classic User: N/A Computer: mailserver1.domain.com Description: A Kerberos error message was received: on logon session Error Code: 0x12 KDC_ERR_CLIENT_REVOKED Extended Error: 0xc0000072 KLIN(0) Client Realm: Client Name: Server Realm: DOMAIN.COM Server Name: mailserver1$@DOMAIN.COM Target Name: mailserver1$@DOMAIN.COM@DOMAIN.COM
А вот это уже интересно. Есть замечательный документ, который я категорически рекомендую – Troubleshooting Kerberos Errors. Он утверждает, что в данной ситуации необходимо слушать трафик. Чем я и занялся. Спустя некоторое время, оба верхних события появились в логах. Network Monitor при этом выловил 2 пакета – запрос на получение билета (TGS Request) и ошибку (KRB_ERROR). Ошибка не очень интересна, потому что дополнительной информации, кроме KDC_ERR_CLIENT_REVOKED она не даёт. А вот TGS Request даёт дополнительную информацию:
- Kerberos: TGS Request Realm: DOMAIN.COM Sname: mailserver1$DOMAIN.COM - TgsReq: Kerberos TGS Request - KdcReq: KRB_TGS_REQ (12) - PaData: + PaData: PA-TGS-REQ (1) - PaData: PA-FOR-USER (129) - PaForUser: + UserName: SM_63b993a3b98c43b2b + UserRealm: DOMAIN
В PaData содержится метод PA-FOR-USER, который содержит данные учётной записи, которая используется при запросе билета. В данном случае это – DOMAINSM_63b993a3b98c43b2b или, говоря человеческим языком – SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}, стандартная учётка, которая используется Exchange-сервером при поисковых запросах. Так как по умолчанию она выключена, то KDC возвращает в итоге ошибку, а в лог идёт фраза “Account currently disabled”. Абсолютно правильное поведение KDC, как это описано тут.
Следующий вопрос – зачем сервер пытается для этой учётки получить билет Керберос я пока оставлю без ответа.
Полезные ссылки:
How to enable Kerberos event logging
Troubleshooting Kerberos Errors
Check Account Policy for Every Session Ticket Request
PA-FOR-USER