Why is IIS Anonymous authentication being used with administrative UNC drive access?

Question

My account is local administrator on my machine.

If I try to browse to a non-existent drive letter on my own box using a UNC path name:

\mymachine\x$

my account would get locked out. I would also get the following warning (Event ID 100, Type “Warning”) 5 times under the “System” group in Event Viewer on my box:

The server was unable to logon the Windows NT account 'ourdomain\myaccount' due to the following error: Logon failure: unknown user name or bad password.

I would also get the following warning 3 times:

The server was unable to logon the Windows NT account 'ourdomain\myaccount' due to the following error: The referenced account is currently locked out and may not be logged on to.

On the domain controller, Event ID 680 of type “Failure Audit” would appear 4 times under the “Security” group in Event Viewer:

Logon attempt by:
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon account: myaccount

Followed by Event ID 644:

User Account Locked Out: Target Account Name: myaccount Target Account ID: OURDOMAIN\myaccount Caller Machine Name: MYMACHINE Caller User Name: STAN$ Caller Domain: OURDOMAIN Caller Logon ID: (0x0,0x3E7)

Followed by another 4 errors having Event ID 680.

Strangely, every time I tried to browse to the UNC path I would be prompted for a user name and password, the above errors would be written to the log, and my account would be locked out.

When I hit “Cancel” in response to the user name/password prompt, the following message box would display:

Windows cannot find \mymachine\x$. Check the spelling and try again, or try searching for the item by clicking the Start button and then clicking Search.

I checked with others in the group using XP and they only got the above message box when browsing to a “bad” drive letter on their box. No one else was prompted for a user name/password and then locked out.

So, every time I tried to browse to the “bad” drive letter, behind the scenes XP was trying to login 8 times using bad credentials (or, at least a bad password as the login was correct), causing my account to get locked out on the 4th try. Interestingly, If I tried browsing to a “good” drive such as “c$” it would work fine.

As a test, I tried logging on to my box as a different login and browsing the “bad” UNC path. Strangely, my “ourdomain\myaccount” account was getting locked out – not the one I was logged in as! I was totally confused as to why the credentials for the other login were being passed.

After much Googling, I found a link referring to some IIS settings I was vaguely familiar with from the past but could not see how they would affect this issue. It was related to the IIS directory security setting “Anonymous access and authentication control” located under:

Control Panel/Administrative Tools/Computer Management/Services and Applications/Internet Information Services/Web Sites/Default Web Site/Properties/Directory Security/Anonymous access and authentication control/Edit/Password

I found no indication while scouring the Internet that this property was related to my UNC problem. But, I did notice that this property was set to my domain user name and password. And, my password did age recently but I had not reset the password accordingly for this property. Sure enough, keying in the new password corrected the problem. I was no longer prompted for a user name/password when browsing the UNC path and the account lock-outs ceased.

Now, a couple of questions:

• Why would an IIS setting affect the browsing of a UNC path on a local box?
• Why had I not encountered this problem before? My password has aged several times and I’ve never encountered this problem. And, I can’t remember the last time I updated the “Anonymous access” IIS password it’s been so long. I’ve run the script after a password reset before and never had my account locked-out due to the UNC problem (the script accesses UNC paths as a normal part of its processing).
• Windows Update did install “Cumulative Security Update for Internet Explorer 7 for Windows XP (KB972260)” on my box on 7/29/2009. I wonder if this is responsible.

Answer 1

Because you had a WebDAV redirector hooked up - I forget what that looks like for XP, but I suspect you can un-bind it from the Bindings interface for a network adapter (possibly in the advanced view).

If you take a network trace of the same client connecting to another drive on a server with IIS installed, you'll see it make two (er three - see SMB) connection attempts, more or less simultaneously:

• an SMB connection to 445 (and 139, fastest respondent wins)
• an HTTP connection to port 80/443, trying to access the same share using WebDAV

So when you connected to your local machine with a DAV-enabled redirector, you triggered discovery of the IIS instance, and that probably triggered the account lockout (for the reasons you gave). Your IIS logs can be used to confirm/deny that.

Answer 2

Remove any cached password in your client machine and try again or lookout for possible Conficker traces :)

Answer 3

I am actually getting a few errors in the IIS space about my mapped drive..

http://server.domain.com.au/index.php?q=s$

Obviously, its shared as: s$ So its hidden from casual browsers, but, the request is actually making it to the webserver, which is rewriting the request as a above. (drupal ya know)

So, if you have a similar setup (IIS) you should be seeing requests for anything that isn't an actual share, and probably for those too, end up in your IIS logfiles.