This part of the four part series will look at configuring Kerberos on SharePoint Web Applications.
The first thing we need to do is to map some SPNs (again) and the SPNs themselves depend on whether you are using CNAMEs or A Records to resolve your web sites. If you are using CNAMEs, whose targets are servers with associated A Records, you construct the SPN using the CNAME's target (i.e. the hostname in the A Record). In the case of an A Record, it's much simpler; just use the hostname in the A Record. If you're unsure and don't have access to DNS (for whatever reason) then ping the DNS name and see if it resolves directly to an IP address or tells you it's pinging another address. The former result indicates an A Record is in use, the latter indicates a CNAME.
In the case of CNAMEs, it'll often be the case that the target is a machine which will mean constructing SPNs based on that computer's name. There's a further complication in that the same SPN cannot be assigned to more than one account so if you have a collection of CNAMEs for different Web Applications all resolving to the same A Record, each Web Application must use the same domain account for its Application Pool Identity to maintain a unique mapping of SPNs (this will become clear below).
As an example, I am creating SPNs for a site served on the host header kerbtest on port 80 with an appropriate A Record associated with it. The fully qualified SPN is optional (depending on whether the site is ever accessed using the FQDN), but I would always include it.
setspn –A HTTP/kerbtest yourdomain\UserRunningAppPool
setspn –A HTTP/kerbtest.yourdomain.com yourdomain\UserRunningAppPool
Note that HTTP in this case refers to the HTTP service, NOT the protocol. A common mistake is to mistype the above and start them with HTTP://, which is incorrect.
If your domain functional level is Windows Server 2003 or later, you will need to make some changes on the Delegation tab of the user account running the Application Pool. In Active Directory Users and Computers, locate the user object, right click on it and select Properties. Click on the Delegation tab and change the setting to either Trust this user for delegation to any service (Kerberos only) or Trust this user for delegation to specified services only.
Delegation Tab
Some guides will discuss enabling delegation for the computer account in Active Directory as well, but this is only necessary if the service process is running under the Local System account, which is not the case here.
If constrained delegation (the more secure and, therefore, recommended option) is required, I would suggest making sure everything works with unconstrained delegation first, before pressing on with constrained.
Kerberos can be enabled either at Web Application creation time, or later. I would usually implement it later, and make sure that the Web Application functions correctly with NTLM first.
To change the Authentication Provider to Kerberos, from SharePoint Central Administration (SCA), click on Application Management. Click on Authentication providers under Application Security. Make sure that the correct Web Application is selected and then click on the Zone that you wish to move to Kerberos. I will click on Default. The only change you should need to make is to alter the IIS Authentication Settings by changing the radio button from NTLM to Negotiate (Kerberos). Click OK when the warning dialogue box appears and then scroll to the bottom of the page and click on Save.
Edit Authentication
From another machine on the domain (not one of the SharePoint web front end servers), browse to the Web Application. On the Web Server that you hit you should see an event with ID of 540 in the Security log, containing the following kind of information:
Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 540
Date: 09/07/2009
Time: 14:10:52
User: domain\user
Computer:
Description:
Successful Network Logon:
User Name:
Domain:
Logon ID: (0x0,0x2D996B)
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name:
Logon GUID: {5dea6995-63c8-8ab0-0b1d-e80325461c16}
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.11.12.2
Source Port: 1301
Again, computer, domain and user names have been deliberately removed.
This concludes configuration of Kerberos for a SharePoint Content Web Application. In the final part I will describe how to switch the Shared Services Provider to Kerberos and also add a list of useful references for further reading.
