Microsoft KB Archive/217098

Knowledge Base

Basic Overview of Kerberos User Authentication Protocol in Windows 2000

Article ID: 217098

Article Last Modified on 2/27/2007

---

APPLIES TO

• Microsoft Windows 2000 Server
• Microsoft Windows 2000 Advanced Server
• Microsoft Windows 2000 Professional Edition
• Microsoft Windows 2000 Datacenter Server

---

This article was previously published under Q217098

SUMMARY

This article describes Kerberos user authentication in Windows 2000.

Note that in matters regarding authentication, Windows 2000 is completely backwards compatible. This article focuses on Kerberos user authentication in a pure Windows 2000 environment: authentication between Windows 2000 servers and Windows 2000 clients.

MORE INFORMATION

Windows 2000 provides support for MIT Kerberos v.5 authentication, as defined in IETF RFC 1510. The Kerberos protocol is composed of three subprotocols. The subprotocol in which the KDC (Key Distribution Center) gives the client a logon session key and a TGT (Ticket Granting Ticket) is called the Authentication Service (AS) Exchange. The subprotocol in which the KDC distributes a service session key and a ticket for the service is called the Ticket-Granting Service (TGS) Exchange. The subprotocol in which the client pre-sends the ticket for admission to a service is called the Client/server (CS) Exchange.

The following is a simple overview of the chain of communication involved in a Kerberos authentication session, between a client workstation and a resource server.

1. Authentication Service (AS) Exchange
   
   1. User A, at a Microsoft Windows 2000 Professional workstation, logs on to a Microsoft Windows 2000 network, typing her user name and password. The Kerberos client running on A's workstation converts her password to an encryption key, and saves the result in a program variable.
   2. The Kerberos client sends a message to the Key Distribution Server (KDC), of type KRB_AS_REQ (Kerberos Authentication Server Request). This message has two parts:
      • An identification of the user, A, and the service for which she is requesting credentials, the TGS (Ticket-Granting Service)
      • Pre-authentication data, intended to prove that A knows her password. This is simply an authenticator encrypted with A's master key. The master key is generated by running A's password through a OWF.
   3. The KDC, upon receipt of KRB_AS_REQ from A, looks up the user A in its database (the Active Directory), gets her master key, decrypts the pre-authentication data, and evaluates the time stamp inside. If the time stamp passes the test, the KDC can be assured that the pre-authentication data was encrypted with A's master key, and is not merely a captured replay.
   4. Finally, once the KDC has verified A's identity, it will create credentials that the client program on her workstation can present to the Ticket Granting Service (TGS). The credentials are created and deployed as follows...
      • A brand new logon session key, encrypted with A's master key
      • A second copy of the logon session key and A's authorization data, in a Ticket Granting Ticket (TGT), encrypted with the KDC's own master key.
      • Next, the KDC sends these credentials back to the client by replying with a message of type KRB_AS_REP (Kerberos Authentication Response)
      • When the client receives the reply, it decrypts the logon session key via application of A's master key. The session key is then stored in the client workstation's ticket cache. The TGT is extracted from the message, and stored in the cache as well
2. Ticket-Granting Service (TGS) Exchange
   1. At this stage, the Kerberos client running on A's workstation is going to actually request credentials to access the target server, user B, by sending a message of type KRB_TGS_REQ (Kerberos Ticket-Granting Service Request), to the KDC. This message consists of the following components...
      • Identity of the target service for which the client is requesting credentials
      • Authenticator encrypted with the user's logon session key
      • TGT acquired from the AS Exchange
   2. The KDC decrypts the TGT with its master key, and extracts A's logon session key. A's logon session key is used to decrypt A's authenticator. If A's authenticator passes the test, the KDC invents a new session key for A to share with B. Two copies of this new session key are sent back to A in a single message, encrypted as follows..
      • One copy is encrypted using A's logon session key
      • The second copy is encrypted using the target server's master key, in a ticket along with A's authorization data.
   3. A decrypts the target server session key, using her logon session key, and stores the session key in her cache, along with the target server ticket.
3. Client-Server (CS) Exchange
   1. A's Kerberos client is now ready to be authenticated by the target server, B. A's client sends B a message of type KRB_AP_REQ (Kerberos Application Request). This message contains:
      • An authenticator encrypted with the session key for B
      • The ticket for sessions with B, encrypted with B's master key
      • A flag indicating whether the client requests mutual authentication.
   2. B decrypts the ticket, and extracts A's authorization data and session key. B uses the session key to decrypt A's authenticator, and evaluates the time stamp. If the authenticator passes the test, B looks for a mutual authentication flag. If this flag is set, B uses the session key to encrypt the time from A's authenticator, and returns the result to A in a message of type KRB_AP_REP (Kerberos Application Reply)
   3. A decrypts the reply with the session key. If the authenticator is identical to the one that she sent B, the client is assured that the server is genuine, and the connection proceeds.

Keywords: kbinfo kbnetwork KB217098

---

Send feedback to Microsoft

© Microsoft Corporation. All rights reserved.