The Domain Controller (DC) is responsible for security authentication requests within a network domain and controlling access to domain resources. It authenticates users, stores user account information and enforces security policy for a domain. The DC host can achieve this using Microsoft's Active Directory (AD) or an identity management software such as and FreeIPA. Both are more than capable to act as the centerpiece in a kerberized network environment.
There are two main implementations of the Kerberos authentication protocol, AD and MIT Kerberos.
Kerberos provides a means of verifying the identities of principals, which is a workstation user or a network server, on an untrusted network by relying on a trusted third party, the Key Distribution Center (KDC). The KDC itself consists of two main components, the Authentication Server (AS) and the Ticket-Granting Server (TGS). The set of services in which the KDC has the authority to authenticate a user make up the Kerberos Realm.
The Kerberos authentication uses a shared secret symmetric-based encryption key which is known only to two entities, the KDC and the client. How the secret is made known or stored to the client or the KDC in not part of the protocol. In the simplest case an admin enters it manually.
The protocol in its entirety is designed such that the KDC and the Service never communicates directly. This is achieved trough a ticket-based authentication with two types of tickets.
Ticket Granting Ticket (TGT) is issued by the AS and is used to authenticate the user towards the TGS.
Service Ticket is issued by the TGS and used to authenticate the user towards services.
In order to receive these tickets, different sub-protocols or exchanges are used. In order the access the service, there are therefore three entities the user needs to interact with, the AS, TGS and the service itself. When interacting with the AS and TGS, the client receives two encrypted messages, of which only one can be decrypted using the shared secret.
Finally, Kerberos is time-sensitive since the tickets include timestamps. This means that all hosts in the Kerberos Realm needs to be time-synchronized through, for example, an NTP service.
Kerberos consists of several sub-protocols/exchanges which are defined below.
Pre-requisite: The KDC must have a shared secret with the Client and another secret shared with the Service. How the Secrets are generated or distributed is out of scope.
The Client sends one message in plaintext to the AS with
The AS checks if the user exists in the KDC DB. If the user exists, the exchange continues.
The AS creates a random-generated
The AS replies with two messages, the TGT encrypted with the
TGS-Secret and another message (A) encrypted with the
TGS-Session is included in both.
The Client receives the encrypted TGT and encrypted message (A) and decrypts (A) with its
Client-Secret to get the
TGS-Session. The encrypted TGT is stored in the Client's keytab.
The Client send three messages to the TGS, one message called authenticator which is encypted with the
TGS-Session, a plaintext message with
Service-ID and the encrypted TGT.
The TGS checks if the Service exists in the KDC DB. If the service exists, the exchange continues.
The TGS decrypts the encrypted TGT and gets the
TGS-Session and uses it to decrypt the encrypted autenticator message
The TGS performs a series of checks. If all checks passes, the exchange continues.
The TGS checks if the TGT has expired using the
The TGS compares the
Client-ID and the
timestamp in the TGT and authenticator message, the first should be identical and the second should be within the configured time-tolerence (~2 mins)
The TGS checks if the authenticator with the corresponding
timestamp already exists in the KDC-cache which would indicate a replay-attack
The TGS generates a random-generated
The TGS replies with two messages, one message (B) that is encrypted with the
TGS-Session and the Service Ticket which is encrypted with
Service-Session key is included in both.
The Client receives the encrypted message (B) and the encrypted Service Ticket and decrypts (B) with the
TGS-Session to get the
Service-Session. The encrypted Service Ticket is stored in the Client's keytab.
The Client sends two messages to the Service, one message called authenticator which is encrypted with the
Service-Session and the encrypted Service Ticket.
The Service decrypts the Service Ticket with its
Service-Secret and gets
Service-Session which it uses to decrypt the authenticator.
The Service performs a series of checks in a similar manner as the TGS:
The Service checks if the Service Ticket has expired using the
The Service compares the
Client-ID and the
timestamp in the Service Ticket and authenticator message, the first should be identical and the second should be within the configured time-tolerence (~2 mins)
The Service checks if the authenticator with the corresponding
timestamp already exists in the Service-cache which would indicate a replay-attack
The Service stores the
Service-Session locally and associates it with the Client.
The Service replies with one message called authenticator which is encrypted with
The Client receives the autenticator and decrypts it with the
Service-Session in order to verify the identity of the Service.
The Client and the Service are now authenticated against each other and shares the
Service-Session key which will be used together with the Service Ticket in future requests.