Kerberos is a fundamental infrastructure technology for Active Directory authentication, and plays a major role in enterprise web applications, including SharePoint and enterprise servers like NewsGator Enterprise Server (the news and syndication platform of choice, with a rich web interface and a rich set of APIs for enterprise integration. And the best dev team, of course.) 

Fortunately, Kerberos is the default setting for IIS 6.0, but when you use a named identity for the IIS application pool, as you must for server farm SharePoint installations (and should ALWAYS do), you must also create a Service Principal Name (SPN).

The folowing "SETSPN" comands are for use with the SETSPN tool available from www.microsoft.com/downloads. SETSPN is a command line tool that sets, deletes, and lists SPNs for serice accounts and for servers.

Enabling Kerberos using Application Pool Identities

To create the SPN for the SharePoint Site http://litwareportal for the app pool running as "LITWARE\portalservice", run the following SETSPN command. This will let clients browsers authenticate to the application pool’s Web site using Kerberos. Without this, they’ll get a 401.2 error.

setspn -a http/litwareportal LITWARE\portalservice

From within SharePoint, set the site to use Kerberos in SharePoint Central Administration. Go to the Application Management tab, choose "Authentication Providers", and then choose the site. Under IIS Authentication Settings, check that "Negotiate (Kerberos)" is selected.

In order to enable "portalservice" to delegate those credentials to backend systems, you must also set the delegation tab for the portalservice account. This tab does not show up unless the SETSPN command was run to create the SPN for the account. In Active Directory Users and Computers, open the account’s properties and choose the delgation tab. In the delegation tab, choose "trust this acount for delegation to specified servers only", and "Use any authentication protocol". Then, you MUST choose the delegation constraints for each site the account needs to delegate to. Click on "add", enter the host name, and choose "http". If the web server is not running under a named identity, you won’t have to run the SETSPN account on the delegation target as we did above.

Enabling Kerberos Delegation

To delegate credentials, the service account that will do the delegation needs to have the following rights on the server it is running on, set in Local Security Policy of the local server:

• Act as part of the Operating System
• Create a Token Object
• Impersonate a Client After Authentication
• Replace a Process Level Token

If you are running a Windows Service on a remote computer that is NOT running a web application, you can create an arbitrary service principal name for the account, and that account can then perform the delegation and constraints can be entered in the delegation constraints tab in AD. The folowing command creates an SPN for the LITWARE/newsgatorService account, which used with NewsGator Enterprise Server’s Windows 2003 Domain Level, will let the NewsGator Content Service delegate user’s credentials to the SharePoint Server. Note that while the SPN is arbitrary, we will create the SPN for the NewsGator Content Service (ngcontentsvc) on the NGES server:

setspn -a ngcontentsvc/nges LITWARE\newsgatorService

Now, on the LITWARE\newsgatorService account properties, you can set the delegation constraints to constrain its delegation rights to known RSS data sources in the enterprise such as the SharePoint Server and any other secured corporate news feed sources. In NewsGator Enterprise Server installations, you would also enable the SharePoint Server to delegate redentials back to the NGES server so you could use the NewsGator Enterprise APIs from within your SharePoint installation. Since NewsGator Enterprise’s API site typically runs as Network Service, you wouldn’t need to create an SPN for it, but you would need to enable delegation from the portal account (LITWARE\portalservice) to the http SPN of the NGES box (you would do this in the AD account properties).

The delegation choices may not be obvious at first. In the AD account properties, the setting "Use Kerberos only" means that for the delegation to success, the client must have authenticated to the service using Kerberos in the first place. For the service to create arbitrary Kerberos tickets for accounts (also known as Protocol Transition), the setting should be set to "Use any Authentication Protocol". This does NOT mean that the account can delegtate NTLM credentials– it just means that there isn’t a requirement for an original kerb ticket for the service to delegate– the service can "protocol transition" or delegate credentials from a Windows service, as does NewsGator Enterprise Content Service.

Kerberos Troubleshooting

If you’re having trouble with this, there’s a good chance you don’t have the right SPNs for the accounts and servers. I used Microsoft’s NETMON (a required tool in any enterprise developer or IT pro’s toolkit, available free fron microsoft.com/downloads) to view the Kerberos traffic to and from the boxes in question. You can also export the domain to a text file and search for the SPNs in question such as http/litwareportal. The account that is handling the kerberos delegation, as well as potentially clients that will authenticate, will also need to reauthenticate in order to pick up the changes from AD. Just restart the service, or do an IISRESET, to pick up the new changes from AD.

Summary

Kerberos can be tricky to set up without instructions. But follow these simple steps and you’ll be on your way to an enterprise security infrastructure with Kerberos that will let you delegate credentials between trusted servers, without compromising security or using shared credentials.