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|
Code for this article:SecurityBriefs0500.exe (33KB)
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 BasicsKerberos 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 CacheSo 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.
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.
Delegation of CredentialsOne 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.
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 ProviderIt 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 CacheOnce 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 CacheSometimes 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 NTLMAt 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.
SummaryKerberos 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.