Kerberos in Active Directory Revealing the underpinnings of AD authentication

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.

Obtaining a Service Ticket

After you log on, you probably have a myriad of applications and services that you want to access. In the world of Kerberos, anything you want to access is called a service. Common examples of services include file and print servers, database servers, and internal web applications. To access a service, you need to present a service ticket to the service. The first step is to identify the service principal name (SPN) of the service you want to access. Your machine or the application involved (e.g., Internet Explorer) is responsible for forming the SPN.
In the case of a file server called srv01.contoso.com, the SPN for the file service would be cifs/srv01.contoso.com. Likewise for a web application at web01.contoso.com, the SPN might be http/web01.contoso.com. A common problem that AD administrators encounter is one of duplicate SPNs, in which more than one user or computer in the directory has the same SPN registered in its servicePrincipalName attribute. When this happens, the KDC doesn’t know how to respond to a service ticket request because multiple services with the same name exist.
If you look at the servicePrincipalName attribute in AD, you’ll notice that neither of the two sample SPNs mentioned are defined on any computer account in AD. To reduce the amount of duplicate data stored in the directory, AD maintains a forest-level mapping of default SPNs to every computer account in the directory. Literally dozens of built-in SPNs apply to every computer defined in the attribute. The data is stored in the spnMappings attribute of the Directory Service object in the Configuration partition (under CN=Directory Service, CN=Windows NT, CN=Services, CN=Configuration); this attribute maps each computer object’s HOST service to a variety of other services. These services include the CIFS and HTTP services. If you wanted to define a particular service on every machine in your forest, you could easily modify this attribute to add the service to the list of predefined services.
Figure 3 shows the contents of a TGS_REQ (Ticket Granting Service Request) message that the KDC receives from a client when the client attempts to access a service. The first piece of information is the SPN of the service the client is requesting a ticket for. Encrypted with the session key the client received as part of the AS_REP earlier is the client’s name and a timestamp. This information is again used to prevent replay attacks whereby an attacker reuses a request message. Also included is a copy of the TGT the client received earlier.
When the KDC receives a TGS_REQ message, if a single entry for the SPN is specified, the timestamp is within range, and the TGT is valid (and unexpired), the client will receive a service ticket as part of a TGS_REP message, as Figure 4 shows. Inside the TGS_REP message is everything the client needs to access the service that it’s requesting access to.
Encrypted with the session key provided in the AS_REP message that Figure 2 shows is a second session key for use when communicating with the service the client has a ticket for. Encrypted with the service’s secret (e.g., the password of the machine account or service account) is a service ticket that the client will cache and use whenever it needs to access the service. Much like the TGT, service tickets have a maximum lifetime (which is ten hours by default in AD’s implementation of Kerberos) for which they can be reused. With a service ticket in hand, the client can now request access to the service.

Accessing Services

After the client has a service ticket, the application accessing the service can present that ticket to the service and request access. The mechanics of presenting the service ticket aren’t nearly as standardized as for obtaining the ticket because every application is different. In the case of an HTTP service, the service ticket is embedded in the headers of the HTTP request.
The service ticket is presented to the application in the form of a Kerberos AP_REQ message, as Figure 5 shows. The service decrypts the service ticket and obtains the session key, which it can use to decrypt the timestamp and client name fields, which are in turn used to validate the authenticity of the service ticket itself. It’s important to note that even if the service accepts the service ticket, at this point the client has merely authenticated to the service. The task of authorization is still up to the service, based on the information it has about the client.
The service ticket typically also includes data known as the Privilege Attribute Certificate, or PAC. In Figure 5, the PAC is called Token Information. If you refer back to Figure 2, this is the same token information the KDC included in the user’s TGT. The PAC is composed of information such as the user’s SID, group membership information, and user security rights/privileges. When a user presents a TGT to the KDC to request a service ticket, the KDC copies the token information from the TGT and includes it in the service ticket’s PAC field. This is the information that the service uses to construct an access token for the user and to verify the user’s authorization, typically based on group membership.
An additional Kerberos message known as an AP_REP or Application Reply is permissible after the user presents a service ticket in the AP_REQ message that Figure 5 shows. The Application Reply message is optional; in general, the application won’t send such a message unless an error occurs. One example of when an AP_REP message would be generated is in the case of a client that requests (in the AP_REQ message) that a service prove its identity through a process known as mutual authentication.

Process Overview

Figure 6 shows a recap of the message flow when a user decides to access a service on an application server. The user logs on to his or her workstation, generating an AS_REQ and AS_REP message sequence to the KDC, where the user receives a TGT if the credentials are valid. The user’s TGT is subsequently cached in memory and each time the user wants to access a service (such as a file server, print server, or web application), the user presents the TGT back to the KDC and requests a service ticket for the service. The user receives the service ticket and presents it to the application to request access.
If you’re using read-only domain controllers (RODCs) in your environment, the message flow is a bit different from what Figure 6 shows, depending on your password replication policies and where the passwords are cached. Remember that the KDC needs access to the service’s and user/computer’s secrets to issue service tickets and TGTs, respectively. By default, an RODC caches no passwords, so it has no access to the necessary secrets.
In the event that an RODC receives a request for a TGT or service ticket that it can’t fulfill (because of an uncached password), it passes the request back to a writeable DC that holds the necessary secrets to encrypt the response. The writeable DC sends the response to the RODC, which in turn sends it back to the client. If the RODC has the password cached for either the user or the service the user is trying to access, the RODC simply issues the TGT and/or service ticket in the same manner as shown in Figure 6.
If you refer back to Figure 2, you’ll see that the user’s TGT is encrypted using the KDC secret. This secret is the password to the krbtgt account, which all AD domains have. Considering the baseline design assumption of an RODC (i.e., the fact that it's compromised by default), it would be potentially catastrophic if the RODC contained the password to the domain-wide krbtgt account. If the RODC were compromised, the attacker could issue TGTs independently.
To mitigate this risk, each RODC has its own krbtgt account and is never aware of the passwords for either the domain-wide krbtgt account or another RODC’s krbtgt account. Writeable DCs have access to the passwords for all the RODC krbtgt accounts so they can decrypt TGTs issued by any RODC in the domain.

Transparent Authentication

Kerberos is implemented in such a way as to be almost transparent to AD administrators. Unlike many authentication schemes, Kerberos never requires that a password traverse the network, nor does it require a user’s password to be stored in memory after the initial logon. Both these benefits greatly reduce the inherent risk of other authentication protocols.
In addition, Kerberos gives users a single sign-on (SSO) experience. In a subsequent article, I’ll examine Kerberos delegation and protocol transition, as well as discuss common errors and troubleshooting techniques related to Kerberos. Delegation and protocol transition are features that many application developers use to extend SSO to enterprise resources without having to involve end users. Although these features work seamlessly, initially translating an application’s requirements into tangible tasks in the directory is a daunting task for many AD administrators.

Original Post: