Kerberos Authentication Technology Simplified.

Kerberos is the native authentication protocol in Microsoft Active Directory, which works on the basis of tickets to allow clients communicating over the network to prove their identity to one another in a secure manner. Kerberos protocol is designed to protect messages against eavesdropping and replay attacks.

Kerberos authentication protocol is built on symmetric key cryptography which uses same keys for both encryption and decryption.  Kerberos authentication requires a trusted third party (an Active Directory server) during certain phases of authentication. By default Kerberos uses TCP port 88 for communication.

As mentioned earlier, Kerberos authentication will have 3 parties client (user), resource (File Server) and a trusted third party (Active Directory). Key distribution Server in Active Directory network is its Domain Controller.

Three parties required for Kerberos authentication

Three parties required for Kerberos authentication

In Kerberos, the Key Distribution Center (KDC) does not communicate directly with the resource server. Due to this reason majority of the processing burden in authentication is handled by the client.

The authentication process kicks off once the client attempts to logo on to the network. The client creates a small package called an authenticator, with information including the date and time so that it can track the authenticity and eliminate any hacker attempt to replay on the network.

Client creates authenticator and encrypt using user password

Client creates authenticator and encrypt using user password

Authenticator package is encrypted using user password and it also has a small portion unencrypted where the user name and source address information are stored. The username in the unencrypted portion of authenticator package allows the KDC or Domain Controller to identify who is trying to authenticate.

Using the user password (which is only known to the user) as an encryption key emphasize the fact that Kerberos does not transmit password in plain text.

Client sends the authenticator package to Domain Controller

Client sends the authenticator package to Domain Controller

When the authenticator package is sent off to the Domain Controller, it identifies the user name and looks up the Active Directory database to pick the user password.  The Domain Controller then uses the user password stored in the Active Directory to decrypt the authenticator.  If the Domain Controller could not decrypt the authenticator, the logon attempt is denied. If the Domain Controller can successfully decrypt the authenticator, it identifies that the user is the same user who claims who they are because the secret password is correct

Domain Controller issues Ticket Granting Ticket, encrypt using its private key

Domain Controller issues Ticket Granting Ticket, encrypt using its private key

At this point, since the user is authenticated to the Active Directory, it does not require authenticator package anymore so it is simply discarded.  In order to avoid the user to authenticate every time the user communicate to the Domain Controller, it issues a Ticket Granting Ticket (TGT) which contains all the information the Domain Controller has related to the authenticated user and encrypt it using a key that only the Active Directory knows.

Client receives Ticket Granting Ticket from Domain Controller and place it to Kerberos Tray

Client receives Ticket Granting Ticket from Domain Controller and place it to Kerberos Tray

Domain Controller transmits the TGT to the client (user machine) and that will be stored in a special memory area called “Kerberos Tray”. Since the Kerberos tray always lives in the memory which cannot be swapped out to the disk, whenever the client machine crashes or powered off, you need to authenticate again.

Client sends a copy of Ticket Granting Ticket to Domain Controller along with File Server access request

Client sends a copy of Ticket Granting Ticket to Domain Controller along with File Server access request

Once authenticated to the network, whenever the user want to get some information from a file server, the client system looks for its ticket in the Kerberos try. If it does not find any valid ticket for file servers in the kerbros tray, it must go back to the KDC to get a valid key for the file server. For that purpose, instead of going through the whole authentication process again, the client system simply sends the TGT back to the KDC along with a request to access the File server.

The KDC (Domain Controller) does not have to verify the user information, instead it just decrypts the TGT and verifies that it is the same ticket which was encrypted using its own secret key. By default the TGT has a life period of eight hours, periodically they have to be destroyed and renewed so that Active Directory can revalidate the user identity.

Domain Controller generates ticket and encrypt using File Server’s logon password and sends to the client.

Domain Controller generates ticket and encrypt using File Server’s logon password and sends to the client.

Domain Controller now generates a new ticket and encrypt using the file server’s logon password stored in the Active Directory database and then send to the requested client which later stores it to the Kerberos tray.

Client sends the access ticket to File Server and Files Server decrypts the ticket using its logon password.

Client sends the access ticket to File Server and Files Server decrypts the ticket using its logon password.

For the next eight hours when the client wants to access file server, it just sends a copy of the ticket to file server. The file server tries to decrypt the ticket with its logon password, if it is able to successfully decrypt the ticket, then that ticket must be issued by the KDC because that is the only one has the file server’s login password known.

By decrypting the ticket using own logon password, the file server understands that this is a legitimate ticket. The file server then opens the ticket which has the client’s username, group membership etc, and it uses that information to provide access to the resources within the file server.

Every time the client wants to access the resource from file server, it has to submit a valid ticket along with the request. The file server does not store any client authentication tickets in its memory because it has to serve thousands of user request simultaneously.

Now let us do some practical test.

You can use klist command to display the content of Kerberos tray within the client system. Below TechNet link will provide more details of the parameters can be used along with the klist command. http://technet.microsoft.com/en-us/library/hh134826.aspx

In order to lookup the Kerberos tray in your client system, go to command prompt and type klist.

List of current Kerberos tickets in the system

List of current Kerberos tickets in the system

The klist command will displays the list of currently cached Kerberos tickets in the system. Notice that the Kerberos tray currently has only TGT ticket. The listing will show you the details of the Client name, Service name, encryption type that is used to encrypt the Kerberos ticket, time stamp etc.

Client accessing file share

Client accessing file share

Go to the command prompt and try to access file share on a file server (I have a folder shared on my database server in my lab). Once the file share is connected, rerun the klist command.

List of Kerberos tickets in the Kerberos tray while accessing file server

List of Kerberos tickets in the Kerberos tray while accessing file server

Notice that the command now lists one additional ticket which is belongs to the file server (in our case the database server ACME-DB1.ACME.COM).

Advertisements

About Jayachandran PK
My passion is for Microsoft technologies and how if properly implemented, they can provide actual value for an organization especially in the field of infrastructure, virtualization and system monitoring. I work for the biggest Microsoft partner in Kuwait, specialized in project consultation and implementation services for enterprise clients. When I'm not at work, I try to contribute back through a charitable organization dedicated to prompting cultural values of Kerala. In my free time, I dabble in gardening and am also an avid solar power aficionado.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: