Kerberos Authentication in Active Directory

The Kerberos version 5 authentication protocol provides a mechanism for authentication — and mutual authentication — between a client and a server, or between one server and another server.

Rather than transmitting user actual password over the network, Kerberos operates with a series of tickets.  When you sit down at your workstation and press Ctrl+Alt+Del to log on and enter your credentials, your machine begins the process of authentication.


The process can be divided into three stages

  1. Authentication
  2. Obtaining a Service Ticket
  3. Accessing the Services

  1. Authentication process.

At this step the system sends an AS_REQ or authentication request to Kerberos message to the DC. We call the DC a Key Distribution Center (KDC)


The client name is the user principle name (UPN) . To prevent replay attacks whereby an attacker recycles an AS_REQ message, the current time is encrypted using a hash of the user’s password .Once the KDC receive the AS_REQ , KDC will decrypt the encrypted time stamp using its local copy of the user’s password hash .If this operation fails then an error message will be send to the client .

If the decryption is successful and the timestamp is within acceptable limits, the KDC returns an AS_REP (Authentication Service Reply) message to the user, with an embedded TGT  .

AS Res        as res2

At this point user’s machine caches the TGT and session key for life time of the TGT, by default this will be 10 Hours. AS_REP message contains two parts. In first part, the session key will be used for further communications with the KDC and this will be encrypted with client secret.

The second component, the TGT is encrypted with the KDC’s secret .The KDC’s secret in AD’s Kerberos implementation is stored as the password to the krbtgt user account that exists in every AD domain. The krbtgt account is created when the first DC in a domain is promoted; this account is crucial to the domain’s operation.

  1. Obtaining a Service Ticket

After you log in and try to access a resource or service the service ticketing process gets started. Client system will send a TGS_REQ message to KDC when the client attempts to access a service.

The first piece of information is the SPN of the service the client is requesting a ticket for. Encrypted with the session key the client received as part of the AS_REP earlier is the client’s name and a timestamp. This information is again used to prevent replay attacks whereby an attacker reuses a request message. Also included is a copy of the TGT the client received earlier.

Once KDC validate the TGS_REQ the client will receive a TGS_REP from the KDC which will be embedded with a service ticket. Now client has everything to access the requested service. This will be valid for 10 Hrs by default policy.

  1. Accessing the Services

Once the client has a service ticket, the ticket can present to the service and request for the access. The service ticket is presented to the application in the form of a Kerberos AP_REQ message which contains the previous service ticket and client details.


The service decrypts the service ticket and obtains the session key, which it can use to decrypt the timestamp and client name fields, which are in turn used to validate the authenticity of the service ticket itself. It’s important to note that even if the service accepts the service ticket, at this point the client has merely authenticated to the service. The task of authorization is still up to the service, based on the information it has about the client.