HOWTO: Diagnose 401.x HTTP errors on IIS

One of the most common questions asked about IIS on the newsgroups as well as Microsoft Product Support is "why am I getting 401 Access Denied"?

There are many, many possible causes and variations, but from the IIS perspective, the top-level, logical categories are fixed. This information can help dramatically narrow down the scope of any investigation, but unfortunately, few people know to take advantage of this information. This is what I am going to address with this entry - how to use and diagnose the 401.x error codes on IIS.

Step 1: Determine the SubStatus Code

When you get a 401 response in the browser from IIS and you want to troubleshoot it, the first thing you should do is determine what "type" (i.e. HTTP substatus) of 401 it is.

Starting with IIS 6.0, the IIS web log files located at:

%SYSTEMROOT%\System32\LogFiles\W3SVC###\*.log

record both the HTTP status and substatus code, which when combined with the Win32 error code can aid to troubleshoot many 401 errors. The W3C log entries look like the following, with the HTTP status, substatus, and Win32 error codes highlighted.

You can also get the substatus code from the HTML response itself, but web browsers like Internet Explorer have options like "Show Friendly HTTP Errors" which obscure the detailed error response by making them "simple" and "user friendly", so if you want the real error response, you need to turn off that option.

Unfortunately, prior to IIS 6.0, the IIS web log files are useless in distinguishing 401 substatus because it does not even record it. Your only option is to figure this out from the HTML response itself, assuming the 401.x Custom Error pages for that URL's scope are configured to send different HTML pages for each type of error.

Step 2: Determine Course of Action

Once you have determined the HTTP substatus code, you can start narrowing down the types of failures and causes. The following are the fixed categories that IIS reports. I will give detailed explanation of what each means as well as some common causes/solutions (obviously not exhaustive).

401.1 Denied by Invalid User Credentials

This error indicates that IIS failed to obtain an NT user token with which to execute the request.

In a nutshell, IIS expects to have a NT user token at the end of Authentication (even anonymous authentication - see this URL for details), and if this does not happen, you get 401.1.

Some common causes include:

The client gave the wrong username/password (including none at all). This could be from incorrect cached auto-login attempt by the browser, or from a user login dialog from the browser.

You enabled Anonymous authentication, yet you still get 401.1 for all requests. One common cause is if the configured anonymous user credentials stored in the IIS metabase configuration file is DIFFERENT than the user principle's credentials in reality (i.e. mismatched password). In all cases, the preferred solution is to manually synchronize the username/password of the anonymous user principle in IIS with that of the real user principle. I have seen many amazing variations of this cause, including:

For testing purposes, the user types in his/her OWN username/password as anonymous user credentials at some point in the past and forgets about it. Later, when password policy forces them to change their password, the anonymous user credentials stored in IIS configuration is now mismatched with reality. On subsequent anonymous requests, IIS fails to login and obtain a NT user token for anonymous authentication and fails with 401.1, and it looks like IIS is just plain buggy and could not even support anonymous authentication.

I have also seen the reverse happen - user configures IIS to use their username/password as anonymous user, and when they changed their password, web server traffic quickly causes IIS to incorrectly login with wrong user credentials too many times, causing their user account to be locked out. These users now complain that their user account is mysteriously getting locked out as soon as it is unlocked, even before they log in anywhere.

On upgrading from IIS 5 to IIS 6, IIS Sub Authentication (i.e. the "allow IIS to control anonymous user's password" feature) is enabled by default for compatibility. This allows IIS to log in the anonymous user principle without actually keeping the user credentials in sync, and anonymous authentication looks good while in IIS 5 Compatibility Mode. However, as soon as you switch into IIS 6 Worker Process Isolation Mode, Sub Authentication is disabled because it requires a privileged process identity like Local System (which is a known and quite unnecessary security risk for the lowly purpose of password sync). This means that IIS 6 now tries to log in the anonymous user credentials stored in the metabase, which has probably NEVER been kept in sync with reality through the upgrade... and you now get 401.1 for every single anonymous request. To a casual user, it looks like switching into IIS 6's native mode simply breaks anonymous authentication and the rest of the website.

The server has been reconfigured to deny necessary login privileges for the authenticating user or its containing group (either anonymous or through some authentication protocol). This can be done through automated re-application of Group Policy for domain members, DCPROMO to/from Domain Controller, or static application of security templates. What ends up happening is that the server-side reconfiguration may remove Local/Remote Login rights for that user, impose new restrictions (like Login hours, Logon type), etc... preventing IIS from successfully logging in the user to execute requests and resulting in 401.1.

