The Kerberos Authentication Process in Windows Environments
Kerberoasting, Silver Tickets, Golden Tickets, Pass-the-Ticket, gMSAs, Kerberos Armoring… have you ever wondered what all of this stuff is about? To really understand it, we need to focus on the Kerberos authentication process and how it is implemented in Windows.
In this article, we’ll discuss what Kerberos is, why it is essential for Windows to function, and how it works – not just in theory, but also in practice.
The Kerberos Protocol
Early versions of Windows, pre Windows 2000 to be exact, used NTLM as the primary authentication protocol. However, NTLM has several security weaknesses, including vulnerabilities to relay attacks, replay attacks, pass-the-hash and more.
To attack these problems, Microsoft adopted Kerberos as the default authentication method, starting with Windows 2000 Active Directory environments and continuing ever since. It introduced several important security features, including Encryption in Transit, Mutual Authentication, SSO and replay protection.
Additionally, with Windows 11 and Windows Server 2025, Microsoft is beginning to phase out and eventually eliminate NTLM completely. So theres no better time to learn about Kerberos then now. While Kerberos can be explained at a surface level, the protocol goes much deeper than that. For the purposes of this article, I’ll keep the technical aspects semi-basic but also focus on how to track Kerberos authentication within a Windows environment.
Participants of the Kerberos Protocol
The Client
A User / Host requesting a Ticket and using it to access services of other machines remotely. For example: A User request an Ticket for accessing the SMB Fileshare on “Server01”.
KDC – Key Distribution Center
The Key Distribution Center (KDC), integrated in the Domain Controller, is responsible for validating authentication requests and issuing tickets. The KDC Key Roles are the Authentication Service (AS) and the Ticket Granting Service (TGS).
The Service Server
The server that hosts the service the user wants to access, for example a SMB file share on “Server01”. Each service within the domain must have a unique SPN (Service Principal Name) to support Kerberos authentication.
SPN (Service Principal Name)
The SPN is a unique Identifier, consisting of the Service that is offered and the hostname of the machine. SPNs are automatically created and stored in Active Directory, and they are publicly accessible to any authenticated user within the domain.
Example for a SPN of a SMB Fileshare running on “Server01”:
cifs/Server01.domain.com – “serviceclass/hostname”
The Service Account
Every service relies on an associated Service Account to run. This account provides the necessary identity and permissions for the service to operate. The Service Account can either be a local machine / user account, e.g. “Local System” – or a domain user used as service account, e.g. “ServiceAccountSMB”.
The Kerberos Authentication Process
The Authentication Process of Kerberos consists of three main steps.
1. The Client / Authentication Service (AS) Exchange
In the first step, the client authenticates to the Authentication Service (AS) of the KDC to receive it’s TGT (Ticket Granting Ticket).
The message types included in this exchange are KRB_AS_REQ & KRB_AS_REP.
2. The Client / Ticket Granting Service (TGS) Exchange
In the second step, the client presents the TGT and the SPN of the Service it wants to access to the TGS Service of the KDC. By doing so, it receives its TGS Tickets.
The message types included in this exchange are KRB_TGS_REQ & KRB_TGS_REP.
3. The Client / Service Server Exchange
Last, the client presents it’s TGS Ticket to the Service Server it wants to access. If successful, the client can access it’s desired Service.
The message types included in this exchange are KRB_AP_REQ & KRB_AP_REP.
We’re going to go through all exchanges and their message types, one by one.
1. The Client / Authentication Service (AS) Exchange
(1) KRB_AS_REQ
A client requests authentication at the Authentication Service (AS) of the Key Distribution Center (KDC), e.g. by logging into a domain computer. This request is send in plaintext over the network, containing no crucial information.
(2) KRB_AS_REP
The KDC checks if the client and its according Client Secret Key exists in its Database (Active Directory). In Windows Environments, the Client Secret Key is the hash of the Clients Password.
After validating all informations, the AS first generates the TGS Session Key as well as the Ticket Granting Ticket (TGT-Ticket), combines them into “Message 1” and encrypts it using the TGS Secret Key. In Windows environments, the TGS secret key is the hash of the KRBTGT account password.
It also creates “Message 2”, also containing the TGS Session key, but encrypted with the Client Secret Key. Only the Clients password can decrypt messages encrypted with the according Client Secret Key. Both Messages are then send to the client.
The Client then decrypts “Message 2”, containing the TGS Session Key, using its password. It cannot decrypt “Message 1”, containing the TGT, since it is encrypted with a key the Client doesn’t know about – the TGS Secret Key.
In conclusion, the following things happened:
Encryption in Transit
All crucial information was encrypted, making it impossible for a third party to read information out of the exchange, e.g. by network sniffing.
Mutual Authentication
Only the Authentication Service could have encrypted “Message 2” by using the Clients Secret Key, so the Client knows that the Authentication Service is who it pretends to be.
Only the Client could have decrypted “Message 2” by using its password, so the Authentication Service knows that the Client is who it pretends to be.
Key Exchange
While ensuring Confidentiality, the TGS Session Key has been exchanged. This is important for the next step – The Client / Ticket Granting Service (TGS) Exchange
SSO (Single Sign On)
With the now acquired TGT, the Client can request access to services within the domain without the need of reauthenticating every time.
2. The Client / Ticket Granting Service (TGS) Exchange
(3) KRB_TGS_REQ
The client creates an “Authenticator”, containing of a timestamp and the User ID, and then encrypts this Authenticator with the TGS Session Key. Next, it sends a request to the TGS (Ticket Granting Service), including the Authenticator, the still encrypted “Message 1” containing the TGT and the TGS Session Key, as well as the Service Principal Name (SPN) of the target service as plaintext.
(4) KRB_TGS_REP
First, the TGS checks if the SPN exists in it Active Directory and grabs a copy of its Service Secret Key. In Windows Environments, the Service Secret Key is the hash of the associated Service Accounts password.
Second, it uses the TGS Secret Key (KRBTGT Hash) to decrypt the “Message 1” sent by the Client. If successful, it uses the TGS Session Key to decrypt the Authenticator sent by the Client and validates the TGT.
After validating all informations, the TGS first generates the Service Session Key as well as the Service Ticket (TGS-Ticket), combines them into “Message 3” and encrypts it using the Service Secret Key.
It also creates “Message 4”, also containing the Service Session Key, but encrypted with the TGS Session Key. Last, it sends both messages back to the client.
The Client then decrypts the message containing the Service Session Key using the TGS Session Key. It cannot decrypt the Service-Ticket, since it’s encrypted with a key the Client doesn’t know about – the Service Secret Key (Hash of the Service Account).
Again in conclusion, the following things happened:
Encryption in Transit
All crucial information was encrypted, making it impossible for a third party to read information out of the exchange, e.g. by network sniffing.
Mutual Authentication
Only the Client could have encrypted the Authenticator with the TGS Session Key, so the Ticket Granting Service knows that the Client is who it pretends to be.
Only the Ticket Granting Service could have decrypted “Message 1” by using the TGS Secret Key, so the Client knows that the Ticket Granting Service is who it pretends to be.
Key Exchange
While ensuring Confidentiality, the Service Session Key has been exchanged. This is important for the next step – The Client / Service Server (CS) Exchange
3. The Client / Service Server Exchange
(5) KRB_AP_REQ
The client creates another Authenticator, containing of a timestamp and the User ID, and then encrypts this Authenticator with the Service Session Key. Next, it sends a request to the Service Server, including the Authenticator and the still encrypted “Message 3” containing the Service Ticket and the Service Session Key.
(6) KRB_AP_REP
The service uses the Service Secret Key (Hash of the Service Account) to decrypt the “Message 3”, containing the Service Session Key and Service Ticket, sent by the Client. If successful, it uses the Service Session Key to decrypt the Authenticator sent by the Client and validates the Service Ticket.
At this point, the service knows that the client is who it claims to be and decides whether access should be granted – typically by checking ACLs, group memberships, or claims. You may have noticed this means that any authenticated user can request a Service Ticket for a service, even if they’re not allowed to access it. While this doesn’t mean users can actually access all services, it does expose a significant design flaw in the Kerberos protocol, which can be exploited through an attack technique known as Kerberoasting – a topic we’ll cover another time. 🙂
If the user is granted access, the Service creates an Authenticator itself, containing of the SPN and a Timestamp, encrypts it using the Service Session Key and sends it back to the user. Last, the user decrypts the Authenticator, validates it and is now able to access the Service.
Last conclusion, the following things happened:
Encryption in Transit
All crucial information was encrypted, making it impossible for a third party to read information out of the exchange, e.g. by network sniffing.
Mutual Authentication
Only the Client could have encrypted the Authenticator with the Service Session Key, so the Service Host knows that the Client is who it pretends to be.
Only the Service Host could have decrypted “Message 3” by using the Service Secret Key, so the Client knows that the Service Host is who it pretends to be. Also, the Service Host sent an additional Authenticator to the Client.
Service Access
The Client was enabled to access its desired service.
Kerberos in Practice
Now, to follow this process inside of an windows domain environment, lets start by logging into a domain-joined client with a domain user. This will trigger the Client / Authentication Service (AS) Exchange and, if successfull, give us our TGT!
To verify if we got the TGT, we can open cmd as administrator and enter “klist”. This will give us a overview over all issued Kerberos Tickets of the user.
The TGT in this example was issued for the user “user@domain.local” by the KDC “TESTDC” – the Domain Controller of this Domain. It uses AES-256 encryption, is forwardable, renewable, and valid from 6/23/2025 10:16:21 to 6/23/2025 20:16:21, with a renewal deadline of 6/30/2025.
The KRBTGT user that was used for the encryption of this ticket can be found in AD
Next, we’re going to use our TGT to receive the Service Ticket for accessing a SMB Share. Since all of this happens in the backround, all we need to do is open an SMB connection to the share via its Hostname (Since Kerberos doesn’t work via IPs by default).
After executing “klist” again, we can see the Service Ticket for our SMB Connection, yay!
To look for the SPN that has been used for this request, we can lookup all SPN’s associated with the “TESTDC” machine (Fileserver) by queing this command:
setspn -l testdc
}
Which gives us the following output:
We can also check which service account was used for the “Client / Service Server Exchange” by queuing this powershell command on our domain controller:
Get-ADObject -Filter { ServicePrincipalName -eq "host/testdc.domain.local" } -Properties ServicePrincipalName | Select-Object Name, DistinguishedName}
The output shows us that the Computer Account “TESTDC” is set as service account.
Optionally we could check the Service Account directly as the Service Server via “Services.msc” > “Log On As”
And that’s about all I have to say for now! Thanks for reading. Stay tuned for future articles about attacks on Kerberos, and follow me on LinkedIn to never miss a new post from me. 🙂
