How Kerberos Works

how kerberos works

Kerberos is a computer network authentication protocol that was developed by MIT. An open source, free implementation is available from MIT as well as commercial implementations from other vendors. Kerberos is the native authentication protocol in Active Directory.

Here is how the protocol works:

how kerberos works

In Kerberos, there is no communication between the resource (server) and the KDC. Client takes on the majority of the processing burden in Kerberos, which distributes the authentication workload across the network.

1- Client attempts to log on to the network

Client constructs and authenticator. This includes day and time data, so the authenticators are valid for only a certain period of time. So, they can’t be captured and re-used by an attacker. Some portion of the authenticator is un-encrypted (like who the client is) and some portion of it is encrypted using the client’s key. Kerberos does not transmit your password(key) across the network, password is used as shared secret.

2- KDC receives the authenticator from the client. It tries to decrypt the authenticator with the password it has (KDC has) for that user. If it can’t decrypt the authenticator this means this user (client) is not who they say they are. If it can be decrypted this means the user is who he claims to be and has the correct password.

3- KDC creates a TGT (Ticket Granting Ticket) for the client. This TGT includes the user information and is encrypted by KDC’s own key that only KDC knows about. This TGT is transmitted back to the client and saved on the client machine inside Kerberos Tray. This area is always in the memory and can’t be swapped out to the disk which means If the client computer crashes, this information will be lost. Now the client is logged on and ready to go.

4- Now client computer looks at the Kerberos Tray and sees there is no ticket for the server (resource). Now client sends the TGT back to the KDC and says “I need a ticket for the server”. KDC uses his key to decrypt the TGT. If it can be decrypted then KDC know that this information was generated by him previously. TGTs are generally valid for 8 hours so that KDC will get to re-validate the users but this doesn’t happen every time to save effort. Since KDC was able to decrypt the TGT, now it generates a ticket for the client. This ticket is generated by the server’s key (the resource that client is trying to access) and sent to the client. This ticket is also stored in Kerberos Tray.

5- Now, anytime the client needs to access the server, a copy of this ticket is sent to the server. Server tries to decrypt this ticket with his own key. If it can be decrypted then server knows that this information was generated by the KDC because it is the only other node that knows about server’s password which means this is a legitimate ticket. Once the server decrypts the user information (username, roles, groups etc.) he decides which content client can access. This tickets are not stored in server’s memory. Every time client needs access, he needs to re-send this ticket to the server. Considering how many users the server could be serving to, it makes sense not to store all this ticked data in server’s memory.


Hope this helps.
Good Luck,