Kerberos
Last updated
Last updated
The Kerberos protocol defines how clients interact with a network authentication service.
On the other hand, authorization is accomplished using data.
Clients obtain tickets from the , which uses Active Directory as its , and they present these tickets to servers, as network credentials.
Originally, The client used his master key which is derived from the user password to decrypt session keys received from KDC.
To avoid users to enter their passwords frequently, the protocol introduces the usage of the ticket.
When a user logs on, the client for the KDC just as it would request a ticket for any other service. The KDC responds by creating a logon session key and a ticket for the KDC's full .
Microsoft extend the Keberos authorization data to provide the server with additional information such as:
Group membership
Claims
Interactive logon information
Integrity levels
A collection of key distribution centers (KDCs) with a common set of principals, as described in [RFC4120] section 1.2.
An administrative boundary that uses one set of authentication servers to manage and deploy a single set of unique identifiers.
A realm is a unique logon space.
Kerberos V5 is composed of three exchanges:
The Authentication Service (AS) exchange
The Ticket-Granting Service (TGS) exchange
The Client/Server Authentication Protocol (AP) exchange
The AS exchange and TGS exchange are transported by Kerberos implementations. The AP exchange is passive and relies on an upper-layer application protocol to carry the AP exchange messages.
Also, we can consume the code in Impakct packages to understand the protocol:
A unique identifier associates a service instance with a service sign-in account.
An SPN must be unique in a forest in which it is registered.
Common service classes can be found here:
Typically, SPN registration is done by a service installation program running with domain administrator privileges.
The Privilege Attribute Certificate (PAC) was created to provide the authorization data, which the Kerberos protocol doesn't provide, for Kerberos Protocol Extensions [MS-KILE].
Into the PAC structure [MS-KILE] encodes authorization information, which consists of group memberships, additional credential information, profile, and policy information, and supporting security metadata.
The Kerberos protocol allows a field within the Kerberos ticket to carry authorization information, and Windows uses that field to carry information about Windows groups.
We can use the command ktpass on windows to
configure the server principal name for the host or service in Active Directory Domain Services (AD DS) and
generate a .keytab file that contains the shared secret key of the service.
Applications that use AP exchange messages directly are typically called "kerberized" applications. Most applications use the (GSS-API) and can even be wrapped by higher-level abstractions such as Simple Authentication and Security Layer (SASL) .
When an application wants to use Kerberos-based authentication, it uses either the higher-level API to invoke Kerberos directly; or it uses SPNEGO , which in turn invokes Kerberos.
The ticket formats are defined in .
The exchange message format is defined in using the ASN.1.
Both KRB_TGS_REQ and KRB_AS_REQ have a common structure as the message.
On the other hand, the message format is used for the reply from the KDC for either an initial (AS) request or a subsequent (TGS) request.
The client presents its principal name and present pre-authentication information ([RFC4120] sections and ) in the KRB_AS_REQ message to request a ticket-granting ticket (TGT) from the KDC ([RFC4120] section 5.3).
By , we can see that the first KRB_AS_REQ message contains PA-PAC-REQUEST as the padata, then a second KRB_AS_REQ is sent with pa-enc-timestamp padata if the Kerberos client receives an error message when pre-authentication is required.
Refer to in the Kerberos implementation of function getKerberosTGT in Impacket, we see the Kerberos client is expecting a Kerberos error message:
Then it using the client's key to prepare the padata to be sent in the second KRB_AS_REQ to demonstrate its knowledge of the user's key.
The ticket, with the logon session key embedded in it, is .
The logon session key is contained in , encrypted with the user's master key derived from the user's logon password, in the message.
Refer to in Impacket, we can see that the Kerberos client can decrypt the encrypted part to get the logon session key for further usage in :
The client , a , and the in the request sent to the KDC for a service ticket for the server.
The authenticator is embedded in a KRB_AP_REQ carried by the KRB_TGS_REQ message as a PA_TGS_REQ padata field, refer to the .
Implementation in the function of the Impacket package:
Contained in the padata of an encoded AP-REQ request body as seen in the .
Implementation in the function of the Impacket package:
The KDC validates the TGT ([RFC4120] section 5.3) and the ([RFC4120] section 5.5.1). If these are valid, the KDC returns a ([RFC4120] section 5.3) and session key the client can use to encrypt communication with the server.
See the example code in .
The new session key is used in the AP exchange, for example like .
The client presents the ticket ([RFC4120] section 5.3) and a new authenticator ([RFC4120] section 5.5.1). The server will decrypt the ticket, validate the authenticator, and can use any ([RFC4120] section 5.2.6) contained in the ticket for access control.
