Why is IIS Anonymous authentication being used with administrative UNC drive access?
- by Mark Lindell
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.
