This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

Understanding Kerberos Credential Delegation in Windows 2000 Using the TktView Utility

Keith Brown

Code for this article:SecurityBriefs0500.exe (33KB)

T his month I�ll discuss how Windows® 2000 implements delegation of credentials using Kerberos. In looking for information, I found that the Windows 2000 documentation didn�t help much, but I quickly discovered an API that lets you enumerate and manipulate the ticket cache. This was even better than good documentation because I was able to do my own research to discover the nuts and bolts of the delegation mechanism. It also got me thinking about how tickets work in general, which I�ll also discuss. Kerberos Basics       Kerberos is a powerful authentication protocol supported by Windows 2000. As a user of Windows 2000, Kerberos affects your life throughout the day. From the time you log in to your machine first thing in the morning until you leave at night, Kerberos is watching over your identity, helping to make sure that a bad guy doesn�t impersonate you on the network.       If you�re unfamiliar with the Kerberos protocol, check out David Chappell�s introduction to Kerberos in the August 1999 issue of Microsoft Systems Journal, which is available at https://www.microsoft.com/msj/0899/kerberos/kerberos.htm.       Conceptually, Kerberos is pretty simple if you break it down into its fundamental atoms: tickets and session keys. For Alice to prove her identity to Bob, she must first obtain a ticket from a centralized authority to present to Bob. In Kerberos, this authority is known as the Key Distribution Center (KDC), and this service is implemented by each domain controller in a Windows 2000 domain. Let�s assume that Alice and Bob are in the same domain. In this case they share the same Kerberos authority, and Alice can go directly to her local KDC and get a ticket for Bob. To get a ticket for Bob, Alice must prove her identity to her KDC by proving knowledge of her password (or, in the case of a smart card logon, knowledge of her private key). David Chappell�s article discussed how this works, so I won�t rehash that here. However, I would like to review how tickets work, since my topic revolves around the Kerberos ticket cache.       The ticket that Alice gets for Bob has lots of information, but what�s really critical is that it contains Alice�s name and a randomly generated encryption key (known as a session key). What�s also important is that the KDC locks this information in the ticket by encrypting it with a master key generated from Bob�s password that only Bob and the KDC share. So if the KDC produces this ticket and gives it to Alice, when Alice presents it to Bob, he can verify that the contents really came from the KDC by successfully decrypting the ticket. The basic idea is that Bob will decrypt the ticket, look at the client name, and realize that whoever sent the ticket to him must really be Alice because the KDC validated her identity before giving her the ticket.       If you think about this for a minute, though, you�ll realize that there would be a gaping hole in the protocol if it were really that simple. When Bob receives a ticket from the network, Bob has no idea who really sent him that ticket. It could be a bad guy who simply recorded Alice sending the ticket to Bob earlier and is simply replaying the ticket, hoping to masquerade as Alice. So not only must Alice send the ticket, she must also prove that she is the owner of the ticket. That�s the purpose of the session key.       If Alice can prove she knows the session key that the KDC whispered in her ear when she asked for the ticket, Bob will be satisfied that it really was Alice who sent the ticket. So Alice sends a little package called an authenticator along with the ticket. The authenticator is simply her name plus the time on her clock (in universal coordinated time), encrypted with the session key. If Bob can decrypt this authenticator, the name inside matches the client�s name inside the ticket, and the timestamp is recent and not in his replay cache, Bob accepts this as proof of Alice�s identity.       This is an example of a server ticket (STkt), which Alice uses because she wants to prove her identity to Bob (a server on the network). To get STkts in the first place, Alice uses a ticket granting ticket (TGT). When Alice requests an STkt for Bob from her KDC, she must prove her identity by presenting her TGT (which is simply a ticket for the Kerberos ticket granting service), and prove knowledge of the session key inside it via an authenticator. Earlier, when I said that the KDC whispers in Alice�s ear, what I meant was that the KDC actually uses this session key in the TGT to send secrets discreetly back to Alice. These include session keys for use with the STkts that Alice requests.       So how many tickets does Alice need to set up an authenticated connection with Bob? She needs two tickets in this case: one for the KDC (which she and Bob share since they are in the same domain), and another for Bob. The first is a TGT and the second is an STkt. Any ticket Alice holds will be accompanied by a unique session key that confers ownership upon her.       What if Alice and Bob aren�t in the same domain? Alice will need to follow a path of trust from her domain to Bob�s domain to get a TGT for Bob�s KDC. If Alice is in the domain instructors.la.develop.com and Bob is in the domain admin.boston.develop.com, the natural path of trust (which follows the DNS hierarchy) is as follows:

instructors.la.develop.com
la.develop.com
develop.com
boston.develop.com
admin.boston.develop.com

