Kerberos Authentication in Active Directory Made Simple

Kerberos authentication in Active Directory has been part of the security system since the Windows 2000 era. Although it was developed at MIT, Microsoft realized the protocol’s potential and quickly adopted it as the default authentication mechanism for many of its products. One of them is Active Directory.

With Kerberos in AD environments, admins have a robust secure, and efficient way of user/service identification without transferring any plain text passwords across network nodes.

Despite its prevalence inside on-premise servers, not everyone knows how the protocol behaves, why it is used, or even what it is. So, to change that we have prepared this write-up that dives into the Kerberos protocol revealing its its implementation within Active Directory.

Not only that we also cover the best practices to follow during its deployment and some common vulnerabilities that users may encounter. Together with the advanced troubleshooting techniques that focus on the latest Windows Server (2016, 2019, 2022) and Windows 10/11 environments admins will gain useful insights applicable to their daily workflow. So let us start with the basics first.

What is AD Kerberos Authentication?

Kerberos is nothing but a network authentication protocol that uses the concept of a trusted third party. It can be thought of as a set of rules where a trusted independent system (i.e. Kerberos’ Key Distribution Center) verifies the user’s identity before granting (or denying) access to the network services or server resources.

Here the Key Distribution Center plays the main role and uses symmetric-key cryptography to ensure security.

The word Kerberos itself comes from Greek mythology referring to the 3 headed dog guarding the gates of the underworld.

So three heads of this modern Kerberos are:

• The Client: It can be a user or even another server that is requesting access to a resource.
• The Server (or Service on a Server): It is the destination resource to which the client wants access ( like email, storage, application, etc).
• The Key Distribution Center: The main player that acts as the trusted authority (in the Active Directory Kerberos authentication this is usually another domain controller) which can issue the authentication tickets and make interaction between the other two heads possible.

The core principle behind using Kerberos is to prevent password leaks. This protocol uses encrypted tickets and certificate authenticators to prove/disprove the identity of an entity.

Thereby reducing the risk of password interception to a minuscule amount. With the added benefit of immunity against replication-type attacks. Let us now see what components play a part in making the protocol work.

Components of Kerberos Authentication in Active Directory, their Roles, and Responsibilities

In every type of Windows Active Directory environment, there is a tight integration between the domain structure and the Kerberos protocol. It can be better understood by visualizing the role that each part plays.

Domain Controller: Every domain controller acts as a Kerberos Domain controller in some manner. It is the point where the Kerberos service runs and gains access to the Active Directory security account database. For a domain to have the standard Kerberos on it must have the AD DS Role.

Active Directory Database: This is the storage unit of the entire system. Kerberos protocol does the verification using the user and computer account information and their password hashes (by constructing cryptographic keys). Moreover, the group membership details and other security-related attributes(e.g. objectGUID, objectSID, sAMAccountName) are kept here as well.

Security Support Provider(SSP): Kerberos implementation does not happen directly on the server but is rather implemented as an SSP. A sort of Dynamic Link Library that is part of the Windows security architecture. Apps within the AD interact with Kerberos via an interface aptly named SSPI Security Support Provider Interface.

Winlogon: The Single Sign-On feature that allows users to access many resources by only logging in once is possible due to the integration of Winlogon with the Kerberos system.

Service Principal Names (SPNs): Each service that uses Kerberos in any capacity gets a unique identifier that is registered in the Active Directory. These SPNs are used for both authentication and service discovery. It has a general format that is something like

serviceclass/host:port

Realm: In AD environments the Kerberos realm part is played by the domain itself, which decides the scope or boundaries till where the Kerberos authority lies.

Process of Kerberos Authentication in Active Directory Explained Step-by-Step

The Active Directory Kerberos authentication involves many different steps where information exchange between the client, the KDC (specifically its Authentication Service and Ticket-Granting Service), and the target server. It usually starts from a:

Client Request: Whenever a user logs into a domain-joined computer or a similar service request happens the client sends out a “KRB_AS_REQ” message to the authentication service on the domain controller. In this request, there are multiple components like

Client name, requested realm (domain name), pre-authentication data (with timestamp), requested options, and encryption types.

KDC Verification: When Kerberos receives this request it starts a look-up in the AD, gets the password hash, and decodes the pre-auth data. If decryption is as per the rule set then the request is genuine and further processing is carried out otherwise the request gets terminated here itself.

KDC Response: Like the client request this is also a special message tagged as “KRB_AS_REP” containing the following parameters. This is an encrypted value that uses the KDC’s secret key part of the krbtgt account’s password hash.

Also, there is the client’s principal name.

TGT (Ticket-Granting Ticket) otherwise known as the main parameter of the Kerberos system which has the client name, realm, session key(temporary randomly generated character sequence) etc.

Attacks Against Kerberos Authentication in Active Directory

Although Kerberos protects your AD against a wide variety of threats there is always a risk factor involved. The main reason why breaching Kerberos is so lucrative is that it makes critical business data vulnerable. Moreover, almost every on-premise Active Directory uses some form of Kerberos so the potential target list is huge. Hackers can reuse the same attack pattern on many different targets. Some of the most common mechanics are:

Pass-the-Ticket (PtT): Hackers steal a valid Kerberos ticket and use it to do a replay attack to gain access.

Pass-the-Hash (PtH): Here a leaked hash value of the password key is used to obtain a TGT pass.

Kerberoasting: Attacks service accounts to request service tickets for SPNs associated with user accounts. These service tickets are encrypted with the service account’s password hash so the attacker can crack the hash offline.

Overpass-the-Hash: It is similar to a pass-the-hash attack with a slight change that it only targets the Kerberos

PAC Manipulation: Try to make changes to PAC value to escalate privileges.

Encryption Downgrade Attacks: Forced algorithmic level changes that reduce the encryption security (eg from AES to DES)

DC Shadow: A rogue/false domain controller to inject malicious code into the main server.

Conclusion

Kerberos authentication in Active Directory is vital for maintaining security. Its absence can lead to password leakages and other critical failures. Despite all its advantages Kerberos is not invulnerable and can fall victim to highly sophisticated attacks like Kerberoasting. However, with the guidelines provided here, admins can protect their environments from such threats. Additionally, if you require an AD migration anytime soon you can trust the best and most secure solution. Which is none other than SysTools Migrator for Active Directory Migration.