How a Kerberos Logon Works in Windows 2000
January 3, 2001
As most of you are aware, Windows 2000 includes a new authentication package, which is Microsoft's implementation of MIT's Kerberos protocol. This protocol is much more secure than NTLM and NTLMv2. And with that, I'm going to show you how a client logon happens with Kerberos.
Bob comes into work in the morning, grabs his coffee, and sits down at his workstation. He looks at the Windows 2000 professional logon at the logon screen, hits ctrl+alt+del, and proceeds to type his username, password, and after being authenticated by a Windows 2000 domain controller, logs onto his domain. He starts Microsoft Outlook, to take a look at this morning's pile of email. This seems like a simple process, but that's far from the truth. Let's take a look at what happened in the past few seconds.
Domain Logon Authentication
When Bob pressed "Enter" after typing his password, the Kerberos client on his workstation converted his password to an encryption key. Kerberos is based on the concept of symmetric encryption keys, which means that the same key is used to encrypt and decrypt a message. This is also referred to as a shared private key.
After the Kerberos client converted Bob's password to an encryption key, it's saved in the workstation's credential cache. The workstation then sent an authentication request to the Domain Controller, or KDC (Key Distribution Center is a Kerberos term, used to describe the service that distributes the "keys to the kingdom"). The authentication request identifies Bob, and names the service that he's requesting access to, and some pre-authentication data, that proves that Bob knows the password. The first portion of the authentication request identifies Bob, and asks for access to the TGS(Ticket Granting Service). The TGS is the service on the KDC that issues tickets for access to other services. All of the services within the Kerberos domain trust the TGS, so they know if a ticket was issued by the TGS, that the user successfully authenticated (him/her) self, and is really who he claims to be. The second part of the authentication request contains the pre-authentication data, and is a generic timestamp, encrypted with Bob's long-term key (or password in this case)
When the KDC receives the authentication request, it checks the local AD database for Bob's password. Decrypts the pre-authentication info that was sent in the package, and if the timestamp is within the permissible guidelines (allowable clock difference, usually of 5 minutes or so), sends Bob a TGT (Ticket Granting Ticket) that he's going to use to access the TGS in the future. But even this process isn't so simple (Kerberos is much more complicated than NTLM). To accomplish this task, the KDC creates a session key for itself and Bob to use in their future communications, then it encrypts that session key with Bob's password, and embeds another copy of the session key and some authorization info about Bob (This authorization info is the list of Bob's SID's (SID history, group membership, and Bob's own SID) which is used where ACL's are applied.). It encrypts all of this with it's own long-term key. (The portion that was encrypted with the KDC's long-term key is the actual TGT) The Kerberos implementation in Windows 2000 places the SIDS in the TGT in a field that is defined as optional in the RFC's, which Win2k uses for access control information, which extends Kerberos from not only authentication, but a piece of the access control puzzle as well.
When Bob's workstation receives a reply from the KDC, it decrypts the session ticket with Bob's password, and stores this in the credentials cache. This is the authentication info that Bob's workstation will use to communicate with the KDC from now on, the next time Bob logs on, the session ticket will be completely different, as the KDC doesn't reuse it's session keys. The workstation also extracts the TGT, which will still be encrypted with the KDC's long-term key, (which Bob's workstation doesn't know) and stores the encrypted TGT in it's credentials cache.
"What does all of this have to do with the way I access resources?" you might ask. I'm going to give you a bonus, here's how resource access works in the same domain, with the user being authenticated by Kerberos. Authentication works a bit differently when you are traversing trusts. I will show you that process in an upcoming article.
Resource Access Authentication
Since Bob was authenticated by the KDC, he received a TGT, which allows him to request access to other resources. Since Bob needs to access the word doc reports.doc on the FILESERV1 fileserver, he's going to request access to FILESERV1. Bob might be opening the document from the recent documents menu, or browsing for it in Windows Explorer, however Bob is opening the file, is irrelevant. The Kerberos client performs all authentication in the background, without any user intervention. Below is a detailed process of the entire negotiation.
First Bob's workstation sends a message to the domain controller that granted it's TGT. The message is a Ticket Granting Service Request, that includes Bob's username, the authenticator, the TGT that was sent back to Bob's workstation during the logon, and the name of the service that Bob is requesting access to. (In this case it's FILESERV1) When the KDC receives the message from Bob's workstation, it decrypts the TGT portion of the message, with it's own private long-term key, and pulls out the session key that it embedded during the logon session. It uses the session key to decrypt the authenticator section of the message. If everything checks out OK, it creates a session key for Bob to utilize when talking to FILESERV1.
The KDC now constructs a message to Bob in 2 parts. The first part is the actual session key for Bob to use when talking to the FILESERV1 file server, which is then encrypted in Bob's logon session key. The second part is the session key that Bob is going to use to talk to the FILESERV1 server, but it's encrypted in FILESERV1's long-term key. This message is sent to Bob's workstation.
When Bob's machine gets this message, it decrypts the first part of the message and saves the session key for FILESERV1 in it's credentials cache. Then, it pulls the second portion of the message out (which is encrypted in FILESERV1's long term key, which by the way, Bob's workstation does not know the key by which it was encrypted) and also stores it in it's credentials cache.
Now Bob's workstation is going to access the FILESERV1 server. Bob's machine sends FILESERV1 a Kerberos App Request, which sends the has in it an authenticator encrypted in the session key that the KDC gave to Bob to use when talking to FILESERV1, and the encrypted ticket that the KDC gave to Bob, which is the Bob-FILESERV1 session key, encrypted in FILESERV1's long-term key, that the KDC stores in the Database.
When FILESERV1 receives this message, FILESERV1 decrypts the ticket with it's own long-term key, and is able to read the session key that the KDC gave to Bob for use with FILESERV1. It then decrypts the rest of Bob's message with the session key, viola', an authenticated session is established.
I know this seems extremely complicated, but in relative terms of authentication, it's a simple, and secure process. I'm more than satisfied with Microsoft's implementation of Kerberos in Windows 2000, I think it's a long needed building block for a secure OS. We won't see full benefit of Kerberos, until all of our clients are Win2k, since AD servers still support the old NTLM, and NTLM2 authentication protocols, but I think that day is coming soon....
There is another set of events that occurs after this exchange, that set of events refers to access control, I'll also explain that in another article.