Although Kerberos might seem like black magic to many systems administrators, it’s one of Active Directory’s (AD’s) key underpinnings. Nearly all of Kerberos’s configuration is abstracted, making actual interaction with the protocol uncommon. However, Kerberos is used every time you log on to an AD-joined machine, as well as when you access network resources such as file shares and applications.
Rather than transmit your actual password over the network, Kerberos operates with a series of tickets. At a high level, when you log on to a machine you generate a series of exchanges with the domain controller (DC) that, if successful, ultimately grants you a ticket-granting ticket (TGT). Each time you subsequently want to access a service, such as a file share or application, you use the TGT to apply for a service ticket to the service or application you want to access.
Authentication
When you sit down at your workstation and press Ctrl+Alt+Del to log on and enter your credentials, your machine begins the process of authentication. At this step, the first thing that happens is your machine sends an AS_REQ or Authentication Service Request Kerberos message to the DC. In Kerberos, we call the DC a Key Distribution Center (KDC). Figure 1 shows the critical contents of such a request.
The client name is either the user’s user principal name (UPN) or the user’s legacy username (sAMAccountName). The service name in this case is always the same, a request to the krbtgt service in the user’s domain (or realm in Kerberos parlance). To prevent replay attacks whereby an attacker recycles an AS_REQ message, the current time is encrypted using a hash of the user’s password. This is where the five-minute clock skew tolerance most AD administrators are familiar with comes into play. If the encrypted timestamp isn’t within five minutes of the current time, the request is rejected.
When the KDC receives an AS_REQ message, the first thing it tries to do is decrypt the encrypted timestamp using its local copy of the user’s password hash. If this operation fails, then an error is returned to the client and the request doesn’t proceed any further. If the decryption is successful and the timestamp is within acceptable limits, the KDC returns an AS_REP (Authentication Service Reply) message to the user, with an embedded TGT. Figure 2 shows the contents of the AS_REP message. At this point, the user’s machine caches the TGT and session key for the lifetime of the TGT and disposes of the user’s password. By default, TGTs issued by AD KDCs expire after ten hours.
It’s important to note that AD’s Kerberos implementation requires the encrypted timestamp in the AS_REQ message. This initial exchange is known as pre-authentication. Kerberos as a standard doesn’t require the encrypted timestamp and instead is perfectly happy with an AS_REQ message that simply contains the client name and service name. The problem with this approach is that an attacker could mount a dictionary attack because each request containing a unique client name would either return an error stating the client wasn’t found or would yield a valid TGT for a given user.
As Figure 2 shows, the AS_REP message contains two pieces of encrypted data. The first component is encrypted with a hash of the user’s password and contains a session key and ticket expiry timestamp. The session key will be used to encrypt future communication with the KDC. The second component, the TGT, is encrypted with the KDC’s secret. The KDC’s secret in AD’s Kerberos implementation is stored as the password to the krbtgt user account that exists in every AD domain. The krbtgt account is created when the first DC in a domain is promoted; this account is crucial to the domain’s operation.