#status/done

Kerberos

The Kerberos authentication protocol, used by Microsoft, is adopted from the Kerberos version 5 authentication protocol created by MIT and has been used as Microsoft's primary authentication mechanism since Windows Server 2003.

At a high level, Kerberos client authentication to a service in Active Directory involves the use of a domain controller in the role of a Key Distribution Center, or KDC and uses of a ticket system.

Process

  1. A user logs in to their workstation, a request is sent to the domain controller, which has the role of KDC and also maintains the Authentication Server service. This Authentication Server Request (or AS_REQ) contains a timestamp that is encrypted using a hash derived from the password of the user and the username.
  2. The domain controller receives the request, it looks up the password hash associated with the specific user and attempts to decrypt the timestamp. If the decryption process is successful and the timestamp is not a duplicate (a potential replay attack), the authentication is considered successful.
  3. The domain controller replies to the client with an Authentication Server Reply (AS_REP) that contains a session key (since Kerberos is stateless) and a Ticket Granting Ticket (TGT). The session key is encrypted using the user's password hash and may be decrypted by the client and reused. The TGT contains information regarding the user, the domain, a timestamp, the IP address of the client, and the session key. **To avoid tampering, the Ticket Granting Ticket is encrypted by a secret key known only to the KDC and can not be decrypted by the client. **
  4. The client has received the session key and the TGT, the KDC considers the client authentication complete. By default, the TGT will be valid for 10 hours, after which a renewal occurs. This renewal does not require the user to re-enter the password.

But since the user wants to access a actual resource of the domain, such as a network share or a mailbox, it must again contact the KDC.

  1. This time, the client constructs a Ticket Granting Service Request (TGS_REQ) packet that consists of the current user and a timestamp (encrypted using the session key), the name of the resource, and the encrypted TGT.
  2. The ticket-granting service on the KDC receives the TGS_REQ, and if the resource exists in the domain, the TGT is decrypted using the secret key known only to the KDC. The session key is then extracted from the TGT and used to decrypt the username and timestamp of the request. At this point the KDC performs several checks:
    1. The TGT must have a valid timestamp.
    2. The username from the TGS_REQ has to match the username from the TGT.
    3. The client IP address needs to coincide with the TGT IP address.
  3. If this verification process succeeds, the ticket-granting service responds to the client with a Ticket Granting Server Reply (TGS_REP). The first two parts (service name and session key) are encrypted using the session key associated with the creation of the TGT. The service ticket is encrypted using the password hash of the service account registered with the service in question. This packet contains three parts:
    1. The name of the service access has been granted.
    2. A session key to be used between the client and the service.
    3. A service ticket containing the username and group memberships along with the newly-created session key.

Once the authentication process by the KDC is complete and the client has both a session key and a service ticket, the service authentication begins.

  1. The client sends to the application server an application request (AP_REQ), which includes the username and a timestamp encrypted with the session key associated with the service ticket along with the service ticket itself.
  2. The application server decrypts the service ticket using the service account password hash and extracts the username and the session key. It then uses the latter to decrypt the username from the AP_REQ. If the AP_REQ username matches the one decrypted from the service ticket, the request is accepted. Before access is granted, the service inspects the supplied group memberships in the service ticket and assigns appropriate permissions to the user, after which the user may access the requested service.

This protocol may seem complicated and perhaps even convoluted, but it was designed to mitigate various network attacks and prevent the use of fake credentials.

Relevant Note(s):