Troubleshooting Anonymous authentication failures in IIS
Recently I was checking MSDN and KBs for a quick check on troubleshooting anonymous authentication, and sadly I could not find a single article devoted to it (that's strictly my personal experience). We often get calls on issues related to Anonymous authentication failures and this is something which I feel a user can fix oneself without requiring our support. My aim in this post is to ensure people have a good troubleshooting strategy for anonymous authentication failures.
As with all my posts I won't get into much of concept building stuffs here on anonymous authentication in IIS; reason again being the same, you will find tonnes of articles on the Net talking about it and I don't want to be another one.
So in brief Anonymous authentication in IIS is a type of access wherein any user can freely access the site. It's like a public website open to all.
So let's get started....
Anonymous authentication uses a local or domain account when user tries to access a webpage in IIS (By default it is of the form IUSR_<machinename>).
All the webpages which have anonymous authentication will use an account in order to access a page, and depending upon whether the account has permission or not the page will be rendered. Typically if anonymous authentication fails, you will see 401.1 in the error page shown by IIS. This means that Anonymous user account for that page doesn't have necessary permissions to the page or else some other settings like Domain or local policy is restricting the access.
If you have set only anonymous authentication for your web resource (that means no other authentication like Windows integrated or Basic ), and it fails then you will be shown 401.1 directly without any challenge which generally prompts to enter credentials.
Wanna know how IIS negotiates an authentication, check this.
If you want to check the anonymous username being used for a website or a virtual directory, type in this command at the following location:
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/anonymoususername
or,
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/Anonymoususername
or,
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/<Virtual directory>/anonymoususername
[If you get the result like: The parameter "anonymoususername" is not set at this node, it means it is inheriting the settings from its parent level.]
If you want to check where all Anonymous username is set at a webserver level, you can type in:
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs find anonymoususername
Typically the Anonymous username is in the form of IUSR_<machinename>, wherein machinename is the server name.
Although you can set it to a different value by manually changing it. It can be a local account to the server or a domain account.
A caveat here, it's a security risk if you make anonymous username as part of an Administrator group (remember it allows access to everyone on the net without asking for credentials).
To set an anonymous username at a website level, you can type in:
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/anonymoususername <your desired username> (Remember to include quotes around the username). [This setting is at the global level, i.e. for all the websites in the server provided you don't manually override the settings at a specific website or Virtual directory level]
or
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/<Website Identifier>/anonymoususername <your desired username> [At a specific website level]
or
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/<Website Identifier>/<Virtual directory>/anonymoususername <your desired username> [At a specific Virtual directory level in a specific website]
I will move forward with specific issues one by one:
Anonymous user account is locked out:
Ensure that the account is not locked, disabled or expired.
Password Synchronization issues:
I have seen a lot of support calls (I mean a LOT) where password synchronization has been the issue, and this is very very simple to fix.
Anonymous username's password are stored in two places in IIS 6.0: In the IIS metabase and in the SAM database.
If the password at these places are not synchronized (not same), anonymous authentication will fail. They have to be same.
So do this as the first step in troubleshooting:
1) Find out how many places we have the anonymousername set by following the command I mentioned above. Here I mention it again:
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs find anonymoususername
2) If you have it set at multiple places, find out the specific site you are having problem with. Check the anonymous username for it and then check the password.
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/anonymoususerpass
[You may find the password in encrypted format like ************. In such a case you need to modify the adsutil.vbs file to get the exact password. Open Adsutil.vbs in notepad from the above location and search for the function "IsSecureProperty(ObjectParameter,MachineName)".
In this function IsSecureProperty(ObjectParameter,MachineName), you will find the following code:
Function IsSecureProperty(ObjectParameter,MachineName)
On Error Resume Next
Dim PropObj,Attribute
Set PropObj = GetObject("IIS://" & MachineName & "/schema/" & ObjectParameter)
If (Err.Number <> 0) Then
ReportError ()
WScript.Echo "Error trying to get the property: " & err.number
WScript.Quit (Err.Number)
End If
Attribute = PropObj.Secure
If (Attribute = True) Then
IsSecureProperty = True <--------
Else
IsSecureProperty = False
End If
End Function
In the highlighted line above, change the value to False, save and now rerun the adsutil.vbs command and you should see the actual password]
or if you have it set at the global level only, check this:
<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/anonymoususerpass
Copy the password from here and go to Computer management->System Tools->Local Users and Groups->Users
You should find the username (By default, IUSR_<machinename> is used by IIS) [Unless you have Domain controller and Web server running on the same box. In such a case you need to look for the domain user name under Active Directory Users and Computers. I will talk about DC and IIS running on the same box later, this is really important!]
Change the password for Username (or, IUSR_<machinename>), by pasting the password that you got from metabase.
Ideally, if the issue was with Password synchronization your problem should get resolved at this point :) If not, then move on....
NTFS permission for the requested web resource:
NTFS permissions not set properly for the content can also cause 401.1 (although you should typically see 401.3 Access denied due to ACL). Ensure that the page we are trying to access has necessary NTFS permissions for Anonymous username (or the group that anonymous username belongs to). Ensure that Anonymous user account is part of the Users group.
Policy settings:
If your issue did not get resolved by Password synchronization, then Local security policy (or, Domain security policy) can be a very probable reason. Please follow the following articles religiously.
Default permissions and user rights for IIS 6.0 (IIS 6.0)
How to set required NTFS permissions and user rights for an IIS 5.0 Web server (IIS 5.x)
Check this too.
Typical reasons being:
- Anonymous username being a part of Guests group (During IIS installation, IUSR_<machinename> is added to the Guests group by default), and Guests group being denied access to some web folders and/or denied access because of local/domain policy).
Suggestion: Make sure that either you remove the anonymous username from the Guests group and/or remove the Anonymous username from any of the Deny policy settings (You can do this by going to the Local Security policy->Local Policies-> User rights assignment).
- The account is corrupted because of some reason like corrupted SID, moving the server from one domain to another etc.
Suggestion: First try adding the Anonymous username to the Administrators group to check whether you can access the web page or not. If it works it means it's an issue most likely with the permission for that account. If it still does not work, then there is some thing wrong..may be Policy settings or a corrupted account. Change the Anonymous user account to a different account and see if it works (be sure to make that account part of IIS_WPG group). If it works then it's a corrupted account. Recreate the IUSR and IWAM accounts (you can recreate by deleting existing IUSR_machine and IWAM _machine and then doing an IISRESET. IISRESET will recreate the IUSR and IWAM accounts for you) or manually creating a new user.
- Check this The account that is used for anonymous access may be unexpectedly locked out in IIS 6.0 or in IIS 5.0
At times you may see that HTML pages are running fine but not ASP pages. They might throw error like 401.3 etc. Check whether Users group has permission on ASP.dll at the <systemdrive>\wind*\system32\inetsrv folder.
Account Lockout:
Now something that creates confusion among a lot of people. At times people see their anonymous account getting locked intermittently and there seems to be no valid explanations for it.
Scenario: You have set anonymous username at multiple levels in IIS.
Let's say you have different usernames at the following level:
Global Web Sites level {IUSR_m1}
Website 1 {IUSR_m2}
VD1 {IUSR_m3}
VD2 {IUSR_m2}
VD3 {IUSR_m2}
Website 2 {IUSR_m2}
Now, let's assume you have different passwords at different levels. Now in the SAM database you can have only one instance of an account and hence only one password for it. Let's say you accidentally change the password for IUSR_m2 in the metabase at Website1 ->VD2 level and forget to change the password at the Website1, Website1->VD3 and/or Website2 level. Now since the password has to match in the SAM metabase too, only one of these will work. Also by mistake a wrong password can be set at a given level.
1) If you changed IUSR_m2's password in the SAM database to reflect Website1->VD2, then Anonymous authentication works fine when you access a resource from Website1->VD2. Although now, anonymous authentication will fail when you access a resource from any of Website1, Website1->VD3 or Website2 levels.
2) If you have the IUSR_m2's password in the SAM metabase reflecting the password set at any of Website1, Website1->VD3 and Website2 (assuming all of them have same password for simplicity sake), then anonymous authentication will succeed when you access a resource from any of the above levels, but will fail when you access a resource from Website1->VD2 level.
Now most servers have an Account lockout policy after certain invalid logon attempts. So if users try to access the Web resources from different levels, at one point of time because of multiple attempts Anonymous user account will get locked out and this will block access from all the levels irrespective of the matching passwords in Metabase and SAM database.
So IUSR_m2 might get locked intermittently because of the above scenario and will give unpredictable results. That's why I recommend to use a single Anonymous username at the global level only and let all the websites inherit from there,or else use completely distinct accounts at various levels (it again finally depends upon your requirement specific to the system).
IIS and Domain Controller (DC) on the same server:
Also, if your IIS server is a DC then you need to check:
<Anonymous useraccount>-->Properties-->Account-->Logon Hours..., [Ensure we have Logon Hours permitted for the account]
and <Anonymous useraccount>-->Properties-->Account-->Log On To..., [Ensure we have Logon to the machine enabled]
Please keep this handy when you are troubleshooting issues on a DC for IIS authentication.
Generally, DCs are very restricted when it comes to Permissions and access policies. Hence we have seen a lot of issues related to anonymous authentication failures on DCs. Microsoft recommends not to use a machine both as a DC and an IIS server from Security and Performance perspective.
Comments
Anonymous
August 30, 2007
I have encountered a more frustrating problem. The anonymous authentication is OK, when the IIS is just restarted. I can see the web page, and the "Authenticaion and access control diagnostic" tool also shows that the IUSR_myMachineName account is fine. However, after running a few minutes, troubles start to show up in the "Authenticaion and access control diagnostic". The IUSR_myMachineName is found without the privilege for "access this computer from the network". Depending on my luck, I could still access the webpage while this diagnostic error is shown. But eventually, the web page becomes unaccessible, with an HTTP error 401.1, as described in this article. What could have messed up the IUSR_myMachineName account after IIS has been in operation for a while?Anonymous
August 31, 2007
Hi David, Is the IIS server also a Domain controller by any chance. If yes, then we have seen such issues because of restrictive policies. One of the most probable reason why you are seeing such a behavior is because of domain group policy being applied to the server. Please check whether domain policies are causing IUSR account to be removed from "access this computer from the network". -SaurabhAnonymous
November 26, 2007
Hi Saurabh, This post was of a great help to us .Thanks... We were really in a fix when weird things were happening at the production server where as in the testing environment everything seemed just perfect... Thanks a lot.Anonymous
November 27, 2007
Glad this post was of some help. Tnx, SaurabhAnonymous
November 28, 2007
Just want to say thanks. I scoured all ends of the Internet trying to fix my 401.1 errors. You explained all the potential pitfalls and covered pretty much everything possible. The fix for me was a combination of syncing the pw, and also removing the guest group from the IUSR group. THANKS AGAIN!!!Anonymous
January 07, 2008
Thanks for the help. Removing IUSR from the Guests group was the trick for me.Anonymous
January 09, 2008
Thanks, this was a great help. Turned out to be the Guests group for us as well.Anonymous
March 06, 2008
The comment has been removedAnonymous
April 25, 2008
We often get support calls on issues related to Anonymous authentication failures and this is somethingAnonymous
June 13, 2008
Thanks a lot dude, this is really helpful.Anonymous
June 20, 2008
Terrific help - after 8 lost hours, you gave me back the will to live. A big THANK YOU.Anonymous
July 06, 2008
The comment has been removedAnonymous
July 07, 2008
Just to answer the previous comment, adding here for everyone. In case for some reason you see that IUSR and IWAM account are not present on the computer (or got deleted for some reason), you can recreate this automatically by doing an IISRESET (start->run->iisreset). If that dones't work for you form some reason you can manually recreate them as normal user accounts.Anonymous
July 24, 2008
The comment has been removedAnonymous
July 24, 2008
401.3 is an ACL issue and not authentication. I would suggest you to run Procmon from www.sysinternals.com while you are trying to reprodice the issue. Search in the Procmon log whether there is an "ACCESS DENIED". It most probably could be a permission issue for Network Service or some other account under which your exe is trying to run. Also if this is IIS 6.0 running under worker process isolation mode, you may want to test it by running your app pool under LOCAL SYSTEM account and see if the issue still appears. Let me know if that helps. ~SaurabhAnonymous
August 03, 2008
The comment has been removedAnonymous
May 22, 2009
I need to create anonomus user of the machine or update with current machine name. How can i do it?Anonymous
May 22, 2009
there are two ways: a. Ensure there is no IUSR/IWAM_Machienname as of now on the server. go to cmd prompt and type in IISRESET. It will restart IIS services and also recreate IUSR/IWAM accounts. b. If the above does not result in the account creation go ahead and manually create a local IUSR_machinename account. You should be good.Anonymous
August 25, 2009
I was able to get the password following your advice. Thank you! But what happens if the anonymous password is corrupt and needs to be wiped out and recreated? Any ideas? Then I can get it and put it back in there. Thanks!Anonymous
August 29, 2009
David, sorry was away on a long vacation (was having a ride in Ladakh :-)). Regarding your question yes you can modify the password for anonymous user account. >cscript.exe adsutil.vbs set w3svc/anonymoususerpass <your desired password> *Ensure that when you change the password through the above command the same password is modified in the Local Computer Users mmc console for the account, or domain acct based on the situation. The above cmd modifies the password in the IIS metabase. We need to ensure the password is same in both the IIS metabase as well as SAM database (Local Users and Computers console). Hope this helps!Anonymous
January 04, 2010
Excellent post! I've got a question in regards to authentication. Some users in my domains get locked out of their "home" domain account once they visit an internal website hosted on another domain (seperate forest, but a Trust is set up bewtween domains). Any change this problem is IIS related?Anonymous
January 04, 2010
Dean, based on what you said it may or may not be an IIS issue. It could be some domain policies. We need to know more about what this website does..Anonymous
January 19, 2010
I think you might be the expert who can help me. Today I just found I lost my old IUSR_Machinename, instead I have an odd IUSR and IWAM account. My machine name is atllwe, but the IUSR account is something like IUSR_YOUR-92791234. I did an IIS reset, and it's still like that. I just realized that I couldn't write to an XML file that was working before. When checking the IUSR account, I realized such a change. Have you seen something like that before? Thanks!Anonymous
January 19, 2010
Frances, Yes I have seen similar issues in the past, although i cannot pinpoint to a specific issue being the problem. You may see multiple IUSR_<diff_names> if the machine was upgraded or renamed etc etc. You need not worry about other accounts though. If IISRESET is not working you can manually create the account with whatever name you like and give it the necessary permissions as per KB 812614. Regarding the question around why your cannot write to XML it could be permission issue for the account, may be write permission etc. You can use tools like Process Monitor to check what identity your app is using to write to the XML file etc. You may see Access Denied entry in the process monitor log. Let me know if this helps.Anonymous
March 09, 2010
Is there a similar process for the IWAM_machine_name account? The password for this account expired on the server, and now we're getting DCOM errors referencing this account and W3SVC warnings. Thanks so much for this article, by the way. What a great help it has been to me already, dealing with some internal website issues we were having after running the MBSA on some internal web servers.Anonymous
March 09, 2010
Thanks Christine for your kind words :). For IWAM account, you can use synciwam.vbs script to sync the password in the SAM database, IIS metabase and the DCOMconfig. Also I would suggest to disable Password expiration in the properties of this account for future purposes. Check this article for more details: http://support.microsoft.com/kb/297989Anonymous
November 04, 2010
The comment has been removedAnonymous
November 04, 2010
Hello William, I am assuming you are running the following command: Cscript adsutil.vbs get w3svc/1234/anonymoususername and then getting the message: "is not set at this node" This is normal. what it means is that your website (corresponding to site id 1234) is inheriting this setting from the global level for the websites. If you really want to check the value that is being inherited at this site level you can run cscript adsutil.vbs get w3svc/anonymoususername. Rearding your original problem you can just enable anonymous access in the IIS mmc and it will automatically take the setting that this site is inheriting from the root. Hope this helps!Anonymous
November 04, 2010
The comment has been removedAnonymous
November 04, 2010
The comment has been removedAnonymous
November 04, 2010
Many thanks for this article and the help you have given me - Been absolutely brilliant and has helped a lot. Even years after it was written, it is still very helpful!Anonymous
December 03, 2010
Thank you for a awesome knowledgeable article and excellent to the point answers. Much appreciated :))Anonymous
February 07, 2013
Helped me out :) Password synchronisation issue! Thank u!