IIS 6.0 – Integrated Authentication Issues (NTLM and Kerberos)
Kerberos, for all its many great features and enhancements, can be real pain when it doesn’t work. It is primarily designed for domain centric communications. The upside is that it can enhance your security. The downside is that using Kerberos has the potential to degrade your security (read on before you choke on your own saliva).
The up side:
Kerberos compliments Microsoft’s Domain Server model nicely. It can verify that the connection points are valid, issue access tickets that expire and need to be renewed, and generally make the world a safer place to communicate.
The down side:
Since the Microsoft implementation of Kerberos relies on a domain server, that means that for outside traffic (e.g. web browsing customers) the domain server may need to be exposed to the Internet at large (a domain server is not always required, unless user accounts are domain accounts). If you expose your domain server to the internet to support Kerberos, you have just opened a rather large hole in your network security. Be very careful if you make the choice to do so (hence the possible degradation of security).
Standalone Servers:
Personally, I am running standalone servers (with no domain). This is a common thing for Internet facing servers as they can be placed in a DMZ on your network and your Domain and other critical servers can be placed behind a firewall.
Most of my web traffic is anonymous users coming to my sites. They shouldn’t need domain accounts. The few that do authenticate don’t need domain accounts (local accounts on the web server suffice).
During one of the service packs or updates (not sure which one) an IIS 6.0 server was kicked into a different mode of dealing with integrated authentication (or at least the process of negotiation changed). Integrated authentication is visible when you go to a web site and you get the username/password popup (as apposed to typing your username and password into a webpage itself).
After a certain update (again, not sure which one, but sp1 specifically is mentioned in this context at http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true) my clients and I could not authenticate to areas of any websites that were protected by integrated authentication. The system was trying to use Kerberos to authenticate and was failing.
The Problem:
Before Kerberos will do anything, it tries to identify both the host and the client. When identifying the host, it looks at the name of the host, and then uses that to look up the users account. You may not know this, but often the website address (e.g. www.cmagic.biz) will not match the name of the computer that the site is running on (e.g. server1.cmagic.biz). Because of this, Kerberos says who the heck is www? I know who server1 is, but I don’t know www (www is identified in the DNS system, but Kerberos needs to be specifically told that it is ok to authenticate users for www). Slight or major differences in the name can mess Kerberos up.
Solution 1:
One option is to add to the list of SPNs (Service Principle Names) that Kerberos can use to authenticate against (by default only the NetBIOS name of the computer is registered). The setspn.exe tool (download at http://www.microsoft.com/reskit ) can be used to add new names to the list. Make sure you add the Fully Qualified Domain Name (FQDN) instead of just the name (e.g. use www.cmagic.biz, not www). If you host multiple sites on your server, you may need to add all possible sites using this tool. There is lots more information on setspn.exe so I will let you find the exact command on your own. Why? Because this isn’t my preferred solution. You can find more information about SPNs here: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true
Solution 2:
I would really rather not deal with the issue of adding SPNs every time I toss up a new site. In addition, I don’t feel the need to use Kerberos when clients connect. The simple solution is to kick IIS back into NTLM mode (the old form of communication). Some may argue about security implications, but NTLM is MUCH more secure than basic authentication which sends your login information clear text for EACH new page requested. If you are really worried about security, you need to install certificates and use SSL to protect your communications regardless of your authentication mechanism.
In this solution, you can either edit the IIS Metabase directly (the file that stores all of its configuration information) or you can use the vbs script called adsutil (located in the Inetpub\Adminscripts folder). You need to add or change the NTAuthenticationProviders property. There is a chance that the property doesn’t exist in IIS 6.0 (it should in IIS 5.0). As such, I prefer to use the adsutil script because it will put it in the right location for me and save me from putting it in the wrong spot.
In IIS 6.0, you can tweak this setting at multiple levels. In IIS 5.0, you can turn this on/off globally. For IIS 6.0 users, you need to find out the ID of the website (the default site is always 1, after that its anyone’s guess). To find the ID, look at the logfile properties and at the bottom of the first tab is the log file folder. You will see something like (w3svc23452523\..). The number is what you need (23452523).
Open a command prompt and change to the Inetpub\Adminscripts directory. Then for IIS 6.0 type (replace [websiteid] with your site number – e.g. 23452523):
cscript adsutil.vbs set w3svc/[websiteid]/root/NTAuthenticationProviders "NTLM"
For IIS 5.0 type:
cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"
Once that is done, your IIS server should be set to only use NTLM authentication. Doing this caused my issues to go away. You may need to stop/start your website and/or app pool before the changes take effect.
For more information on using adsutil in this manor, go to: http://support.microsoft.com/kb/215383
NOTE: That page talks about turning Kerberos ON rather than OFF. They show changing the NTAuthenticationProviders property to “Negotiate, NTLM” which means: try Kerberos, then fall back on NTLM.
Ray Pulsipher
Owner
Computer Magic And Software Design
