First published on CloudBlogs on Sep, 05 2006
Kerberos delegation scenarios can be some of the most difficult problems for an admin to troubleshoot and resolve. Much of that has to do with the variety of services (also known as applications in non-Kerberos speak) which can be delegated to and from. Each service may be code written to work a particular way, as dictated by what that software is designed to do, and may use it's own network communication methods as well. Knowing how broad a field Kerberos is can be as very useful since it helps to know what types of things which can be unique. I promise that's the most confusing sentence in the entire post, they all get easier from here.
Kerberos delegation can be summed up by saying that a principal (a.k.a. an identity or user) is trusting his or her credentials to a service so that service may access info or do things on behalf of that user. This is typically done so that the user can be seamlessly handed information or do an action that he or she did not directly request while maintaining that identity's security.
In the Directory Services world, there are actually two different things we call Delegation: Kerberos Delegation, and the Delegation of Control (permissions on objects sufficient to allow a user to do a task or tasks based on an access check). A basic distinction is that Kerberos Delegation is allowing a service to do something for a user-on behalf of that user, whereas Delegation of Control is allowing the user to do something directly on an object (like a file or folder, AD object et cetera).
So, let's go over an example of Kerberos Delegation that myself and my colleagues in Microsoft product support see more often: IE--->IIS-->SQL.
In this scenario a Windows 2000 or XP Pro client connects to a web page hosted on a Windows IIS server. This page runs an application which is written to query a SQL database for information and then provide that information back to the user in a web page.
The various configuration points of failure on this are described well in this document:
http://www.microsoft.com/downloads/thankyou.aspx?familyId=99b0f94f-e28a-4726-bffe-2f64ae2f59a2&...
and much more info available here:
http://www.microsoft.com/windowsserver2003/technologies/security/kerberos/default.mspx
But let's go over this and hopefully get a better understanding of what is happening 'under the hood'.
Here's how the sequence of events goes. First, the user logs onto the domain (or configures the principal for non-Windows realm). This part is glossed over pretty frequently but it's critical. Without the user logging on successfully and the computer being able to find a KDC for the configured realm (read:domain) all bets are off.
Next, the user opens Internet Explorer and goes to the URL of the web paged which is being served out by the IIS server. The network traffic flow gives the best understanding of this portion: client sends HTTP GET, server responds HTTP unauthorized (but detailing in that packet the authentication methods the site is configured to support). Client resends HTTP GET (this time including it's Kerberos token in the packet), server then responds with the requested page.
So that gets the initial request out of the way. Picture in your mind a web page with the initial formatting data, but missing fields of information. The fields of data will be supplied by the SQL query's returned data. In real life, you won't normally see it in that half-fulfilled state, but this is for conceptual purposes.
The next part is the IIS server (servers in this middle role are often referred to as the middle tier server) using the user's identity to request the SQL data. You could say that the IIS server (or identity which the application is using in IIS) is trusted for delegation with the users identity <wink>.
For the IIS<-->SQL leg of the journey the network traffic will still have negotiation, but that is usually a bit less interesting. Good to know: the information will be TDS (tabular data stream) packets. The more common failures are well outlined in the various resources mentioned above.
A key note to keep in mind for all of this is that, in order for the IIS server to pass the credentials along, it needs to have a local copy. To make a long story short, the IIS server will initiate requests to the KDC (AS_REQ and TGS_REQ) on behalf of and as the user. The TGT and (MSSQLSvc) service ticket the IIS server receives for that user will be stored in a local cache on the IIS server . That cache is there for that user and accessible for that user and the service which the user trusts only.
Because of the tickets being cached there you could, as a troubleshooting step, dump the general info about those tickets for that user if you had a tool to do so (like KLIST.EXE) via RunAs. In the above situation, were things going as planned, you would see a TGT and a service ticket for the user cached locally on the IIS server.
To finish things up, the IIS server in our story has received the TDS packets containing the SQL queried results. The application in the IIS app pool sorts it out and then passes it along to the client computer's web browser for final display. Voilà.
Thanks all for waiting for the latest post-it was a bit delayed coming thanks to a busy couple of weeks moving. Hopefully, it's been worth your wait.
Also, we’ve had a few comments/emails regarding some things to go over. I hope to be getting into those in the next few weeks.
Have a great day everyone!
