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.