One of the more complex technologies that a Microsoft Directory Services specialist supports is Kerberos authentication.
When Windows 2000 debuted this was something that was documented well in RFC and whitepaper, but perhaps not thoroughly understood by most people who use our products. People running other operating systems had a leg up in that regard at the time with Kerberos implementations prior to v5 and getting it to work with platforms, applications and KDCs.
We do have a good trouble shooting Kerberos whitepaper:
But it may not cover some complex scenarios and advanced troubleshooting on a per application basis, particularly for new applications.
Why am I bringing this up? Well, pretty frequently lately I've been approached by colleagues with questions on how Kerberos is expected to work in some scenarios. With most technologies that haven't had enormous changes and have been in use for 5+ years we would normally have a good handle on things. Not always true for Kerberos.
So, here is Tim's Quick List Of Things To Keep In Mind For Kerberos:
-Kerberos is the default authentication protocol for Windows and most Microsoft applications, but can always failover to NTLM
-There is no way to "disable" Kerberos (yes, I've been asked that) being attempted, or choosing only NTLM. Kerberos, then NTLM folks. That's the way it works.
-Delegation means that a user is trusting another with his/her credentials, and the trusted identity then does things (access resources) on the trusting identity's behalf. Typical scenario, logged on user on Windows XP uses IE web browser to access IIS web page on a server. IIS in turn accesses resources on that users behalf on an Exchange server, and provides this data back to the user in his web browser so he can get his mail. Viola, OWA!
-Service principal names are constructed of DNS suffixes and the named service being accessed. Which leads to...
-Kerberos cannot work well if DNS is not working well for all computers involved. That statement applies to client side (NIC) DNS settings, name resolution (HOST file, SRV, host and PTR records).
-If you want to know whether Kerberos is working, look at the cached tickets (KLIST or Kerbtray) and/or network captures as the resource is being accessed initially.
-Many applications register their own unique SPNs, and request tickets based on the application's needs. SQL and IIS service principal names are pretty well documented. Others may not be, but hopefully they will use a "well-known" SPN which falls under the HOST standard umbrella.
-Kerberos over trusts entails referrals to the other "realms" so that the requestor can locate the proper KDC to request access from. Think of DNS passing along the question until someone is found who can answer it. Just without the top level domain hierarchy stuff, all Kerberos has is the trusts it knows about, and the DNS to find KDC and create SPNs for requests.
This was some high level stuff, not too deep and no specific scenarios. The next post will cover a specific Kerberos scenario we had to troubleshoot and some techniques we use (with samples of the data). In the meantime, feel free to ask any specific questions which come to mind. I'd love to help you dig in on them.
And I promise not to wait too long to post the next time. No, really.
This blog looks great. I love the content.