401.2 Denied by Server Configuration

This error indicates that the web server is configured to require certain authentication protocols for communication, but the browser failed to use any of those authentication protocols. The corrective action should be to either configure to require an authentication protocol acceptable to the client, or use a client that satisfies the server authentication protocol requirements.

A common cause of this issue happens with the older Netscape/Mozilla browser clients and an IIS web server configured to require Integrated Authentication. These browser clients did not understand Integrated Authentication, so when IIS required Integrated Authentication and the browsers repeatedly ignored those responses, IIS will return 401.2 indicating that the browser failed to use an authentication protocol required by the server. Newer Mozilla browsers like FireFox do not have this deficiency.

Another possible cause is when using Integrated Authentication over the Internet. Integrated Authentication (NTLM) is a connection-based authentication protocol, meaning that an authenticated connection between a client and server is the only proof of authenticity. This works fine in Intranet scenarios, but for Internet scenarios a lot of network devices in between the client and server can either not support or mishandle NTLM (such as Proxy Server connection pooling/multiplexing), causing unexpected 401.2.

Here is how it happens: since NTLM is connection-based authentication, once a client successfully authenticates using NTLM, it often re-uses its end of the connection and simply sends anonymous requests over it. Now, assume an intervening proxy server pools connections between client and server, is unaware of NTLM, and independently decides to send the client's request over *another* connection in its pool (instead of the already authenticated one) to the server. This causes the client's anonymous request to be sent to the server over a new, unauthenticated connection, and the server dutifully rejects it with a 401.2 since the server requires Integrated authentication. The 401.2 rejection is totally unexpected by the client since it thought it was re-using an authenticated connection and did not initiate any re-authentication. Yup, fun... 😉

Common variations of an "intervening proxy server" include:

"Web Accelerators", such as the Google Web Accelerator. These programs basically act like a local "caching proxy" such that requests for content has a higher chance of coming from your local hard drive than over the network, thus "speeding up" apparent web access.

Web Anonymizers - these programs basically disguise your own IP and other request characteristics with their proxy's IP and characteristics, and this is shared amongst all their users, thus providing anonymity through numbers.

Sniffer tools like Fiddler for IE - these programs act like "Web Accelerators" except instead of caching request/responses, it chooses to selectively capture and display those request/responses for user analysis.

Web Access Proxies for some broadband providers or preset Company proxies - these are the traditional obvious proxies.

401.3 Denied by Resource ACL

