Kerberos Ticket Flow

[Previous] [Next]

Let's look at the most basic Kerberos authentication overview. In the example illustrated by Figure 14-3, a client logs on to her workstation and then wants to access a remote server.

Figure 14-3. Kerberos authentication flow.

The following simplified steps take place when Kerberos authentication occurs:

1. Alice sends a request to the AS saying, "Hey, I'm Alice. Give me a TGT so that I can access other resources."
2. The AS sends a TGT and a special message encrypted with a key related to Alice's password. (This is not the case when using Kerberos preauthentication, but the spirit is right.) Both the TGT and the special message contain a (shared) session key that Alice and the KDC can use to converse securely.
3. Alice sends a request to the TGS saying, "Hey, it's me again. I want to access a remote server named WebServer."
4. The TGS sends an ST back to Alice along with a session key. The ST, encrypted with WebServer's password, also contains that session key—this is the secret that Alice and WebServer will use to protect their communications.
5. Alice sends the ST to the remote server.
6. The server verifies the ST and sends a data packet called an authenticator back to the client to verify its own identity to the client.

NOTE

---

Steps 1 and 2 happen only when Alice logs on to her computer or when the TGT expires. Steps 3 and 4 occur each time Alice accesses a server she has not accessed previously or if the ST for the server has expired.

Now that we have a basic understanding of how Kerberos authentication works and how TGTs and STs fit together, we'll look at an example.

Kerberos Ticket Flow in the Sample Application

Let's take a moment to reacquaint ourselves with the book's sample application. Figure 14-4 outlines its design.

Figure 14-4. The design of the sample application used in this book.

Here are the major authentication parameters we'll focus on:

• Alice logs on to a desktop computer called Cheryl-Laptop.
• She is authenticated against a domain controller, running Active Directory on a server named DBServer.
• Using Microsoft Internet Explorer 5, she wants to access an IIS 5 server running on WebServer. The Web server is configured to use Integrated Windows authentication.
• The Web application accesses a remote COM+ component that resides on the Middleware server. The COM+ application startup account is AppAccount.

We'll show the Security Event Log entries you'll see if you're auditing for successful and failed account logon and successful and failed logon\logoff.

Alice logs on

Alice sits down at a laptop computer, presses Ctrl+Alt+Delete, and enters her username and password.

Domain controller authenticates Alice

Steps 1 and 2 occur as her computer contacts the AS at DBServer to request a TGT. If this phase of the process succeeds, you'll see the Security Event Log entries shown in Figures 14-5 and 14-6 at the domain controller.

Figure 14-5. The initial TGT being returned to Alice by the AS in the KDC.

Figure 14-6. Alice is given an ST to use on Cheryl-Laptop.

Next, steps 3 and 4 occur as her computer requests an ST for Alice. You'll now see the Security Event Log entries shown in Figure 14-7.

Figure 14-7. Another ticket is returned to Alice by the TGS in the KDC to allow her to delegate her credentials.

Finally, Alice is authenticated, as shown in Figure 14-8.

Figure 14-8. The logon event at Cheryl-Laptop showing that Alice logged on.

Using KerbTray, as shown in Figure 14-9, Alice can see what tickets are currently available to her.

Figure 14-9. Alice viewing her tickets.

Note there are two krbtgt/EXPLORATIONAIR.COM tickets. The highlighted ticket was issued by the AS; it is Alice's initial ticket. The second has different flags set—Forwarded is set, but Initial is not set. This ticket is used by Alice for delegation purposes when she accesses remote servers.

Alice accesses the Web server

Next, Alice starts Internet Explorer and accesses the Web server named WebServer. When this event occurs, she requests an ST to enable her to access the server. Figure 14-10 shows the Windows 2000 domain controller issuing an ST.

Figure 14-10. The Windows 2000 domain controller issuing an ST to Alice so that she can access WebServer.

Figure 14-11 shows Alice successfully logging on to the Web server.

Figure 14-11. Alice viewing her tickets.

As you can see in Figure 14-12, Alice now has another ticket available to her.

Figure 14-12. Alice's tickets, including the new ticket to access WebServer.

Web server invokes COM+ application

Finally, the ASP page on the Web server attempts to launch a remote COM+ component that resides on the Middleware server. The first step is for Alice to get an ST to access the Middleware server, as shown in Figure 14-13.

Figure 14-13. Alice requesting an ST so that the Web server can access Middleware on her behalf.

The next two steps are interesting. Figure 14-14 shows the AppAccount account, which is used as the identity for the COM+ application, requesting a TGT from the AS. Figure 14-15 shows the completion of the logon as AppAccount logs on to the Middleware computer.

Figure 14-14. The COM+ AppAccount account requesting a TGT.

Figure 14-15. The COM+ AppAccount account logs on to the Middleware server.

We haven't shown the request from Middleware to DBServer, but it's virtually the same as the request from WebServer to Middleware: Alice will get an ST, and the Middleware computer will use it to access the DBServer computer.

NOTE

---

To make identity delegation work, each ST request must include Alice's TGT. If it does not, Alice's identity cannot be delegated.