Today I had the chance to pore through a clients Kerberos configuration. The system as designed needs to provide access based on the users account on the client, through the IIS server, and into the SQL Server. This setup is necessary for the precision auditing and process-level access controls required by the client.
A configuration such as this is not particularly uncommon but it sure isn't commonly documented. I did find lots of places that reiterated the same pointers, tips, and tools over and over again, but they were surprisingly unhelpful at debugging when the default behavior stops working as expected.
If we were using the default configurations the various services would all be running under SYSTEM or Network Service accounts and this works without a hassle. However, that isn't really the safest and most manageable way to operate your system and the minute you start deviating from the simple case, things get tricky pretty quickly.
Our security configurations (like most mature organizations) require that services run under domain accounts. This includes the IIS Application Pool, and SQL Server. For this to work then, the domain accounts we are using for these services must support delegation. And then you have some specific steps to follow to bring it all together. Namely, you need SPNs assigned to domain accounts.
There are lots of references for how to establish SPNs so I'll leave that to you. But I did want to point out to other unique things about Kerberos against SQL Server.
A) When you are taking the SPN route, remember to include the port number in the SPN.
B) Use "Integrated Security=SSPI" in your connection string. This one tends to trip people up.
This wasn't exactly rocket science, but there are so few checklists and practical guidance for this subjectively common subject area that I thought maybe this would spare someone else a few hours of poking the servers with a stick.
