I’ve had this nagging problem for a while.  Occasionally when I setup SharePoint I do it on a server where host headers are really necessary because I’m sharing IP addresses.  However, it seemed like when I’d do this I could get to the server just fine remotely but locally I’d get a 401.1 HTTP error even if I entered the correct password.  This was frustrating but something I lived with because I could always work around it.  However, tonight, while in the middle of working on a workflow article, I took another run at the problem and actually connected the dots that had eluded me.

When I’m working on the same server as the web site there’s an expectation that I can send a Kerberos-based, login request (Negotiate).  (Kerberos is underneath the covers of AD in Windows 2003 if you didn’t know.)  The same assumption isn’t true from the remote computers.  They’ll try NTLM first.  Both of these fall under the checkmark in the IIS Manager as “Integrated Windows Authentication.”  In fact, there is no user interface to control whether to allow Kerberos, NTLM or both.

I know, that’s all fine and good but how does that equate to a 401.1?  Well, remember I mentioned that this happens when I try to add a host header?  In other words, I’m calling the system something other than what it is defined as in the Kerberos database.  Kerberos being the three-headed dog it is, fails the validation not because the user isn’t authenticated but rather the service principal that IIS is trying to validate with doesn’t match.  Kerberos returns a failure and IIS assumes that it’s the user that made the mistake – not that the administrator doesn’t have things setup correctly for Kerberos.

Rather than addressing a way to setup the server in Kerberos (which I’m sure is possible), I simply turned off the Kerberos authentication in the IIS metabase.  The result is that I can now login from the same server.

In order to do this for your site follow these steps:

1)      Launch Internet Information Services (IIS) Manager.

2)      Expand the local computer and then click on Web Sites.

3)      In the right hand pane locate the site you need to change and its Identifier.  If the identifier column isn’t visible you can select View-Add/Remove Columns… from the menu and select it.

4)      With a note of this number, open up a command prompt and navigate to C:\inetpub\adminscripts.  (Or wherever you’ve moved the IIS administrative scripts to.)

5)      Run the command ‘adsutil GET W3SVC/*YOURIDHERE*/Root/NTAuthenticationProviders’ and press Enter.  Replace the *YOURIDHERE* string with the ID you recorded from IIS Manager.

6)      If the response is “Negotiate,NTLM” Kerberos is turned on, continue on to turn it off.  If you see just NTLM then just NTLM is turned on and just Negotiate means only Kerberos.  The next step we’ll change the value to only NT authentication. (Stop here and you won’t have changed anything.)

7)      Run ‘Adsutil SET W3SVC/*YOURIDHERE*/Root/NTAuthenticationProvider NTLM’.  You should see the “NTLM” string reflected back.

That’s all it takes to turn off Kerberos for a web site and allow you to access it from the local system.