Why does the Server need access to Kerberos?

Question

I am trying to find out how to authenticate Active Directory users to a remote server.

The goal is to use SPNEGO to receive a Kerberos ticket. The Kerberos ticket can then be decrypted and the identity of the user can be estabilished.

What I do not understand, is why access between server and Kerberos is required. Since the Service Ticket contains the client identity and is encrypted by the TGS private key, the Server does not need access to the Kerberos TGS. It can just decrypt the Ticket and know the user identity. Can anybody explain to me why it is necessary?

http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/16/1054.aspx

Any schemes like Identity Providers or WIF does not seem necessary to me if all I want is a client identity.

Answer 1

It turns out there are a bunch of answers to this question...I won't even attempt to cover all of them here (partly for brevity reasons, partly because the details have become hazy and I don't remember them all :)). I'll cover the big two that come to mind, but again, there are more.

First, you are speaking of round trips to the DC as if it is all about Kerb as the DC is the KDC. I guess that's one way to look at it, but the overall Windows auth stack does far more than just validate Kerb tickets. For example, things like SID resolution are required in order to make heads or tails out of tickets that come in when making authz decisions. So communication happens back to the DC (which is a KDC and more) for many reasons and using many protocols, some of which are supporting the authz stack which is what is typically interesting for most folks.

Second, for Kerb specifically...there are some features of the protocol where going back to the KDC has security value. PAC validation is the first that comes to mind. I'd suggest reading up on this...here's one of a zillion posts that cover it: http://blogs.msdn.com/b/openspecification/archive/2009/04/24/understanding-microsoft-kerberos-pac-validation.aspx I would note that in this case, there are things you can do to actually disable this downstream->KDC flow (like giving the principal TCB). These things are not to be done lightly though...ie, it's more than just a "perf fix" to consider. :)