Kerberos replaced NTLM since Windows Server 2000 as authentication protocol in modern enterprise enviornments. This article will break down the Kerberos protocol as an easy understandable explanation.
Terminology
KDC - Key Destribution Center
Fucntion as trust-source for the kerberos authentication and consists of three sub-components:
- Database with all pricipals and the associated secrets
- Authentication Server
- Ticket Granting Server
Ticket Granting Ticket
Is being assigned to a principal after it has successfully authenticated itself to the authentication server.
Service
Represents a resouce on those a principal can access. This can be everything, for example an SMB-Share or a MS-SQL Database. Every service instance is identified by a uniq Service Principal Name (SPN).
Classic format for this:
class/instnace:portMSSQLSvc/myhost.mylab.microsoft.com:1433Service Ticket
When a principal try's to access a specific service, must it first request a service ticket from the TGS component of the KDC. At that process, the TGT is transmitted to the KDC to proof that the idendity of the requesting client in varified.
Privileged Attribute Certificate
The PAC is assigned to a ticket and contains additional infomration about the principal, for example RID, Domain Group Membership, UAC information and so on. When the service ticket is presented to a service, can this gather the information of it, how ther client/user is privilged to the service, without quering data again to the AD. This is implmented to spare network performance.
Authentication Flow
- To receive a new TGT, the client sends an Authentication Service Rquest (AS-REQ) to the KDC.
- This request contains the Principal Name, Domain Name, Service Name (krbtgt at TGS) and a list of encryption types.
- The KDC verifies that the Pricipal-Account is listed in the Active Directory. By default a pre-authentiction is needed before the TGT is returned. If pre-authentication is not explicitly disabled for this account, it will return an error with valid pre-authentication methods.
- The most common method is a timestap which is encrypted with the secret-hash of the principal.
- The KDC decrypts the timestamp with the secret-hash of the principal. The KDC can access this because this is stored in the AD.
- If this is successfull, the KDC Sends and AS-REP, which contains the TGT for the principal. This also contains a Logon-Session-Key.
- The Session-Key is encrypted with the secret-hash of the krbtgt-account. A copy of this key is encrypted with the user-principal-secret.
New Tickets
Now that a TGT and a Session-Key is availabile, one can request new tickets. The creates a Ticket Granting Service Request (TGS-REQ), which contains the SPN of the target service, for example cifs/computer.domain.com, the principal TGT and an authenticator.
Because the AS-REP and the TGts partially are transmitted over unencrypted networks, Kerberos demands a verification that the TGT-REQs originate from a real principal and not from a 3rd party. For this reason the content of the request is in this context not crucial. It's important that the request is encrypted with the current Logon-Session-Key. Since this key was never transmitted in clear text, the KDC assumes that it originates from a legitimate client.
When the KDC receives the TGS-REQ, it must first decrypt it to validate the authenticator. A copy of this is inclued in the EncTicketPart of the TGT, which is encrypted with the secret-hash of the krbtgt-account. The KDC therefore uses the secret hash of the krbtgt account to decrypt the TGT, obtains the logon session key, and uses it to decrypt the TGS-REQ. When the request is verified, the KDC searches for the SPN in the AD, to determine which principal is assigned to the service, this can be a user or a computer.
When the authenticator and the SPN are technicly valid, the KDC generates a new Service-Ticket for the requested service, together with a new session-key and delivers these in a Ticket Granting Servce Reply (TGS-REP) message. The KDC includes a copy of the PAC of the TGT in the service ticket.
The principal is encrypted with the new Logon-Session-Key. The service-copy of the ticket is encrypted with the secret-hash of the service itself. This is the secreet which is assigned to the user/computer account of the SPN.
Client Server Authentication Exchange
The clients sends only a Aoolication-Request (AP-REQ) to the service itself, this request contians the above explained TGT and an authenticator. The authenticator is a timestamp which is encrypted with the service-session-key. This is needed to verify the topicality of the TGS and to make replay-attacks more dffiicult.
The service decryptes the timestamp and then encrypts it again with the service session key and sends it to the client (AP-REP). The client encrypts the session key with his service session key und verifies that the timestamp corresponds to the original.
The server has now successfully verified that the client possesses a valid Kerberos ticket.
DACL
Subsequently, the service uses a Discretionary Access Control List. To verify the permissions a user has with respect to the service itself. For example, on an SMB server:
- Is the client permitted to read data?
- Is the client permitted to write/modify data?
- Is the client permitted to delete data?
PAC Validation
Furthermore, PAC validation can be required as an optional step, in which case the service examines the PAC contained within the ticket. A request is sent to the KDC to verify the signatures present in the PAC, ensuring that these signatures match the expected secret keys.
Based on this, the service can then either grant or deny access.