Comment on page
Kerberos Authentication Protocol
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.
Integrated Windows Authentication (link) supports two authentication protocols, Kerberos and NTLM where Kerberos is vastly superior in terms of security. While Kerberos usually preferred, NTLM can still be used as a fallback. Some services, in particular legacy systems, may support Windows Authentication but only with NTLM.
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 AD domains (and thus 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.
- Down-Level Logon Name: DOMAIN\UserName
- User Principal Name (UPN):
The secret is determined by
hash(username+password)where the username acts as a salt. Services use generated keys as passwords which are stored on the host instead of a password which would require a user-interaction to enter it.
Kerberos consists of several sub-protocols/exchanges which are defined below.
The KDC must have three shared secrets setup before the exchange starts:
- A secret shared between KDC and the Client (
- A secret shared between KDC and the Service (
- A secret shared internally between KDC/AS and KDC/TGS (
The secrets are used for symmetric encryption. How the secrets are generated or distributed is out of scope.
Purpose: Clients gets a
TGS-Session(before the TGS) and an encrypted TGT Client and can now start the authentication against the KDC/TGS.
- 1.The Client sends one message in plaintext to the KDC/AS with
- 2.The KDC/AS checks if the user exists in the KDC DB. If the user exists, the exchange continues.
- 3.The KDC/AS creates a random-generated
- 4.The KDC/AS replies with two messages. The
TGS-Sessionis included in both.
- 1.Message (A) which is encrypted with the
- 2.Message (B) which is the TGT, encrypted with the
- 5.The Client decrypts (A) with its
Client-Secretto get the
TGS-Session. The encrypted TGT (B) is stored in the Client's keytab.
Purpose: Client gets a
Service-Session(before the Service) and an encrypted Service Ticket and can now start the authentication against the Service.
- 1.The Client send three messages to the KDC/TGS, one message called authenticator which is encypted with the
TGS-Session, a plaintext message with
Service-IDand the encrypted TGT.
- 2.The KDC/TGS checks if the Service exists in the KDC DB. If the service exists, the exchange continues.
- 3.The KDC/TGS decrypts the encrypted TGT and gets the
TGS-Sessionand uses it to decrypt the encrypted autenticator message
- 4.The KDC/TGS performs a series of checks. If all checks passes, the exchange continues.
- 1.The KDC/TGS checks if the TGT has expired using the
- 2.The KDC/TGS compares the
timestampin the TGT and authenticator message, the first should be identical and the second should be within the configured time-tolerence (~2 mins)
- 3.The KDC/TGS checks if the authenticator with the corresponding
timestampalready exists in the KDC-cache which would indicate a replay-attack
- 5.The KDC/TGS generates a random-generated
- 6.The KDC/TGS replies with two messages. The
Service-Sessionkey is included in both.
- 1.Message (C) which is encrypted with the
- 2.Message (D): The Service Ticket, encrypted with
- 7.The Client decrypts (C) with the
TGS-Session(from the KDC/AS exchange) and gets the
Service-Session. The encrypted Service Ticket is stored in the Client's keytab.
Purpose: The Client and the Service are authenticated (2-way) through
- 1.The Client sends two messages to the Service, one message called authenticator which is encrypted with the
Service-Sessionand the encrypted Service Ticket.
- 2.The Service decrypts the Service Ticket with its
Service-Sessionwhich it uses to decrypt the authenticator.
- 3.The Service performs a series of checks in a similar manner as the KDC/TGS:
- 1.The Service checks if the Service Ticket has expired using the
- 2.The Service compares the
timestampin the Service Ticket and authenticator message, the first should be identical and the second should be within the configured time-tolerence (~2 mins)
- 3.The Service checks if the authenticator with the corresponding
timestampalready exists in the Service-cache which would indicate a replay-attack
- 4.The Service stores the
Service-Sessionlocally and associates it with the Client.
- 5.The Service replies with one message called authenticator which is encrypted with
- 6.The Client receives the autenticator and decrypts it with the
Service-Sessionin order to verify the identity of the Service.
- 7.The Client and the Service are now authenticated against each other and shares the
Service-Sessionkey which will be used together with the Service Ticket in future requests.
Microsoft Kerberos Network Authentication Service V5 Extensions