Why my account is getting locked out every one hour by Inetinfo.exe?
Recently we got an interesting case: Customer’s domain account would be locked out every one hour. Further more, based on security event log, the related process is Inetinfo.exe:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 529
User: NT AUTHORITY\SYSTEM
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: AccountName
Domain:
Logon Type: 3
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Caller Process ID: 1456
(Here 1456 is the Process ID of inetinfo.exe)
What to Check?
====================
At first, we thought it is due to customer’s user account was configured somewhere in IIS and the password was not refreshed. For example:
a) Being configured as anonymous account
b) Being configured as certain Application Pool’s identity
c) Being configured as certain COM+ component’s identity…
However, nothing valuable was found in metabase.xml and COM+ manager.
So we decide to set break points on the following functions in the inetinfo.exe process:
ADVAPI32!LogonUserExW
ADVAPI32!LogonUserExA
ADVAPI32!LogonUserW
ADVAPI32!LogonUserA
ADVAPI32!CreateProcessWithLogonW
Then whenever the problematic user account is used by inetinfo.exe, we can check the call stack/dump file to clarify the scenario. Fortunately, this time we got just what we want.
Root Cause:
==============
We got the following dump files every one hour when the account gets locked:
· PID-1456__INETINFO.EXE_Breakpoint_advapi32_LogonUserA__mini_1904_2009-04-28_16-04-42-207_05b0.dmp
· PID-1456__INETINFO.EXE_Breakpoint_advapi32_LogonUserA__mini_1904_2009-04-28_17-04-40-385_05b0.dmp
· PID-1456__INETINFO.EXE_Breakpoint_advapi32_LogonUserA__mini_1904_2009-04-28_18-07-45-420_05b0.dmp
· PID-1456__INETINFO.EXE_Breakpoint_advapi32_LogonUserA__mini_1904_2009-04-28_19-04-45-791_05b0.dmp
The call stacks are exactly the same:
advapi32!LogonUserA
exps!CExchAuthContext::HrCheckClearTextLogin+0x1af
exps!CExchAuthContext::HrServerNegotiateClearTextAuth+0xb6
exps!CExchAuthContext::HrServerNegotiateAuth+0x18
exps!CSessionContext::OnEXPSInNegotiate+0x14a
exps!CSessionContext::OnSmtpInCallback+0x2ae
smtpsvc!RemoteRetryQ::CreateNDR+0x99
Based on above information, we can see a SMTP client is trying to connect the IIS server with the problematic username and bad password and caused the account being lockout unexpectedly.
Solution:
===========
Since we already know the culprit is SMTP client, customer checked the SMTP log when the problem occurred to find out which SMTP client used the obsolete password.
Regards,
Yong Kang Chen