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

Jeremy Williams — Wed, 09 Nov 2011 16:11:58 GMT

…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…

HTTP 503: Service Unavailable after a SharePoint Upgrade…HELP!!!

Jeremy Williams — Mon, 07 Nov 2011 19:48:41 GMT

As pointed out to me by my esteemed colleague (Kathryn), November is apparently a blogger’s goal month of a post-a-day. While I think that might be a bit of a lofty goal for myself, I’m going to strive to get a lot more posts out than I have in the past. We’ll see how it goes, but in the meantime, I hope this posts provides a bit of comic relief for those that have ever been in this situation; and some relief for those that haven’t and/or currently are in it!

Scenario: You’ve been tasked with patching your SharePoint 2010 installation…You’ve done all of the leg-work: made and verified you have full backups at the ready, a solid back-out plan in place, all of the latest and greatest (and applicable) update files on the server, a cup-full of coffee, and an after-hours maintenance window. [Note: this is NOT a full list of everything you’ll need for a patching-session, but let’s pretend for the sake of my post that it is :-)] Before you start, you think, “I’m prepared, how bad can it be?” <—Why did you think that, you jinxed it now for sure!!

The horror story unfolds: You start patching as directed by Microsoft, applying the SharePoint foundation patch-pack followed by the SharePoint Server patch-pack, and you finish off by running psconfig (FKA SharePoint Products Configuration Wizard). At the end of the agonizingly slow process (during which time, you were luckily reading this blog post) you see an error message pop up… Paying no attention, you click okay and you get this beautiful screen while launching Central Administration:

The panic: Your maintenance window is quickly closing in…You frantically search through Event Viewer, ULS logs, Services, etc… You might even fire up IIS manager quickly see if your web sites are somehow stopped (which, of course, they’re not). What you might not think to check are your application pools… Go ahead and fire that up, and you’ll probably see something similar to this (below):

The Solution: Go ahead and hit this problem with a big hammer, and start all of the application pools (later, you can go back and clean it all up, right now you just need to get SharePoint back up and running!) After that, hit all of your SharePoint URLs and make sure everything is working as expected [P.S. Don’t forget to check each of your server’s IIS manager snap-in to ensure all application pools are running]…It should (if you were experiencing the same problem as this post is detailing). If you’re still having intermittent errors, you might want to go back and check up on your custom solutions, the event log, ULS log, etc…

Why it happened?? Sometimes, for whatever reason, a SharePoint update package doesn’t play nice with psconfig, and it’ll throw an error…I don’t know why this happens only sometimes, but I’ve personally run into it a number of times. I believe the primary issue (with the error) is that psconfig dies early, and doesn’t have a chance to restart all of the application pools. Once you’ve restarted all of your application pools, it can’t hurt to re-run psconfig to make sure everything has been properly updated.

As always, I hope that this has been helpful!!

Viewpoint : Troubleshooting, SP2010

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

HTTP 503: Service Unavailable after a SharePoint Upgrade…HELP!!!