The Joys of SPNs

Last week I was at TechEd in LA and spent some of my time listening to Mark Minasi talk about Kerberos in Active Directory. He spent some time talking about SPNs (Service Principal Names). The takeaways were:

a) They needed some love and care when creating them manually.
b) That you really didn't want duplicates of them lying around in AD.

I've dealt with SPNs on occassion when dealing with delegating connections between SQL servers for one of our in-house applications and always remember it being a confusing process that I never spent enough time to seriously understand. So I nodded to myself in agreement with the speaker and moved on.

Then I came back to work. One of our on-going projects required serveral of our company SQL servers to be moved from one domain to another. Our DBA was responsible for planning this work, since he'd ultimately be the one fielding the support calls if things went bad. And he decided to work on this yesterday, tapping me to help out with anything that fell into the realm of Active Directory.

The key troublemaker in all of this? SPNs.

It can be tricky to find old SPNs when you aren't really sure where to look, and since we were never really sure of what we'd done in the past, knowing where to look was a factor. It's also hard to tell if you are doing things correctly using the SetSPN Tool that comes with Server 2003, as it lacks some of the improved features of the Server 2008 version. Also, we had a lot of moving parts involved - changing the domain membership of the servers, changing the service account that runs the SQL Services on each server and the additional issue of forgetting to check that DNS was updated properly.

The big helper in all of this? ADSIEdit.

Once we realized where we were supposed to look (at the service accounts, not the servers themselves), it made adding the new SPNs and remove the duplicates really easy. And now I really think I understand how SPNs work - instead of my previous attempts of just mucking around and getting lucky.