When thinking about Active Directory authentication, the protocol that comes to mind is Kerberos. Kerberos has been an integral part of Active Directory authentication since Windows Server 2000 Active Directory, and it continues to be the primary authentication protocol for Microsoft’s Active Directory Domain Services (AD DS) on-premises. Azure Active Directory is the cloud counterpart of AD DS and uses different authentication standards for authenticating users. However, Microsoft recently has announced changes to both AD DS and Azure Active Directory regarding Kerberos that you want to be aware of moving forward.
What is Kerberos?
First of all, what is Kerberos, and how is it used in Active Directory. Kerberos is an authentication protocol that is directly responsible for authenticating resources in Active Directory found in Windows Server 2000 and higher. It is much more secure than NTLM for authentication.
MIT initially developed Kerberos for Project Athena, and Kerberos version 5 was released in 1993 under RFC 1510, which was obsolesced by RFC 4120 in 2005. Microsoft has taken Kerberos and implemented the protocol in Active Directory for use with authentication services there.
Kerberos authentication provides “mutual authentication” without sending or storing passwords over the network. Instead, it validates passwords by checking that specialized tickets can be decrypted using the known password on both sides. This process effectively validates the user credentials are correct without only sending the password over the network.
Using Kerberos “tickets” provides an efficient and secure way to gain access to resources since the client does not have to reauthenticate. It performs the following:
- The client makes a request to receive a Ticket Granting Ticket (TGT)
- Credentials are verified by the Key Distribution Center (KDC) server and sends back an encrypted Ticket Granting Ticket (TGT)
- The TGT is stored, and the client uses this to request access from a server using the TGT
- The Ticket Granting Server (TGS) sends an encrypted session key and ticket
- The client uses a service ticket to request access to resources
- The server then sends an encrypted timestamp back for client validation
Overview of Kerberos authentication from Microsoft
Important changes to Active Directory Domain Services Kerberos authentication coming soon
Due to a recent security vulnerability detailed in CVE-2021-42287, Microsoft is changing how Active Directory Kerberos authentication works and how the original requestor of a Kerberos ticket is validated. Microsoft has improved the authentication process by adding new information about the requestor to the Privilege Attribute Certificate (PAC) of Kerberos Ticket Granting Tickets (TGTs).
Now, when the Kerberos service ticket is generated for an account, the authentication process verifies the account that requested the TGT is indeed the account reference in the service ticket. It effectively prevents an attacker from forcing the KDC to create a service ticket with a higher privilege than a compromised account.
The new change is being gradually introduced using Windows Update. The first phase of the rollout that will change Active Directory Domain Services Kerberos authentication is included in the November 9, 2021 security update and November 14, 2021 OOB update. Microsoft outlines three steps (phases) to deploy the new functionality fully. These include:
- November 9, 2021 – Initial deployment phase
- April 12, 2022 – Second deployment phase
- July 12, 2022 – Enforcement phase
Let’s consider what is involved with each phase and the changes introduced.
November 9, 2021
The November 9, 2021 security update introduces the new underlying remediation of the CVE-201-42287 and allows organizations to audit their environment for the new PAC information. Additionally, with the November update, a new PacRequestorEnforcement registry key has been introduced, enabling Active Directory administrators to control the auditing and enforcement of the new PAC validation.
The new PacRequestorEnforcement registry key has three possible values with the November security update in place:
- 0 – Disabled – Microsoft does not recommend this setting as it disables the registry key. DCs with this setting are in the Disabled phase. This value will not exist after the April 12, 2022, or later updates. Additionally, the 0 setting is not compatible with the 2 setting, which is the enforcement mode
- 1 – Audit mode – With the PacRequestorEnforcement key set with a value of 1, the DC checks to see if the user has the new PAC and if this is validated. If the user does not preset the new PAC, no enforcement action is taken. Active Directory domain controllers instead log various warnings in the System event log, noting the missing PAC.
New PACRequestorEnforcement registry key assigned the 1 value
- 2 – Enforcement mode – In enforcement mode, the PacRequestorEnforcement key is set to 2. If the user does not present the new PAC when authenticating, the authentication is denied.
With the November security update, organizations have the ability to fully implement the remediation it requires all domain controllers have at least the November security update. Organizations can decide to fully implement the remediation by setting the PacRequestorEnforcement key to 2.
April 12, 2022 – Second deployment phase
The upcoming April 12, 2022, Windows Update will introduce the “second deployment phase” in the rollout of the CVE-2021-42287 remediation. The difference with the April 12, 2022 Windows Update is it removes the 0 setting of the PacRequestorEnforcement registry setting. After installing this update on the domain controllers in the environment, setting the registry key to 0 has the same effect as setting it to 1. It essentially places all DCs into deployment mode regardless.
This phase is not required if customers already had their domain controllers in the PacRequestorEnforcement 1 setting before this second deployment phase. Nothing will change if that is true. This phase from Microsoft helps organizations ensure they are properly transitioning and implementing the deployment phase.
July 12, 2022 – Enforcement phase
After installing the July 12, 2022, Windows Update, it will transition all domain controllers to the new Enforcement phase of the new PAC rollout. After installation, the PacREquestorEnforcement registry key is removed completely. It is extremely important for customers to understand the ramifications of installing this update with the enforcement option mandated. At this point, domain controllers with this update will no longer be compatible with the following:
- DCs that have not installed the November 9, 2021, or later updates
- DCs that have installed the November 9, 2021, or later updates but not the April 12, 2022 update and have a PacRequestorEnforcement registry value set to 0.
Begin auditing and planning now
The new CVE-2021-42287 remediation and subsequent enforcement of the new PAC validation represents a fundamental change in Kerberos authentication found in Active Directory Domain Services. Therefore, organizations must give due attention and plan for this impending change as domain controllers in unsupported and mixed Windows Updates and PacRequestorEnforcement registry configurations will not interoperate.
Introduction of Kerberos authentication in Azure Active Directory (Azure AD)
While Kerberos authentication has been the de facto standard in on-premises Active Directory Domain Services environments, Azure Active Directory (Azure AD) has not supported the use of Kerberos authentication. Instead, Azure AD uses other authentication protocols, including SAML 2.0, OpenID Connect, and OAuth 2.0.
Microsoft recently announced the introduction of Azure AD Kerberos. So why did Microsoft decide to introduce Azure AD Kerberos? Microsoft realizes that to help organizations make the transition for many business-critical services to the Azure cloud, they must bridge the gap between legacy applications that may rely on protocols like Kerberos for authentication instead of cloud authentication protocols like OAuth.
Currently, Kerberos is being introduced for authentication to access Azure File shares configured for Azure AD authentication to allow specific use cases such as allowing FSLogix interaction with Azure File Shares. However, undoubtedly, Microsoft has bigger plans for Kerberos in Azure AD to enable organizations to use the Azure cloud more easily.
With the introduction of Kerberos in Azure AD, organizations can now have the best of both worlds with the extremely easy security solutions integrated with Azure AD, such as conditional access, Windows Hello, and other technologies. In addition, advanced security features that are complex and difficult to implement with on-premises AD DS are relatively easy to do in Azure AD, often amounting to a few checkboxes. You can read more about the new Kerberos authentication capability in Azure AD Kerberos technical deep dive here.
Wrapping Up
Kerberos is the core authentication protocol found in on-premises Active Directory Domain Services (AD DS) environments. After decades of no fundamental changes, Active Directory Domain Services is receiving Kerberos enhancements. Microsoft has already begun making fundamental changes to Kerberos to remediate CVE-2021-42287. Starting with the November 2021 security patches, a new registry key (PacRequestorEnforcement) allows AD admins to audit and enforce the new PAC validation. Organizations must plan accordingly.
In addition, in a surprise announcement in December 2021, Microsoft has introduced Kerberos authentication for Azure Active Directory. It allows organizations to bridge the gap between legacy applications and the Azure cloud more easily and help solve specific authentication challenges.
