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:
