Skip to content

Kerberos Authentication

Sources for this notes

How it works

Active Directory is a Microsoft solution used for Windows network management, and provides the following services:

  • Directory service (LDAP)
  • Authentication (Kerberos)
  • Name resolution (DNS)
  • Homogeneous software policy

Kerberos is used whenever a user wants to access some services on the network. Thanks to Kerberos the user wonā€™t need to type his password every time and the server wonā€™t need to know every userā€™s password. This is centralized authentication.

In order to do this, at least three entities are required

  • AĀ client
  • AĀ service

  • AĀ Key Distribution CenterĀ (KDC) which is aĀ Domain ControllerĀ (DC) in Active Directory environment.

  • Authentication Service (AS): The client must authenticate itself to the KDC.

  • Ticket-Granting Ticket (TGT): He must then request a ticket to access the chosen service (e.g. CIFS, HTTP, SQL, ā€¦).
  • Application Request (AP): He finally uses the service by providing the ticket.

Authentication Service (AS)

We are in Active Directory context, so the KDC is also the Domain Controller (DC). The KDC contains all the domain information, including the secrets of each service, machine, user. Thus, except for the DC, everyone only know his own secret, and therefore do not know the secrets of the other objects in Active Directory.

KRB_AS_REQ

User pixisĀ will first send a request for aĀ Ticket Granting TicketĀ (TGT) to the Domain Controller (DC). How? By sending - its name - a timespan encrypted with a hashed version of its password.

This request is calledĀ KRB_AS_REQĀ (Kerberos Authentication Service Request).

The Key Distribution Center (KDC) will receive this username, and will verify that it exists in its database.

If it finds it, it will then retrieveĀ pixisĀ hashed password which it will use to try to decrypt encrypted timestamp. If it canā€™t, then the client didnā€™t use the correct password to encrypt this timestamp.

If it does, however, the KDC is assured that it is reallyĀ pixisĀ who is talking to him. It will generate a unique session key tied to this user and limited in time.

KRB_AS_REP

The Key Distribution Center (KDC) sends back different things toĀ pixisĀ (KRB_AS_REP).

  • TheĀ session key, encrypted withĀ pixisĀ hashed password;

  • TheĀ TGT, containing various information like:

    • Username (pixis)
    • Validity period
    • Generated session key
    • TheĀ Privilege Attribute CertificateĀ (PAC) which contains a lot of specific information about the user, including his identifier (SID) and all the groups he is member of.

    TGT will be encrypted with the KDC key. Thus,Ā only the KDC is able to decipher and read this ticketā€™s content.

The client receives these pieces of information. Using his hashed password, the first part will be decrypted in order to retrieve the session key that will be necessary for further exchanges.

Ticket-Granting Service (TGS)

Now the user has his own key as well as a time-limited session key that only he currently knows, and a KDC-encrypted TGT that contains, among other things, this same session key.

KRB_TGS_REQ

WhenĀ pixisĀ wants to use a service, e.g.Ā CIFSĀ onĀ SERVER01, it will send several pieces of information to the KDC so that the KDC can send back a Service Ticket:

  • The TGT;
  • The service he wants to use and the associated host, soĀ CIFS/SERV01Ā in this example;
  • AnĀ authenticator, which contains his username and current timestamp, all encrypted with the session key.

Now the Key Distribution Center (KDC) will compare TGT and authenticator contents. Since only the KDC can read TGT content, it could not have been tampered with. The KDC will read TGT content, including the TGTā€™s owner and the associated session key. Then it will decrypt authenticator content with the same session key. If the decryption works, and the data in the authenticator matches the data in the TGT, then pixis is who it claims to be. The KDC is assured that whoever made the request has the TGT and knowledge of the negotiated session key.

KRB_TGS_REP

Now that the KDC has been able to verify that the user isĀ pixis, it will respond to Ā pixis with the KRB_TGS_REP containing:

  • The Ticket Granting Service (TGS) containing:
    • The name and host of the requested service (CIFS/SERV01)
    • An encrypted part (encrypted with the serviceā€™s key (i.e. the host key, since CIFS service runs under the host account);) with:
      • userā€™s username (pixis)
      • the PAC,
      • and a new session key which is only valid for communications betweenĀ pixisĀ andĀ SERVER01Ā for a certain period of time.
  • A new session key

These two pieces of information (the ticket and the session key) are encrypted with the first session key, the one that was initially exchanged between the KDC and the client.

The client will receive this message, and will be able to decrypt the first layer to get the session key created for communication with the service, as well as the Ticket Granting Service (TGS) generated to use this service.

Application Request (AP)

KRB_AP_REQ

Now when the client wants to use the service, he will generate a new authenticator with this new session key.

service receives the TGS and can decrypt it with its own secret.

Summary

Last update: 2025-01-19
Created: December 27, 2024 22:00:41