Why my account is getting locked out every one hour by Inetinfo.exe?

  • Article

 

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