Kerberos is an authentication technology, if you’ve used Microsoft Windows and Active Directory (AD) you will have heard of Kerberos as its the authentication method used to secure an AD Domain and any hosts and devices that are joined to it.
I’d like to provide a fairly high-level run through of how Kerberos works, so you can understand the individual parts and processes that are involved in authenticating a user to a service, you can find really detailed explanation elsewhere, however here I’m just trying to give enough of an overview for you to understand where to start from a troubleshooting perspective, or to assist in an exam like the CISSP.
Overview of Key Parts
Key Distribution Centre (KDC) – The authentication server is actually three parts, the Authentication Server (AS), the Ticket Granting Server (TGS) and a Database (in Active Directory this is the Active Directory database based on a JET database), when you interact with the KDC you’re actually interacting with either the AS or TGS that use the Database to verify user credentials.
Authentication Server (AS) – The AS performs the authentication of a user (subject) who is wanting access to a domain resource (e.g. a file on a file server), if the authentication is successful the client is given a TGT (Ticket Granting Ticket).
Ticket Granting Server (TGS) – The TGS issues Service Tickets (a.k.a TGS Tickets) to successfully authenticated users requiring access to a network resource.
Client – The client is the client workstation from which the user (subject/principal) is making their request for access to a network resource from.
Server (Resource Server) – The server that holds the network resource the user is trying access.
Principal – A subject, i.e. a user or service (program) accessing the network resource.
High-Level Overview of the Process
A very high-level of the authentication process is shown below, yes its very high level, and I’ll go into detail in the subsequent sections of each of these; but let’s just start with the scenario that a user on a Microsoft Windows workstation wishes to access a file on a shared drive on a Microsoft Windows Server, both of which are joined to a Microsoft Active Directory domain.
- Access the network resource, provide authentication credentials.
- Obtain a TGT (Ticket Granting Ticket).
- Obtain a TGS (Ticket Granting Service Ticket).
- Granted access and use of the network resource.
Authentication Process
So in our example a user “Bob” on the client CLIENT01 is wanting to access a shared folder “finance” on the server FILESERVER1.
Step 1 – The client wants to access a resource, let’s say a file server on the network (domain), so it first makes a request to the Domain Controller (Key Distribution Centre), where it creates a packet called an “Authenticator”, this has two parts:
1. A plain text part containing username, current date and time etc.
2. an encrypted part which has been encrypted using the user’s password (i.e. a hash), notice this means that the password is not sent across the network.
Note the time is critical here, the KDC will not accept an Authenticator if the time/date within is not within about 5 minutes of that of the KDCs current time/date.
Step 2 – The Authenticator is sent to the DC (KDC) specifically the Authentication Service (AS), the DC (KDC) has a record of what the user’s password is, as it knows who the Authenticator is from as it read this in the plain text part of the message. The Authentication Service (that resides on the KDC) then attempts to decrypt the encrypted part of the Authenticator using the user’s password (that it knows of course). If the decryption fails, the request is thrown away and access is denied. If however it is correct the DC (KDC) can assume the requestor is who they say they are. The Authenticator message can then be destroyed as it has served its purpose.
Step 3 – Now the DC (KDC), specifically the Authentication Service (AS), is happy that the person is who they say they are, it issues a Ticket Granting Ticket (TGT), and encrypts a portion of this TGT with its own key, i.e. the KDC’s key; it then transmits this to the client who stores this TGT in its Kerberos Tray; which is a portion of memory on the client (never swapped to disk) for storing the TGT. The TGT typically lives for 8 hours (by default) after that time, steps 1, 2 and 3 are repeated to create a new TGT to continue to allow the user to have access to the domain.
Be aware that the user can decrypt this TGT because its been encrypted with its own secret key (i.e. its password).
Step 4 – Right, now the client is ready to start the authentication process to the resource (in this case the file server), so it checks in its Kerberos Tray for a ticket to allow it to connect to resource (in this case the file server), however one does not exist yet, so it then needs to make a request to the TGS (Ticket Granting Service) which also resides on the KDC.
Step 5 – The client makes a request to the KDC specifically the Ticket Granting Service (TGS) for a ticket by sending the Ticket Granting Ticket (TGT) along with a request to the resource on the network (e.g. the file server) it wants to access. When the KDC gets this request it checks the TGT is valid by attempting to decrypt it with its own key (which it used to encrypt it on step 3), if it is able to be decrypted successfully, the KDC can be happy the user is who they say they are, as they wouldn’t have a valid TGT if they were not already a trusted user.
Step 6 – The Ticket Granting Service (TGS) on the KDC, can then generate a service ticket to the required resource (i.e. the file server), it creates a service ticket and encrypts it using the password of the resource (in this case the file server), it can do this because the file server is joined to the domain and therefore the Domain Controller (KDC) has a copy of it’s (the server’s) password.
Step 7 – The service ticket (which has been encrypted with the file server’s password) is then returned to the client. The client puts the service ticket (for the file server resource) in its Kerberos tray, now for the next 8 hours (or however long the service ticket is valid for) the client need only present this service ticket when it attempts a connection to be authenticated to the particular network resource.
Step 8 – We’re nearly done. Now the client has a valid service ticket to the file server resource, it makes a connection to the file server, it presents the service ticket it got (from the KDC) to the file server. The file server has no knowledge of the user up to this point, so when it gets the ticket from the client, it attempts to decrypt the service ticket with its own key (password), if it can’t be decrypted, the service ticket is bad the request is rejected. However if the service ticket can be decrypted, the file server can be happy that the request is safe because only the Domain Controller (KDC) knows its password (key) so it must have been that which authenticated the user and created the valid service ticket for its resources.
Step 9 – The file server (resource) now uses the service ticket and retrieves the user’s details, group membership etc. and decides what access that particular user can access on the file server resources. Note at this point there is no communication from the file server (resource) to the Domain Controller (KDC), there does not need to be, as the client has presented a service ticket which could only have been generated (and be trusted and valid) if it came from the Domain Controller (KDC). Of course at this point the client can then access the resources on the file server that the user is allowed to see, and can continue to do so for the lifetime of the ticket at the end of which another is generated (using this process) and access continues.
Possible Attacks
There are a few different types of attack, “Overpass the Hash”, “Pass the Ticket”, “Silver and Golden Ticket” amongst others, But one that I found quite interesting is the ASREPRoast attack.
The ASREPRoast attack specifically targets the weakness if Kerberos pre-authentication is not in use. An attacker can send an authentication request to the KDC as their target user, the KDC will reply with a ticket-granting-ticket (TGT) which has been encrypted with the client’s password as the key.
Now the attacker essentially has a ticket which has been encrypted with the client’s password (as the key), so they basically have the ciphertext as it were and can use this with a brute-force ciphertext only attack which depending on the strength of the user’s password may allow it to be cracked and used to gain access.
Kerbroasting is where the attacker scans AD for user accounts or service accounts with a SPN set, when it finds one they attempt to login, as a challenge the KDC responds with the challenge that is encrypted with the NTLM hash of the password. Then on your machine you dump this ticket to disk, then using a password cracker offline you brute force this hashed ticket, when you find the hash that matches the password, you then know what the actual password is – by inferring it because the hashes match.
Conclusion
Hopefully that gives you a good high-level overview of the process, as you can see its fairly complicated, but if you break it down into the two parts, getting the TGT and then getting the TGS it makes it much easier to understand.
Also bear in mind that in logging on you get one TGT, that you can just keep passing back to obtain TGS tickets for all of the network resources you want to access, ergo you logon and get a TGT, then you don’t need to get another TGT (until it expires) and can use that TGT to get as many TGS as you need for the network resources to which you need access.
Destination Certifications explanation is very much more detailed and certainly worth a look.
Additional Links
https://dev-2null.github.io/Kerberoasting-AES-Encryption-Protected-Users-Group-and-gMSA/
