A customer reported that IUSR_<COMPUTERNAME> account was locked out on his Windows 2003 server. IIS anonymous authentication was disabled on this server.

 

It is easy to identify this issue by enabling “Audit account logon events” and “Audit logon events” in Audit Policy:

 

 

 

From the security log we found w3wp.exe tried to logon IUSR_<COMPUTERNAME> account. However it failed due to “Unknown user name or bad password”. According to the account lockout policy this IUSR account was locked out.

 

We opened metabase.xml by Notepad and found AnonymousUserPass property appeared at not only the global level but also site and directory levels. Some of them had the different value from the global level property that meant the wrong password may be set at site/directory levels.  The problem has gone after we deleted these AnonymousUserPass property at site/directory levels. (IIS will use the value of AnonymousUserPass inherited from the global level)

 

Although currently anonymous authentication is disabled on this server, someone may enable it before and set wrong password. Then he may clear the checkbox “Enable anonymous access” again. AnonymousUserPass property will be left in IIS metabase at that site/directory level.

 

 

 

 

When the first request to that site/directory which has an AnonymousUserPass property, IIS will still try to call LogonUser API to create an anonymous user token and cache it although anonymous access is disabled at that level. If the password is invalid and there is a strict account lockout policy, that IUSR account will be locked out.

 

Conclusion

I recommend to use a single Anonymous user account at the global level and let all the websites and directories inherit from there.

 

Regards,

 

XinJin from APGC DSI Team