Alice always obtains her initial TGT from the domain in which she is a member (instructors). Following the path of trust, she�ll ask instructors to give her a ticket to the Kerberos ticket granting service at la.develop.com. (Trust relationships in Kerberos imply that an authority trusts another authority to give out TGTs on its behalf.) She�ll then ask la.develop.com to give her a TGT for develop.com, and so on until she ultimately gets a TGT for admin.boston.develop.com. Now she can get an STkt for Bob from that KDC. It sounds like a lot of work, but because each incremental step (that is, each TGT/session key pair) has been cached along the way, if Alice wanted to authenticate with a server in the instructors.boston.develop.com domain, she would already be most of the way there. Tickets are cached on Windows 2000 for 10 hours by default, although this setting is adjustable via group policy. The Kerberos Ticket Cache       So what�s in Alice�s ticket cache, and why would Alice bother to look? For one thing, if Alice is trying to authenticate with lots of different server principals in various domains and she is occasionally running into trouble doing so, she can determine how far she was able to get along each trust path by looking at the breadcrumbs left at each stop along the way. Perusing the ticket cache is quite useful for diagnosing problems. Figure 1Authentication       Back in the days of Windows NT® 4.0, when the NTLM authentication protocol ruled the roost, each time Alice would authenticate with Bob it would be Bob (not Alice) who talked to Alice�s authority (see Figure 1). Since this happened every time Alice reauthenticated with Bob, the obvious drawback was that Alice�s authority could be overloaded with authentication requests. This is one reason why lots of backup domain controllers are sometimes necessary in large domains. But the benefit of this older mechanism is that since Bob (the server) was in close contact with Alice�s authority, he was always able to obtain the most up-to-date authorization attributes for Alice. Authorization attributes consist of groups, aliases, and privileges, and the group assignments are always provided by the client�s authority. For instance, if Alice becomes a member of a new group and then reauthenticates with Bob in NTLM, Bob will see this change immediately.       How does this work in Kerberos? Well, when Alice first logs in to her machine in the morning, she authenticates with her authority and obtains a TGT so that she can request tickets for other servers on the network (she�ll even need an STkt for her own machine). This TGT contains a snapshot of Alice�s authorization attributes. (The KDC looks in the Active Directoryâ„¢ service to discover the groups to which Alice belongs, and stores these SIDs in the ticket.) Since the TGT is locked with a key that only the KDC knows, Alice cannot alter these groups without ruining the TGT.       Let�s take the example where Alice has to traverse several authorities to get a ticket for Bob. Each time she presents her TGT and asks for a TGT for the next authority in the trust path, the authority simply copies the authorization attributes from the presented TGT to the new TGT. When Alice finally reaches Bob�s authority, that KDC copies those same authorization attributes into the STkt for Bob. So what Bob ends up seeing each time Alice presents this ticket is the snapshot of Alice�s authorization attributes from earlier that morning. It is possible for this snapshot to become stale later in the day if an administrator changes Alice�s authorization attributes. This happens frequently in a lab environment during security tests, but much less frequently in a stable production environment. If Alice wants to refresh her security context for Bob, she needs to purge her cache to force her local Kerberos provider to retrieve new tickets as needed, thus repopulating the cache. She should purge all the intermediate TGTs as well, not just the STkt for Bob; otherwise, it�s likely that the system will pick up wherever the trust path left off in the cache and end up with the old authorization attributes. Delegation of Credentials       One of the features built into Kerberos is delegation of credentials documented in RFC 1510 (see https://www.ietf.org/rfc/rfc1510.txt?number=1510). This is where Alice chooses to loan her network credentials to others for a fixed amount of time. The KDC ultimately decides which clients can exercise this feature, since a client must obtain a special ticket for the target server. There are two ways of delegating credentials in Kerberos: via a proxy STkt, or via a forwarded TGT. Windows 2000 uses the latter, most likely because it�s the simplest implementation and fits naturally into the existing Windows security model. This means that Alice can obtain a forwarded TGT and discreetly communicate it along with its associated session key to Bob (see David Chappell�s article for a great picture of how this works). Now Bob can pretend to be Alice until the ticket expires. He can go to Alice�s authority and requests tickets for other servers on Alice�s behalf, for good or evil. Clearly this is a privilege that could be abused if there were no constraints other than ticket expiration (imagine that Bob had been compromised by a bad guy; 10 hours is a long time to party on the network with Alice�s credentials, especially if she is a system administrator).       The fundamental properties that the Windows 2000 KDC uses to constrain the use of delegation are in the directory service. The first controls which clients are allowed to delegate their credentials, and is associated with every user account in the Active Directory service: "Account is sensitive and cannot be delegated." The second controls which server principals are trusted to receive these delegated credentials: "Account is trusted for delegation," which is found on user principal accounts, and "Trust computer for delegation," which is found on computer accounts. The former affects servers that run under distinguished user accounts, while the latter affects servers that run as part of the operating system itself (in the SYSTEM logon session) on a particular machine.       Based on looking at the types of tickets that the Windows 2000 KDC issues, the following rules appear to hold. If a client�s account is not marked as sensitive, the client�s TGT will be flagged forwardable, which indicates that the client is allowed to request forwarded TGTs to give to other servers. When the client gets an STkt for a server (either running under a distinguished user account or under a computer account), if that server principal is marked as trusted for delegation, the STkt will be flagged ok-as-delegate. This recent addition to Kerberos won�t be found in RFC 1510, but instead can be found in a newer IETF Internet-Draft (https://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-revisions-06.txt). The client-side Kerberos security provider won�t delegate a client�s credentials to a server whose ticket doesn�t possess this flag. Figure 2TktView in Action       Understanding these settings didn�t come easy for me. The online help for Windows 2000, although much better than the help in Windows NT 4.0, doesn�t do a very good job of describing what these settings mean. It wasn�t until I wrote a tool to enumerate the cache and actually saw the tickets being issued that I was able to determine what they actually mean. I found this tool so useful that I dressed it up with a GUI and named it TktView (see Figure 2). Connecting with the Kerberos Provider       It turns out that there isn�t just a single ticket cache per machine. Rather, each logon session has a private ticket cache that nobody else is privy to. This is good because the ticket cache contains the corresponding session keys that confer ownership of tickets to their holders. You don�t need to have any special privileges to access your own private ticket cache, but you need to be part of the trusted computing base (TCB) on a machine to see someone else�s ticket cache. I decided to keep version one of TktView simple, so the program dumps the cache for whatever logon session you run it in. Typically this will be your interactive logon session, but you could get more fancy (see my article, Handle Logons in Windows NT and Windows 2000 With Your Own Logon Session Broker at https://www.microsoft.com/msj/0200/logon/logon.asp in the February 2000 issue of MSJ).        Figure 3 shows the prototypes and code for connecting to your local Kerberos provider. Basically this consists of establishing an untrusted connection to the Local Security Authority (LSA) and looking up the index for the Kerberos authentication package. The difference between a trusted and untrusted connection is that the latter can be made from outside the TCB, while the former can only be made from inside. For example, WinLogon, which runs in the TCB, has a trusted connection to the LSA. Perusing the Ticket Cache       Once you are connected, there are two ways of viewing the ticket cache. You can ask for a list of tickets, or you can ask for an individual ticket by providing detailed information about which ticket you want. Remember that the body of a ticket is encrypted so that only the target server can read it. Because of this, TktView doesn�t bother trying to get the body of the ticket itself (although this is possible); rather, it simply enumerates the information in the cache that was sent back with each ticket. This information answers several questions about the contents of a ticket: which server principal it targets, what time it expires, what flags are set in the ticket, and so on.        Figure 4 shows the prototypes and code used to enumerate the tickets in a given logon session. Note that the request message includes a logon session identifier. Unless you�ve made a trusted connection to the LSA, you must set this value to zero, indicating that you want information about your own ticket cache. If you were part of the TCB and knew the logon session ID for another local logon session, you could enumerate its tickets as well. At least this is the documented behavior; I have not yet tried to add this functionality to TktView. Purging the Ticket Cache       Sometimes it�s useful to refresh your ticket cache, especially when you�re working in the lab or experimenting with security in Windows 2000 and want to know how something works. A fresh ticket cache can give you lots of great clues. From a practical perspective, purging the ticket cache can help you freshen your security profile on the network after your group assignments have changed in the Active Directory service.        Figure 5 shows the format of the message that you�ll need to send to the Kerberos authentication package to purge your cache. Note once again the presence of a logon session identifier. This works exactly the same way as I described earlier. Also note that it�s theoretically possible to be more selective and only purge tickets that refer to a particular server principal. I say theoretically because I haven�t figured out what brand of rubber chicken to wave over my machine to make it work. Watch out for NTLM       At one point during my experimentation I made a remote authenticated request (which succeeded), and yet I couldn�t find the ticket that had been issued to make this possible. On all the machines I use on a day-to-day basis I�ve enabled auditing of logon and logoff events (something I urge all developers to do in the lab), and so when I checked the server�s audit log, I discovered that the client had been authenticated. I scratched my head until I looked at the detailed information in the audit record: the NTLM providerâ€"not the Kerberos providerâ€"had authenticated the client.       I was really surprised at this behavior since the client was using a domain account in a Windows 2000 domain and both client and server were running Windows 2000. In fact, the client was running on the same machine as her KDC. I�m hoping to get some resolution on what caused this behavior. (I�ll share any feedback and keep you up to date at https://www.develop.com/securitybriefs.) The moral here is to keep an eye on your audit logs, not just the ticket cache, so you get the whole picture. Summary       Kerberos is a powerful authentication protocol, and if you are planning to develop distributed applications for Windows 2000, you should start getting comfortable with it as soon as possible. Familiarizing yourself with the ticket cache is a really great way to develop a better understanding of how Kerberos works in Windows 2000. My TktView utility should get you started.

Keith Brown works at DevelopMentor, developing the COM and Windows NT Security curriculum. He is coauthor of Effective COM (Addison-Wesley, 1999), and is writing a developer�s guide to distributed security. Reach Keith at https://www.develop.com/kbrown. From the May 2000 issue of MSDN Magazine.