How a Kerberos Logon Works in Windows 2000
2009-12-04 18:30
204 查看
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.
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.
相关文章推荐
- How to use Pageheap.exe in Windows XP, Windows 2000, and Windows Server 2003
- RunningMapReduceExampleTFIDF - hadoop-clusternet - This document describes how to run the TF-IDF MapReduce example against ascii books. - This project is for those who wants to experiment hadoop as a skunkworks in a small cluster (1-10 nodes) - Google Pro
- How to check in Windows if you are using UEFI
- How-to create a Windows 10 usb installation media in Linux
- How to Defeat Windows 8 ASLR in Getting the Address of KPCR
- How To Translate Unicode Character Codes to TrueType Glyph Indices in Windows
- How to convert from the color camera space to the depth camera space in Kinect For Windows
- How TCP backlog works in Linux
- How to Enable or Disable Access to Windows Updates in Windows 7
- How much of Silverlight is in Windows Phone 7
- How to unpack a tar file in windows
- How to debug Web Services or .Net Remoting Components hosted in IIS in Windows 2003 Server
- How to change the language of oracle sqlplus from chinese to english in windows(如何将oracle sql plus中的中文变成英文版)
- How to enable javascript in windows server 2008 R2 enterprise
- How to edit hosts in Windows 7
- How to Exploit Multiple Monitor Support in Memphis and Windows NT 5.0
- some usual error when configre glut, glui in windows(http://accad.osu.edu/~ywei/Help/HowTos.html)
- How to reset a Roaming Profile in Windows 7
- Ex2010-05 How offline Address books works in Exchange 2010
- MS-DOS autocomplete in Microsoft Windows 2000 and above