Wednesday, November 9, 2011

SharePoint 2010 and Kerberos…Not as bad as it was in 2007

Jeremy Williams, Sr. Director, Modern Workplace

…but don’t get me wrong, it’s still no picnic! 

So I was tasked with taking an existing 2010 farm (running the standard NTLM and SharePoint 2010 RTM) bits over to authenticate over Kerberos.  Having done this many times in 2007, I figured that it would be mostly the same…boy was I wrong.  Luckily, I did a LOT of up-front research, and discovered a pretty decent Microsoft whitepaper on the subject.  Don’t be alarmed when you download this, it’s over 200 pages long, but it’s worth the reading!  [Plus, I’m going to assume that if you’re reading this post for a solution to your problem, then you’ll have already read that whitepaper too].

Scenario: I need to secure a SharePoint 2010 farm so that the user-facing web applications are secured via Kerberos.

Solution – Part I: I followed the above-mentioned Microsoft whitepaper to a ‘T’ to secure the SharePoint environment.  For the sake of brevity, I won’t re-hash those steps here.  However, the SharePoint environment I was working on doesn’t have any non-standard configurations…all of my DNS records were A records, each web application had it’s own worker process, and only standards (80 and 443) ports were in play. 

After running through all of the steps, I saw that SharePoint was working, and a quick perusal of klist on my client and the security log on the SharePoint server showed that I was authenticating over Kerberos… Sweet!   I made one change to the instructions, and that is that I’m not doing constrained delegation, I just allow my service accounts to pass auth wherever asked… I was just about to pack it all up when I noticed something disconcerting…

Problem 1: The search box wasn’t showing up ANYWHERE on my SharePoint page.  When I hit the Search Center directly, I received an error promptly after submitting my search query.  Additionally, most of my shared services had become inaccessible: managed metadata, user profiles, secure store, etc. were all throwing errors in both the UI and error logs.

Solution – Part 2: [Quick note: If you’re experiencing similar issues (and, this is important, you’re running SharePoint 2010 RTM bits), don’t try the other troubleshooting steps you find on the internet just yet…just read on]  Alright, so I performed a TON of troubleshooting here, and nothing seemed to work.  Finally, I had enough, so I decided to apply SharePoint SP1 to the environment.  Remember, this will take down your SharePoint environment for an extended period of time.  At any rate, after the long application of the service packs (Foundation first, followed by Server, followed by psconfig) and a server restart for good measure, everything seemed to be working as advertised. 

The only thing that wasn’t was my User Profile Sync Service, but it started up without any issue and even ran a nice sync using my old connections for me.

Final Validation: After the application of SP1, I tested all of the major feature functionality in the farm (custom web parts with SQL calls, SSRS reports, Profile information, and workflow execution), and everything was working over Kerberos.  Woohoo!

A parting note on Kerberos: Kerberos is great (once it’s configured), it’s less chatty than NTLM, and I like the security it offers (it’s like claims, but for more stuff).  However, Kerberos has it’s limits that you need to remember.  The largest of these limits is that a user must have access to the Ticket Granting Service in order to auth with Kerberos…In other words, if you have SharePoint punched through your firewall and you need users to interact with it over Kerberos outside of your internal network, you’ll need to punch at least one DC’s Kerberos-granting ports through to the internet [Note: I’m not at all recommending that you do that…I’m just saying what you would need to do]…By the way, the correct thing to do (in that scenario) is to leverage something like Microsoft’s TMG…