This error indicates that the web server was able to authentication and obtain SOME NT user token to process the HTTP request (you still have to determine WHICH user's token...), but that NT user token lacks the FileSystem ACLs to access the requested resource. This is the typical "access denied" due to missing file ACLs that people assume, and yes, you will likely need to adjust ACLs to resolve this issue.

However, realize that all of the OTHER 401.x errors have nothing to do with ACLs, so I recommend AGAINST tweaking resource ACLs to "Everyone: Full Control" to remove ACL issues from the picture. You should be able to determine the exact user that fails to have ACLs to the resource, and just adjust ACLs for that user on the necessary resources and resolve the issue

Common causes include:

Wrong/Missing ACLs on the file for the authenticated user. You need to change the ACLs or change the user to an identity that has correct ACLs on the file.

You are not authenticating with the authentication protocol you think, and thus the user principle may be unexpected. Reconfigure the authentication protocols as-appropriate so that you end up running as user identity you expect on the server.

If your content is on a UNC share, you may have mismatched NTFS ACLs vs. UNC Share ACLs.

A useful tool to pragmatically determine access-denied to file resources is File Monitor.

401.4 Denied by Custom ISAPI Filter

This error indicates that some ISAPI Filter running on that request sent back a structured 401 response of some sort.

The reasons why the ISAPI Filter is returning such 401 responses are completely arbitrary and uncontrollable by IIS. You will need to determine WHICH ISAPI Filter is returning this response and obtain support for this ISAPI Filter to resolve the issue.

401.5 Denied by Custom ISAPI/CGI Web Application

This error indicates that some ISAPI Extension or CGI Web Application sent back a structured 401 response of some sort.

The reasons why the CGI/ISAPI are returning such 401 responses are completely arbitrary and uncontrollable by IIS. You will need to determine WHICH CGI/ISAPI is returning the response and obtain support for it.

In the case of requests that execute .DLL or .EXE requests, the CGI/ISAPI binary is clear. In the case of requests with Extensions that have Application Mapping (i.e. the .asp extension is mapped to the ASP ISAPI DLL Script Engine), you need to look up the extension and its associated Application Mapping in the URL's scope to determine the Script Engine to obtain support.

Starting with IIS6, it is also possible for Wildcard Application Mappings to execute on any request within its configured scope prior to executing the actual handler for the request. It is conceptually like how an ISAPI Filter can act on a .asp request before the ASP ISAPI handler processes the request.

A popular scenario for Wildcard Application Mapping is to implement custom authentication, so a 401.5 on a .html file may indicate presence of a Wildcard Application Mapping-based custom authentication. To the astute reader - .html is handled by the Static File Handler by default, which will only return 401.3 for access denied... so if you see a 401.5 involved with a resource like .html that is usually NOT associated with an Application Mapping which can only return 401.5 for access denied... you know either a Wildcard Application Mapping, or non-standard Application Mapping for .html is involved.

To determine which Wildcard Application Mapping is involved on a request, you have to use the IIS Manager to look up the EFFECTIVE Wildcard Application Mapping for that request, starting from the web page of the URL itself and working up the directory tree until you find the nearest Mapping definition. Yes, it is a major hassle prior to IIS7 to determine the effective Application Mapping of a request for support purposes.

Starting with IIS7, you can use Failed Request Tracing to determine all handlers that executed in sequence on a given request, which will show exactly what module / application mapping caused the 401.5. This makes it extremely easy to identify the faulty DLL without trying to calculate effective Wildcard Application Mapping configuration.

Conclusion

401.1 through 401.3 errors are associated with IIS request processing and allow the logical interpretations and assumptions that I listed above.

Meanwhile, the 401.4 and 401.5 errors are the most arbitrary to diagnose since custom ISAPI DLLs and CGI EXE can cause IIS to behave in non-obvious manners. Thus, much of the logical assumptions about 401.x do not apply.

I hope that this information has been useful in deciphering the 401.x errors from IIS. If you have additional questions, feel free to post a comment or post a private question via the "contact" link.

Recently, we have also released a tool, AuthDiag, to help troubleshoot IIS access denied issues. You can download it from this location. In particular, it has a feature to hook in to various failure points in IIS and directly troubleshoot what is failing on a given request - you need to see and try it out!

Superb explanation. It didn’t give me the answer exactly, but it sure lead me in the right direction. In my case, I had user ‘XYZ’ being the anon. user for the root of the website. Then, I had user ‘ABC’ as the anon. user for one of the virtual directories. It was in the VD that I was having the issues with 401.1 errors.

Your pointing out of the anonymous user issue made me think that it might be the mismatch between root web and virtual directory.

Thanks once again.

PS: The interesting thing was that I did not get the 401 errors when accessing the site using ‘localhost’, but I did when I accessed the site with 127.0.0.1, even with 127.0.0.1 added as a trusted site of I.E.

Is anonymous authentication the ONLY thing that is enabled/running on your website, or is another authentication, like Integrated authentication, also enabled?

Because if so, then you may be observing IE’s different "auto-login" behavior regarding "127.0.0.1" and "localhost".

In all cases, IE tries anonymous authentication and got the 401.1 because your anonymous username/password was mismatched. However, since you have other authentication protocols enabled, in one case IE chose to auto-login with your user credentials using Integrated authentication and succeeded, while in the other IE chose to NOT auto-login and thus you saw the 401.1.

The key thing to realize is that there is NOTHING special about the "Trusted site" when it comes to authentication/access other than the fact that different IE Zones can have different auto-login behavior, and some URLs automatically trigger certain login behavior regardless of the zone.

If I add windows authentication to the virtual directory configuration the site works fine but the authoring tool appears.

Both CMS sites point to the same database and I have checked all of the IIS and other system settings and they seem to be identical.

Can you give me some idea how to troubleshoot this problem? Are there any logs that I should be looking at. I created another ASP.NET project(non-CMS) in the same web server and that works fine with anonymous authentication.

I first noticed this problem when I got 401.2 errors accessing an Images directory in the CMS project but now I can not even access the aspx pages in the project.

I’m getting a 401.2 error on a virtual directory and I can’t for the life of me figure out why.

I have one site on IIS6 (running in IIS5 isolation mode). The site has a CGI directory and a VD for isapi redirection that are both configured for Basic Authentication only. The CGI directory works just fine, the VD does not. It all works fine with anonymous access selected but basic auth just fails.

401.1 means that IIS does not have a valid user token to use for request processing, so Server-side redirection/forwarding cannot reasonably expect to work. Client side redirection, however, should work just fine since you can customize the HTML page of 401.1 to cause client-side redirect.

Thanks for this article. We had a system that was recently upgraded from IIS5 to II6, and after working through a number of problems, we’re at the point that when we access a test page from a different machine, we are getting a "You are not authorized" error. I have to get someone at the site to confirm, but it sounds like it would be a 401.1 error.

The website is configured for "anonymous" only, and with "IUSR_machinename".

In your blog, you said "In all cases, the preferred solution is to manually synchronize the username/password of the anonymous user principle in IIS with that of the real user principle.".

Can you tell me the specific steps "to manually sychronize the password of the anonymous user principle in IIS with that of the real principle", or point me to a reference on this procedure?

Jim – the text "You are not authorized" shows up for a variety of errors, not just 401.1, so I would suggest that you obtain the actual HTTP status/substatus and Win32 error codes from the IIS6 website log file before making your next move.

Getting an interesting situation. A site is setup with only Integrated Authentication. If I access the site using http://some.domain.com/”>http://some.domain.com/ I immediately get the 401.2 error message with no chance to enter my username and password. If I access the site using http://192.168.1.7 I *am* prompted for my credentials and I’m able to login successfully with everything working as expected.

[ethereal trace comparison removed due to length]

I can hit refresh, reload, etc. and it’s the same thing. Yes, I’ve cleared the cache and cookies. Comparing requests in Ethereal, the difference in the initial client request is that when Connection: Keep-Alive isn’t specified, it doesn’t work. I assume the "Accept: */*" vs an explicit list doesn’t matter. The initial server response appears to be identical in each case. However, in the some.domain.com instance, the browser just gives up and doesn’t even try to respond with "Authentication: Negotiate …".

I’ve tried adding the site to trusted sites, to no effect.

Well, as usual in researching this more to post sufficient details on what is happening I managed to solve it myself. The use of the Google Web Accelerator in IE was intercepting the request for the http://some.domain.com so this falls under the "intervening proxy server" case mentioned in your article. Stopping Google Web Accelerator made authentication work as expected. Just to confirm it wasn’t a coincidence, re-enabling it made authentication break again.

I will edit the article advice to bring up other non-obvious "proxies" like Web Accelerators, Web Anonymizers, sniffer tools like Fiddler, Web Access Proxies for some broadband providers, preset Company proxies, etc.

Dave – this article is great, but i am still having trouble with my IIS 6 server.

I can’t browse to the default website without getting 401.1 errors and the IIS logs show 401 1 0.

This is a fresh install of IIS 6 and initially both Integrated and anonymous authentication were enabled. I disabled Integrated so that only anonymous was checked and am still getting the error message. I have not modified the anonymous user credentials so I am at a loss now.

Dave – This server is not joined to a domain at this time, however I had the same behavior with a server that was joined to a domain. What exactly occurs when an IIS server is joined to a domain that changes the anonymous user account if it’s set to use a local account?

There is definitely an issue with the IUSER account that was created by IIS because when I create another local user and set the website to use that user I can access the site without any issues. I modified the IUSER account properties removing it from Guests group and adding it to Users and now I am able to use the account for anonymous access to any website on this server. Can you help explain?

Dave – sorry for the multiple posts, but I am now suspecting that there is a problem with the security template applied to the server causing the issue with the IUSER account and it being a member of the GUESTS group.

Yes that’s exactly what happened, the security template had deny network access to server for the Guests group of which the original IUSER account was a member. I removed this setting and that corrected the issue. Now I just need to decide what is the most secure way to setup the IUSER account. Should I make it a user and leave the security setting to deny Guests network access or leave it as a guest and remove the security template setting. Any suggestions?

Went through all of the steps to determine the reason for our 401.1 errors when accessing any page in IIS wiht no luck. The application had previously been working for months. Turned out that the security log on the server was full which was preventing any non-admin account from logging on, this included the IUSER_machine name account. Here is a link to the msft article explaining the solution and problem:

Ben – thanks for the feedback. I’ve added this as a possible cause into the blog entry. I’ve seen it happen to different users a couple of times, and each time it was quite non-obvious what was failing

Just wanted to say that you guys got me thinking in the right direction. I’m no server admin by any means, and I’m really figuring this out as I go. In my case, I had the IUSR_* account set to log on and it worked great. I think AFTER I set it up, the account was changed to NS1IUSR_* When I changed the user again for both directories I was having trouble with to the NS1 version, it worked like a champ.

To be honest, I don’t know why or how any of this happened since once it was set up, I didn’t change anything – I was happy I just got it working in the first place. 🙂

Actually, I -did- install FTP since it was all set up, so maybe the installation did that? I don’t know, but thanks for the ideas.

i am have strange problem ..i have configured the IIS for anonymous user and it is working ..but after a day or sometimes after 5/6 hours it need IISreset if thats not done..site explodes out and show unauthorized access error 401

-i have also manually configured it aswell …system is on domain

-IUSR_machinenamecan log in to system

-Folder security settings for that website is also carefully done

-i have checked event log and there is nothing in it except this..

IISADMIN service recreated an account IUSR_machinename

please please reply me on this as soon as possible it is killing me 🙁 coz client is on hold only for this

Usman – strange behavior like this usually indicate the issue is not in IIS. After all, IIS just asks Windows for a user token and gets one that is valid, so it uses it — no reason for IIS to somehow make the user token invalid after 5/6 hours. The system must be doing it somehow.

I would start by examining the Group Policy’s security settings. In particular, maybe it is intentionally restricting the IIS anonymous user or otherwise restricting logon hours/period for users, especially Anonymous users.

if there have been restriction over logon hours…i guess it would not have been working when IISreset is done …coz IIS i guess does not play with options of Users….need some detail information or anyother idea please..and thank u very much david .

Usman – make sure that there are no restrictions against the anonymous user, against any of the groups it is contained in, as well as login type. Also check the same against the group the server machine is in – maybe the server prevents users from being logged in for some amount of time.

Effective Domain Group Policy is not easy to check; I never eliminate it as a cause because strange IIS login behavior almost *always* result from some non-obvious security/permissions change of user rights by Group Policy. You just have to figure out what it is.

In other words, I only hear people reporting these bizarre behavior when their server is in a domain or was created from some sysprepped/standard "image". I have never heard of these problems on clean-installed stand-alone machines.

Very interesting article and I wish there were more on this subject. We have had such a frustrating day and still no solution. Scenario: Standalone Win2003 Server. If we use Integrated Auth, the user/pass we created works fine, but the client wants this to be Basic Auth and as soon as we switch Integrated off and Basic on, the Auth fails with a "HTTP Error 401.2 – Unauthorized: Access is denied due to server configuration". We are stumped at the moment. We have no entries in the Default Domain & Realm fields but my understanding is that they aren’t necessary? Any help would be soooo much appreciated!

JammyD – 401.2 happens when the browser does not use the authentication protocols that the server requires.

Now, it may be that the browser uses Basic auth but the intervening proxy strips it off for whatever reason. Default realm, user identity, etc are not relevant.

Basically, it all comes down to IIS being configured to expect all requests to to contain "Authorization: Basic <base-64-encoded-blobrn", and the requests received by the server from the browser (and optionally modified by any intervening network appliances, proxies, etc) does NOT contain that request header. Hence 401.2.

Anyways, the 401.2 means there is a mismatch somewhere between the browser, network, and server, and you have to figure out where. A network sniff is the easiest way to see what is going on.

FYI: using Basic Auth, no matter if encrypted over SSL, is inherently insecure because the username/password still exists unencrypted on the server after being transported over SSL and can be otherwise stolen or mis-delegated. Integrated authentication is the secure way to go.

David, many thanks for your reply. The plot thickens though. We have just found that even if we browse to the local machine using IE on that same machine, the same problem exists. It still fails Basic Auth with the same error. The server is hosted with Fasthosts and I wonder if their Matrix Control Panel, (a kind of overlay to the machine that can be used to control domains/websites/users etc), is in some way screwing with IIS6 security? Also found this guy with the same problem, also at Fasthosts: http://www.iis-resources.com/modules/newbb/viewtopic.php?topic_id=3980

David, (and anyone else interested in Fasthosts whiley ways)… we solved it… I don’t think you’d have ever guessed the problem as it did indeed turn out to be related to the setup of dedicated servers at Fasthosts. They have a system called Matrix Control Panel which among other things has a security option on it. You can enable secure folders through their web-based gui, and it gives you a dialog very similar to the standard challenge/response. However, it uses it’s own ISAPI Filter which is applied at the top level ‘Web Sites’ properties level. So even if you haven’t got this bespoke security enabled on the domain in question, it is still intercepting any Login attempts. As soon as we removed the Filter and restarted IIS, the Basic Authentication started working properly. Many thanks for your reply and keep up the good work with the articles etc. I just wanted to share this solution for any other unsuspecting Fasthosts customers.

I have a Windows Server 2003 with SP1 and was having problems with configuring frontpage server extensions. Even though I was using the correct user (local administrator account) I could not get past the server extension administration webs authentication. All I got was 401.2 and 401.1. Very annoying. After surfing around in circles for quite some time I came across this knowledge base article at microsoft, http://support.microsoft.com/kb/896861. Indeed I had host headers defined for my site and that was what was causing my problems. I added the BackConnectionHostNames registry entry and rebooted. Restarting IIS Admin as the article suggests was not enough.

The problem is not with host header based IIS websites. It is a security change which affects localhost network connection over Integrated Authentication where the computer name and host name does not match.

I have an ASP.Net 2.0 web app installed on IIS 6 on server2003 SP1. The app is setup up as a web site (port 83), as opposed to a virtual directory. The web site is configured to use integrated securty and anonymous access is turned off. The web site is running under an application pool. When the application pool is set to run under the default Network Service identity the app works fine. But when I change the app pool identity to use a domain account, which also happens to be a domain administrator and is also an administrator on the local machine, the web site does not work and writes 401.2 status codes to the logs.

I really want to run under the app pool under the alaternative account as I want to use integrated security on the database connection. The database is running on an different server in the same domain and my domain user has access to the database.

As I understand, this should just work. I have read many articles on the web and have run the setspn tool to register the service princle name in the AD. All to no avail. I have spent several hours on this now and would greatly appreciate any help. Is there anything I have overlooked?

We run an IIS6 server hosting 3 virtual hosts, each running their own ISAPI applications, running in IIS5 mode as one of the ISAPI applications doesn’t like application pooling according to the system vendor. 2 sites are anonymous access via IUSR_, 3rd is integrated authentication via AD. The two anonymous access sites appear to loose their token to use the IUSR_ account overnight sometime and come back with authentication failed every morning. Restarting IIS resolves this issue and its fine until next morning.

We’ve been through local and domain security policy and can’t see anything glaringly obvious, no time restrictions. AuthTool suggests that BuiltIn/Users and ASPNET need “Access this computer from the network” although this is granted to the anonymous users directly, we’re not using any .net applications on the machine so haven’t made any changes to that user from the factory default.

We are using sharepoint 2.0. When a user has insufficient privilages to navigate to a particular area/page or perform an action that that user does not have access to, a series of three dialogs allows the user to log in as a different user in order to gain permission to the requested resource. This happens by sharepoint design. I have written a filter to bypass these dialogs and go straight to the access request page. In predictable cases, the filter hangs – particularly when the attempted action is to simply view a page with insufficient rights. The filter works great in cases where the attempted action is to delete or create an item (i.e. a document, bullitin, announcement, etc..) where the user does not have permission.

More Info: When my code detects a certain pattern of filter behavior just before the OnAccessDenied function is triggered, I clear the response buffer and use WriteClient to send an "Access Denied" message to the client (which gets immediately redirected to an access request page). I make this WriteClient call inside the onAccessDenied handler.

to be honest not everything there works as expected. Like with integrated auth. Simple scenario.

Web server: websrv02.domain.com

1st web site: site1.domain.com

2nd web site: site2.domain.com

1st App Pool for site1 with ID DOMAINuser1

2st App Pool for site2 with ID DOMAINuser2

Theoretically you only need to add SPN http/site1.domain.com to DOMAINuser1 and similar for second site/user, allow delegation for user1, user2 and webserv02. But in practice this doesn’t work at all. In best case you get access from local console of web server only, in worst – everywhere you’re asked for credentials and nevertheless authentication fails.

When I try to connect to Reporting Services via SSMS using Windows Authentication (signed on as Administrator) I get "Cannot connect to MYMACHINESQL2005. The request failed with HTTP status 401: Unauthorized.(Microsoft.SqlServer.Management.UI.RSClient)"

Hello — I get 401.2 errors accessing anything.asp from a brand new, fresh install of WinXP Pro with SP2. Seemed strange because iisstart.asp has always loaded in the past on new Windows installs, with no particular configuration. Yes, anonymous authentication is the only one enabled, and the IUSR_machinename is the default installed automatically. "Allow IIS to control" is checked. The machine serves ordinary html just fine.

For kicks I checked my home machine, also WinXPProSP2 — where I do a lot of testing of non-ASP web sites I build — same errors. Seems like some Windows upgrade broke default ASP application functionality. What am I missing?

One clue for me is that pages with .asp extensions don’t have icons — so they are not associated with any application. That seems odd. I stress again, this is a fresh install with SP2 install following it.

Karl – I believe your problem is specific to your computers and network.

If there was something wrong with Windows upgrade or IIS itself, then my freshly installed XP SP2 machines would also have non-functional ASP, but that is not the case. ASP works perfectly as expected for me.

Now, I do not expect iisstart.asp to function on XPSP2 because it was intentionally broken for security reasons and we chose not to fix non-essential ASP samples..

401.2 response that is specific to ASP seems suspicious because IIS authentication happens *before* handlers for ASP or HTML are determined.

It sounds like some network access device or personal security software common to your computers are causing this issue with ASP. Assuming no ISAPI Filter modifications on your computers (you say it is a clean install), if anonymous authentication is enabled and you get 401.2, then it means your requests are NOT anonymous. Now, assuming that the client sends anonymous requests by default( since that’s how HTTP works) it means that something in between the client and server is altering authentication only for .ASP requests.

At this point, it sounds like your problem is specific to your computers/networking. I am not aware of any part of IIS, Windows, or any other Microsoft software that does this.

Finally, .asp pages are not supposed to have icons in Windows Explorer because they are not associated with any application. IIS uses its own "Application Mappings" to do this association, which are not represented within Windows. If you have application development environments like Visual Studio, they may register application handlers and icons in Windows for .asp.

I am running IIS6 on W2003 server and have two site which work perfectly well. I have added a new site and get 401.1

It only happens with one site out of the three so I am guessing it is not down to permissions for IUSR? I have tried multiple things such as checking that IUSR has access and checking the IUSR passowrd is correct but no joy 🙁

It is really winding me up now so any help you could offer would be greatly appreciated.

I’m having a 401.1 error with Anonymous authentication, but it goes away if I make the IUSR_* user a local Administrator on the server and then can access pages again (and returns if I make the IUSR_* user a Guest again). Why would I have to make the IUSR_* account an admin to run the website? By the way, this is on a new server/IIS installation with only one test "default.htm" file added to C:inetpubwwwroot and "default.htm" is the highest on the list in the "Documents" tab on the "Default Web Site" properties in IIS.

Even with adding IUSR_* to the ACL on C:inetpubwwwroot and giving it Full Control, until I gave the account admin rights, I couldn’t access the site. But since I could AFTER doing so (and still could even after changing the ACL back to Read, List Folder Contents, and Read & Execute for IUSR_*), how can this be a 401.1 AUTHENTICATION error, implying the passwords aren’t sync’d? It is possible there’s some local security policy involved that could have been set (I’m not the only admin involved here, unfortunately, and don’t want to point fingers til I know where to look and find what I need to find), but I don’t know what to look at for this, and seems like it should be something easy. Please let me know.

To follow up on my last post with the 401.1 error where I had to give IUSR_* Admin rights… What was going on is that Guest accounts were disabled by Group and Local Security Policy… so… To make it work, I created Domain Users IUSR_* and IWAM_*, told IIS to use the new DOMAINIUSR_* account instead of the now defunct (and therefore deleted) LOCALIUSR_* account, did an IIS reset, and badaboom-badabing, all is well in the Land of Nod. Hope that helps someone….

If you get a "You are not authorized to view this page php 401.3" erorr, make sure that execute or read permissions are assigned to the NETWORK SERVICE account for the php5isapi.dll. Doing this solved my problem.

DavidK – Thanks for the advice to others, but I have to disagree with your advice. Just because it works for you does not mean it makes sense for anyone else. For example, I could say that I assign read/execute permissions to arbitrary user and it works — does that help anyone if they do not have my arbitrary user?

The actual solution is to make sure an Application Mapping gives read/execute access to the Process Identity of the Application Pool servicing the URL. This is actually always required, so your problem was that you attempted to lock things down tighter than you should and figured out the mistake.

A simple way to catch the Process Identity of the Application Pool is to use the group IIS_WPG (unless you install IIS on a Domain Controller which does not allow such groups — in which case you must ACL to the specific Application Pool identity).

Since none of the identities must be Network Service, your suggestion is actually not correct.

We are currently recieving the 401.2 error and 401.5 errors while using our web application.

401.2 – The issue only happens when multiple users are on the site at the same time. We have confirmed with our net admin that we are not using a proxy server, sniffer, and i have tested the issue on a machine without an accelerator.

Would a firewall cause a similar problem?

401.5 – Again we have confirmed that we are not using any custom ISAP authentication, and only have asp 1.0 and 2.0 setup. Is there anything else to look for here?

It sounds like your network is using some sort of connection pooling, causing one user’s authentication state to be borrowed by another and in general confuse the real user authentication state. This sort of confusion can lead to 401.2 or 401.5 depending on the authentication protocol.

I am running a website on w2k3 and it uses ii6 and host headers. Whenever i try to run i am getting 401.1 401.2 errors. But if i set browsers cache to never check server for page modification it works fine. I am totally confused what is goin on..

Can you tell me what is the relation between caching and host headers + Ie 7 + and external resources (* like css and js ) , webresource.axd..

Chamy – Sounds like everything is fine. 401.1 and 401.2 can be normal for some authentication protocols.

When you tell the browser to cache and never check for page updates, the browser caches and stops requesting for that page that required authentication – thus never causing the 401.1 and 401.2 again for that page.

Host headers, IE7, External Resources, webresource.axd, etc have no relation to the issue nor each other.

That is a very nice article. We have a web application in ASP.NET 2.0 which gives 401.1 and 402.2 errors for some requests. After viewing the IIS log files its interesting thing to note that every time when a 401 error is received, it contains "-" in cs-username. And in very immediate request it logs same request but this time with a valid a user name and gets 200 code. So each 401 request is immediately followed by a valid 200 request for same resource/url but with a valid user name.

We have a separate Application Pool AND Integrated Authentication is used AND the web server is in a domain AND set Integrated Authentication to favor NTLM. But still we getting these misterious 401.1 and 402.2 errors.

Naveed – getting 401.1 and 401.2 errors are normal part of the NTLM authentication handshake.

There is no way that a server can "get rid of" 401 errors because a client can always choose to do the wrong thing and cause 401s. Thus, you should not be concerned about the 401s.

A client can optimize away the 401.2 through Pre-Authentication, and can optimize away the 401.1 by keeping its authenticated connection open. But, these are things that the client needs to be smart and perform; server cannot force it.

Your article is very informative. I hope you can help me out from a critical situation.

I am inside a compny intranet using LDAP. I configured a new IIS server in a virtual system for a webapplication giving anonymus acess to all. Also I enabled integrated windows authentication(becos otherwise I was getting a blank aspx page). The application is configured in server say X in port 8888 and has multiple identity say Y with port 80.

Now in the server itself when I access it through http://X:8888 it works fine. but when I try to access through http://Y it ask for nt id and it never accepts my id. I am admin in the system.

I also have 401.2 errors and looks like caused by NTLM on OWA IIS. I use monitor software that spits out alerts due to 401.2 error and do not want to ignore alerts as the 401.2 could be attacks to OWA. I cannot filter out which 401.2 errors to send alerts on nor figure out to avoid logging these erroneous errors.

So the Q is: Can I use URLScan 3.1 to filter out these events and log in URLScan log and not W3SVC log so I can actaully get valid alerts on 401.2 errors?

I have IIS 6.0 using Windows 2003. There is a default Web Site and virtual web sites. The default site works but the other 3 sites return a 401.1 Error. The sites are setup identical however the 3 virtual sites have there own Application Pool.

Anonomus User is selected and Integrated User is deselected.

There was a strange occurance in that I can use the IP address for the Default site and it asks me for a login and password (domain). However trying the same thing with the other 3 just pushes it directly to the 401.1 error.

We are seeing 401.5 errors while trying to access resource(the GIF file). WE have a web part running in SharePoint. The problem is that this is happening only for some laptops the client is using, but not other. All laptops are using the same domain user (for testing) right now to access the page.