If you have been researching Active Directory (AD), chances are that you will come across the concept of Kerberos for user authentication and other service request-related functionalities.
It is worthwhile to examine the Kerberos protocol in depth and, in turn, appreciate the dependency of AD on Kerberos. Given that Kerberos is an industry standard, you will see that it has become the most widely used network authentication protocol for all Windows environments with operating systems 2000 and later. Being familiar with Kerberos authentication is vital for understanding this protocol better.
In the most simplest of terms, you can think of Kerberos authentication as the default and most fundamental authenticating mechanism used by Windows AD environments.
Kerberos authentication is built on the concept of tickets and session keys that ultimately makeup what we commonly describe as credentials. These credentials are used to authenticate users on any required domain. They subsequently make service requests to establish a secure encrypted connection with a target server, over any unsecured network. Kerberos ensures that all interacting clients provide proof of identity with the servers, sometimes mutually if need be, to enable a flawless authentication process.
Kerberos, LDAP and their intersection: Commonly confused concepts
There is often some confusion about the differences and similarities between how Lightweight Directory Access Protocol (LDAP) works and what Kerberos offers. To address this confusion, you can think of Kerberos as providing a single sign-on authentication service for clients to access multiple applications and services. And, you can think of LDAP in relation to AD, as a communication protocol to look up, search, and modify AD data.
LDAP also authenticates users with a dual step procedure. It first checks a user’s distinguished name and the password that the client provides against the information stored in the LDAP database. LDAP authentication and subsequent authorization enables clients to access the AD database to retrieve and manage the AD data in a swift and efficient manner.
Kerberos and LDAP are generally used cohesively to ensure that the individual capabilities offered by both are harnessed as the AD environment is set up.
The Kerberos authentication model
The Kerberos mechanism is analogous to the three-headed dog, Cerberus, of Greek mythology. The working model of this protocol is designed based on three parts:
➤ The user, or the client, requesting a given service
➤ The application, or the target server, providing the required service
➤ The trusted, third-party server, called the key distribution center (KDC). This is usually installed on the domain controllers in any AD environment.
The KDC is logically further identified by three main components:
➤ The database (Db)
➤ The ticket granting server (TGS)
➤ The authorization server (AS)
Using multiple steps, including ticket granting, encryption and decryption checks, Kerberos tickets aid in the authentication process.
This protocol flows explains the Kerberos authentication process broadly:
-
-
Any user or client requiring authentication during the logon process, inputs a password as part of the login process. This is processed to yield a hash that is derived through a password hashing algorithm.
-
-
-
The client requests a ticket granting ticket (TGT) by stating its user principal name (UPN) to the KDC. The Kerberos command used here is KRB_AS_REQ.
-
-
-
This password hash is checked, processed, and then used by the AS of the KDC to generate a client/user secret key.
-
-
-
The AS at this stage also generates a TGS secret key after confirming the availability of the TGS.
-
-
-
A session key 1 (SK1) is processed by the AS, which becomes a part of the encrypted TGT delivered to the client to prove it’s initial identity.
-
-
-
The TGT is sent to the client from the KDC after a look up of the client’s UPN in the Db of the KDC. The Kerberos command used here is KRB_AS_REP.
-
-
-
The TGT has the client ID, client network address, timestamp, lifetime value and the SK1. Here, it is important to note that the encryption of the information in TGT is completed using both the client or user secret key as well as the TGS secret key.
-
-
-
After receiving this response, the client uses its password hash to extract the SK1.
-
Each time the client requires a service or access to any particular network resource, the TGT will need to be renewed upon expiry from the KDC.
-
This completes the first stage of establishing the primary identity of the client, which paves the way for subsequent steps of authentication.
To access a particular service, such as a remote login to a new workstation, or access a web browser or a file system, there are subsequent authentication steps required to prove that the client is allowed access to that service. These steps are:
-
-
The client processes the TGT in possession, adds the service principal name (SPN) of the required service, and sends an authenticator encrypted with SK1 and later by the TGS secret key to the TGS. The Kerberos command used here is KRB_TGS_REQ.
-
-
-
The TGS is contacted to request session initiation between the client and the target server though a service session key (SK2).
-
-
-
The TG server uses the TGS secret key to decrypt the the authenticator and extract SK1. Upon successful checks for validity of TGT, and a match of client information both on the TGT and the authenticator, the TGS creates the SK2.
-
-
-
The KDC includes the SK2 along with the client ID, network address, timestamp etc. in a service ticket and sends it to the client. The Kerberos command used here is KRB_TGS_REP.
-
-
-
This ticket is encrypted using a server secret key that the Db provides. It is again double encrypted with SK1 and is sent to the client. This ticket also has the privilege attribute certificate (PAC) which states the user privileges for the client as encrypted and signed by KDC.
-
-
-
The client can only decrypt this service ticket to extract SK1, generate a new authenticator message, encrypt it with SK2, and send it to the target server for final decryption and authentication to access the service. The Kerberos command used here is KRB_AP_REQ.
-
-
-
The target server, with its secret key, decrypts the service ticket. It accesses SK2 and decrypts the authenticator. It may first identify itself, i.e. authenticate itself with the client with an optional KRB_AP_REP Kerberos command, in cases where mutual authentication is needed for enhanced security.
-
-
-
If the client ID and other information from the service ticket and PAC matches that on the authenticator, a secure, authenticated connection is established between the client and the target server to offer the required service.
-
These steps are followed to determine if authentication can be deemed a success or a failure between client and server using the Kerberos protocol.
Some of the most noticeable advantages of using this authentication model is that passwords are never stored in plain text, nor are they transferred over the network in their native form. Kerberos, however, is not infallible. To understand this protocol completely, you will need to pay due attention to the limitations of the protocol flow as well as the vulnerabilities associated with it. The blog on A practical approach to Active Directory Domain Services, Part 8: AD Attacks introduces you to AD attacks, one of which specifically focuses on the concept of Kerberos. Stay tuned for more!
