Dan Larson's SharePoint Developer Blog

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 "LITWAREportalservice", 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 LITWAREportalservice

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 LITWAREnewsgatorService

Now, on the LITWAREnewsgatorService 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 (LITWAREportalservice) 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.

Tonight is the FINAL deadline for edits and corrections for our book (Inside Microsoft Windows SharePoint Services 3.0), and I’m going through the final pre-flight check to make sure all the page compositions and editor changes are correct. I’m also doing this on Ted’s final chapters (which are QUITE good!), and his chapter on Workflow is probably the best resource available for workflow in WSS. I’m quite proud it’s in our book.

So what would YOU do if you were going over the final edits while your partner is on the beach drinking Mai-Tais?  That’s right– you’d send an email like the following to the (pre-alerted) editor with him on the CC line:

Kathleen,

I’m sorry to hear about the page limit length—it’s a shame we have that cap! Ted is going to be disappointed, although I think it’s alright to cut out the last half of the workflow chapter as suggested.

Let’s go ahead and drop pages 271, titled "Developing Custom Workflow Templates", through the chapter summary on page 309. The first 20 pages really do a great job at explaining the core workflow concepts, so if we have to drop 40 pages from the book as required then this would be the least impact.

Again, I’m sad to hear about this requirement, but I think Ted will agree these are the pages to be dropped.

Daniel

So Ted Pattison, you worlflow-slinging, c sharp coding, mai-tai drinking, beach house sleeping, book writing, web part coding, master of all things SharePoint,… YOU sir, have been PUNK’d!!! (And THAT, my friend, is the best chapter on Workflow I’ve ever read, and a highlight of our book!)

And to all who read our book– we DO hope you have as much fun reading it as we did writing it. It should hit shelves JUST in time for Tech Ed– in fact, Ted should have the very first copies at his booth.