Description: Description: http://www.monacaron.com/~mona/images/large/kerberos.jpg Κέρβερος, the three-headed guard dog

Troubleshooting the 401.1 - Unauthorized: Access is denied due to invalid credentials

Trouble-shooting the 401.1 when an IIS website is set to using Windows Integrated / Negotiate (Kerberos or NTLMv2) authentication

in single hop and double hop scenarios

by vIISual.net(at)hotmail(dot)com

updated May 2010. But this is unfinished. There is a lot left to do on this page.

Confirm the error message. There are several types of 401 errors. The 401.1 is very different than the 401.2 and 401.3. Here is the 401.1 as seen in the IE 7 browser:

You are not authorized to view this page

You do not have permission to view this directory or page using the credentials that you supplied.

Please try the following:

· Contact the Web site administrator if you believe you should be able to view this directory or page.

· Click the Refresh button to try again with different credentials.

HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.
Internet Information Services (IIS)

Technical Information (for support personnel)

· Go to Microsoft Product Support Services and perform a title search for the words HTTP and 401.

· Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled Authentication, Access Control, and About Custom Error Messages.

Here is an example of the 401.1 as seen in the IIS logs

#Software: Microsoft Internet Information Services 6.0

#Version: 1.0

#Date: 2010-04-22 14:36:47

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status

2010-04-22 14:40:48 W3SVC1655145481 172.25.5.32 GET /admin.asp - 80 MYCORP\hobbsj 172.25.5.32 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.2;+Trident/4.0;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 401 1 0

The default location for IIS6 is c:\windows\system32\logfiles\w3svc. For IIS7 it is c:\inetpupb\logs\logfiles\w3svc. Note how the 401.1 shows up as 401 1 (status code substatus code). This assumes that the IIS logging properties of the website in focus is set to log the sc-substatus code.

Some Client (IE) Considerations

Same Domain?

For both kerberos authentication and/or NTLMv2 authentication to work the client (Internet Explorer preferably) has to be joined to the domain that the web server is in. (Or it has to be in a domain with proper trusts set up to/from the target domain.)

Unhindered Communication?

The client, the web server, and the domain controller (the KDC – key distribution center) need to be able to communicate with one another over certain ports. If a firewall, for example, has port 88 or 464 locked down Kerberos authentication may not work. NTLM may be able to work when those ports are locked down, however. Still, don’t expect Windows authentication to work when the clients are anonymous clients hitting a webserver from across the internet. The clients are not part of a trusted domain to begin with. And what is more, the KDC is almost certainly protected by a firewall of some kind. It is possible to occasionally get NTLM authentication to work for a client hitting a website across the internet because the client might get prompted for credentials and those credentials might be accepted. However, at this point it would be better to rely on Basic Authentication with SSL rather than NTLM. Neither NTLM nor Kerberos are meant to work across the internet.

Browser Version:

The client browser must be Internet Explorer v5.0 or higher--not Firefox, Netscape, Mozilla, etc.

NTLM or Kerberos?

One thing that can be helpful is to confirm that the IE browser is set to be able to do Kerberos. Click the IE Tools menu select “Internet Options” and select the Advanced Tab. Scroll down to the setting for “Enable Integrated Windows Authentication.” This should be checked by default. If it is not check marked, you can expect your client to try to do NTLMv2 authentication but not attempt to do Kerberos authentication. If you uncheck this and restart IE, you can test the authentication with NTLM. If it works with NTLM but not with Kerberos that is sometimes good to know.

Which IE Zone?

Note whether the address of the website the client is trying to hit is or is not listed in the IE intranet zone list or the IE trusted sites list.

Look in the lower right corner of IE after browsing to the website to see which Zone IE has recognized the website to be in.

In IE, select the Tools menu > Internet Options > Security Tab.

Select Intranet Sites

Click the “Custom Level” button.

For NTLM and Integrated authentication methods to work, it is best that the IE client have “Automatic logon only in Intranet Zone” set (which it usually is by default unless a group policy has changed it) and for the URL that the client is browsing to to be listed in the “Local Intranet” zone list of the client. Many people make the mistake of setting the site in the “Trusted sites” zone list. But that is for internet sites, not intranet sites. And the magic of the automatic logon is only going to occur if that site is in the local intranet site list. If the website you’re browsing to has a period/dot in it, Internet Explorer is going to assume that the site belongs in the Internet zone (not the Local intranet) and will attempt to authenticate accordingly. Don’t expect NTLM or Kerberos authentication to work if the address is an IP address (example: http://64.113.15.3) or a fqdn of a server (example: http://webserver1.mydomain.local). But if you add the address to the local intranet zone, you are one step closer.