3

We are hoping to the implement Kerberos on our Active Directory (2003, Functional Level 2) so that our SQL Server 2005 databases can communicate with one another when a client is using Active Directory Trusted Connectivity.

The reason this wasn't implemented back in the day (circa 2001?) is that we were highly concerned about the holes using Kerberos left open. We haven't truly revisited this issue until now. After reading a couple articles today, namely How to Implement Kerberos Constrained Delegation with SQL Server 2008 and Understanding When Kerberos Delegation Is Needed for SQL Server we see that it's possible to limit this to SQL Server.

Questions

  • What are some possible pitfalls that we will run into?
  • What might break?
  • Is there a reason not to do this?

EDIT: And dang it...I can't add a Kerberos tag!

Hannah Vernon
  • 70,928
  • 22
  • 177
  • 323
Clownish Carnage
  • 33
  • 3

1 Answers1

1

I did this as well to make linked server permissions sooo much easier to manage. You get to choose "Be made using the login's current security context" when setting up linked server security.

I rarely but occasionally see some inconsistent behavior with the registering / deregistering of SPN's (Kerberos authentication will fail if the SPN becomes deregistered). It very well could be something with our setup, I occasionally experience other network vagueries as well. I mention it because it's always the first thing I check when I get the dreaded "Login failed for NT AUTHORITY\ANONYMOUS LOGON". That is the error you'll get if you've configured security as mentioned above, but Kerberos fails and authentication drops down to NTLM.

Henry Lee
  • 1,246
  • 1
  • 10
  • 16