Setting up IIS to work with Kerberos authentication might require extra steps when working with NLB configurations. Kerberos is highly dependent of SPN's (Service Principal Names) and DNS. SPN's are defined in Active Directory and are used by the KDC (Key Distribution Center) in the Kerberos authentication process.
When a user accesses a webservice hosted by a web server, for example http://server01.domain.local, the user will request a Kerberos ticket for the http service hosted on server01.domain.local. The KDC service in the domain will hand out such a ticket and the client will successfully retrieve the website content.
In the NLB scenario however, we could access http://server01.domain.local and http://server02.domain.local which would work fine, but when setting up a load balancing cluster users are supposed to access the web server at http://nlbweb.domain.local. If we do visit http://nlbweb.domain.local we will notice the kerberos single sign on we had for http://server01 and http://server02 is broken.
This can eassily be explained by the fact that there is no one responsible for the http://nlbweb.domain.local service in Active Directory. By default a computer will have two SPN's in AD: termsrv and Host. The Host SPN will be used for a services hosted by the computer which use the local system or network account. Therefore when someone accesses a service using the hostname, authentication will succeed.
Using the setspn tool, available in the Windows 2003 support tools, or built-in in Windows 2008, we can list the registered SPN's and add SPN's.
In a single web server setup, where we would like the users to access our site with a generic name, we could add a SPN for the dns alias:
"setspn -A http/web server01"
"setspn -A http/web.domain.local server01"
Though in a NLB setup, we cannot do this. There is a simple rule to follow: a SPN for a give service should only be registered once in AD! So never add a SPN for a given service on different AD accounts. If we can't add our http/nlbweb service to server01 and server02, we have to delegate it to a user. The following steps are required:Create an AD user for kerberos delegation:
setspn -a http/nlbweb ADuser setspn -a http/nlbweb.domain.local ADuserVerify with setspn -l ADuser
Configuring the authentication on the IIS nodes:
<windowsAuthentication enabled="true" useKernelMode="true" />
useAppPoolCredentials="true": <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
And most important: configure the browser or the client
Access the website from a workstation and make sure the zone displayed is the intranet zone and not the internet. Testing the website from one of the nodes is pointless as it will use NTLM instead of kerberos.
You might enable kerberos debug logging, though keep in mind this will give you a lot "safe to ignore" errors in your eventlogs. Set the following registry key to 1 to enable kerberos logging (0 to disable again), a reboot is not required
Registry Value: LogLevel
Value Type: REG_DWORD
Value Data: 0x1