Kerberos Authentication
Brief summary of how Kerberos Authentication works.
Last updated
Was this helpful?
Brief summary of how Kerberos Authentication works.
Last updated
Was this helpful?
Kerberos authentication protocol is the primary authentication used in Active Directory. It provides information about the privileges of each user but does not determine if the user has access to a service's resources
Unlike NTLM Authentication, Kerberos authentication uses a ticket system.
At a high level, Kerberos uses a Domain Controller in the role of a Key Distribution Center (KDC).
There are 6 main steps involved:
Authentication Server Request
Authentication Server Reply
Ticket Granting Service Request
Ticket Granting Server Reply
Application/Service Request
Service Authentication
For example, when a user logs in to their workstation, a request will be sent to the domain controller (DC), which has the role of a key distribution center (KDC) and also maintains the Authentication Server service. The user will send an Authentication Server Request (AS_REQ) to the KDC. The ASREQ contains a timestamp that is encrypted using a hash derived from the password of the user and the username.
When the KDC receives the request, it will look up the password hash associated with the username and decrypt the timestamp. If the decryption process is successful and the timestamp is not a duplicate, the authentication will be successful.
The KDC will then reply to the client with Authentication Server Reply (AS_REP) that contains a session key and a Ticket Granting Ticket (TGT). The session key is encrypted by the user's password hash and may be decrypted by the client and reused.
The TGT contains information regarding the user, including group memberships (PAC), the domain, a timestamp, the IP address of the user, and the session key.
The PAC (Privilege Attribute Certificate) is an structure included in almost every ticket. This structure contains the privileges of the user and it is signed with the KDC key.
The TGT is then encrypted by a secret key which is known only to the KDC and cannot be decrypted by the client.
Once the user receives the session key and the TGT, the KDC will consider the client authentication complete.
This TGT will be valid by default for 10 hours, after which a renewal occurs. If the user wishes to access resources of the domain, such as a network share, Exchange mailbox, or some other application with a registered service principal name, it must contact the KDC again.
Now, the user will construct a Ticket Granting Service Request (TGS_REQ) packet that consists of the current user, a timestamp that is encrypted using the session key, the SPN (Service Principal Name / Unique Identifier for the service ) of the resource, and the encrypted TGT.
Next, the ticket granting service on the KDC receives the TGS_REQ and if the SPN exists in the domain, the TGT will be 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.
Here the KDC will check the following:
TGT must have a valid timestamp
Username from the TGS_REQ has to match the username from the TGT
Client IP address must coincide with the TGT IP address
Once the verification is done, the ticket granting service on the KDC will respond to the client with a Ticket Granting Server Reply (TGS_REP) which contains the following:
Service to which access has been granted
Session key to be used between client and service
Service ticket containing username and group memberships along with the newly created session key.
The first 2 are encrypted using the session key associated with the creation of the TGT and the service ticket is encrypted with the password hash of the service account registered with the SPN.
Once the authentication is done, the user would have both a session key and a service ticket. From here, service authentication would begin.
First, the user sends to the application server an Application Request (AP_REQ). This includes the username and timestamp encrypted with the session key and the service ticket itself.
The application server then decrypts the service ticket using the service account password hash and extracts the username and session key.
It will then use this extracted session key to decrypt to 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.
