Active Directory: The End of the Road? Not Quite Yet!

Microsoft announced several enhancements to Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS) that are included in the preview for the next version of Windows Server (vNEXT). These enhancements provide additional security, scaling and performance, and supportability for AD DS/LDS. In this blog post, we’ll discuss some of the enhancements in vNEXT—some of which have already been backported to Windows Server 2022 and Windows Server 2019.

You can test drive these enhancements by signing up for the Windows Insider Program for Windows Server.

Security enhancements

Microsoft added several security enhancements to strengthen your AD environment.

Delegated Managed Service Accounts

Delegated Managed Service Account (dMSA) functionality evolved from Group Managed Service Accounts (gMSAs), which were introduced way back in Windows Server 2012. dMSAs allow you to migrate from service accounts originally created as regular users to delegated accounts that provide similar benefits as gMSAs. Like gMSAs, dMSAs automatically rotate their passwords with strong, randomly generated values. 

Another benefit of using dMSAs is that the services do not need to be changed. During the process of migrating to a dMSA, the regular user account and the dMSA are linked in AD using new attributes introduced in the vNEXT AD schema. This allows the service’s configuration to remain unchanged and appear to run under the context of the regular user account but actually use the dMSA.

Be cautious, because a potential pitfall exists. Once the migration to the dMSA is complete, the original service account is disabled in AD. If the original account is deleted, the linkage between it and the dMSA breaks. The services that are still configured to run under the context of the original account will no longer start. This might happen if the disabled object is deleted during a stale object cleanup exercise.

This Microsoft YouTube video demonstrates the migration process to dMSAs.

Confidential attributes

Microsoft is also introducing security enhancements for confidential attributes. Encrypted connections are now required for LDAP add, search, and modify operations, to help protect the sensitive attribute values from being captured in transit.

LDAP channel binding auditing

LDAP channel binding auditing has two new event IDs (3074 and 3075), which help identify clients that would fail LDAP bind operations given certain conditions.

  • Event ID 3074: This event enables administrators to detect clients that attempt to bind with channel binding tokens (CBTs) but the CBTs are constructed inadequately. If the client attempts an LDAP bind over Transport Layer Security (TLS) and the domain controller (DC) is configured to require CBT validation, the LDAP bind will fail.
  • Event ID 3075: This event enables administrators to detect clients that can—but do not—send a CBT. If the client attempts an LDAP bind over TLS, it will fail if CBT validation on the DC is enforced.

Microsoft backported these events to Windows Server 2022 with the August 2023 cumulative security update and to Windows Server 2019 with the October 2023 cumulative security update.

For more information regarding these new LDAP channel binding events, please see Microsoft’s article that discusses the August 2023 and October 2023 updates.

To read more about implementing LDAP CBTs, please see the Ravenswood article Remediating LDAP Client Security.

LDAP encryption

vNEXT introduces an enhancement to LDAP encryption. After a Simple Authentication and Security Layer (SASL) bind takes place, all LDAP client communications now prefer LDAP sealing (encryption).

For more information, please see this Microsoft article on SASL authentication.

LDAP support for TLS 1.3

Enhancements to LDAP over TLS are also coming. Schannel, a Security Support Provider (SSP), enables LDAP traffic encryption using TLS. In vNEXT, the latest version—TLS 1.3—is supported for LDAP.

The security benefits of these enhancements are:

  • TLS 1.3 is more secure than the older versions.
  • Obsolete cryptographic algorithms are removed.
  • The TLS handshake process is encrypted wherever feasible.

TLS 1.3 for LDAP was added to Windows Server 2022 with KB5014665 and Windows 11 with KB5014668 in June 2022. Once installed, TLS 1.3 is enabled by default. If the need arises to disable TLS 1.3, this Microsoft article has information on how to disable it.

Stronger encryption for Kerberos

AD DS/LDS adds support for AES SHA-256/384, which increases encryption and signing strength. Microsoft has also deprecated the Rivest Cipher 4 (RC4) encryption algorithm, which is no longer used.

For more information on RC4 and best practices for disabling RC4, Microsoft has a great blog post:  Decrypting the Selection of Supported Kerberos Encryption Types.

Scaling and performance improvements

Scalability enhancements allow performance improvements in your AD environment.

New forest and domain functional levels

vNEXT introduces new forest and domain functional levels: ForestLevel 10 and DomainLevel 10. Some of the enhancements discussed require AD DS/LDS to be at the new forest and domain functional levels.

You might recall that the previous functional levels were from Windows Server 2016 (ForestLevel 7 and DomainLevel 7). What happened to functional levels 8 and 9? It seems that these would have correlated nicely with Windows Server 2019 and Windows Server 2022, but since Microsoft did not introduce any functionality that required new functional levels with these operating systems, levels 8 and 9 were skipped.

32KB database page size optional feature

AD DS and later AD LDS were originally implemented with an 8KB database page size. The database page size restricts the AD object size, because each object must fit on a single page. Increasing the page size limit to 32KB allows larger objects to be stored in the AD database. The most noticeable impact is to multivalued attributes, which were previously limited to around 1,200 values. With the increased database page size, this limit grows to approximately 3,200 values.

You might be wondering, How do I get this impressive new 32KB database page size? New vNEXT DCs that are added to an existing forest at forest functional level 7 have the 32KB database page size, but they run in compatibility mode (8KB page size). Once all DCs are upgraded to vNEXT and the forest functional level is raised to level 10, the 32KB database page size optional feature can be enabled.

To move to the 32KB page size, use PowerShell to enable the “Database 32k Pages Feature” optional feature. For a demonstration on how to enable this optional feature, see this Microsoft YouTube video.         

Non-uniform memory access support

AD DS now supports non-uniform memory access (NUMA), which allows it to use all processor groups. Previously, AD DS could only use processors in Group 0. Most organizations don’t run DCs that have more than 64 logical processors, but for those that do, AD DS can now use all processor groups and can use more than 64 logical processors.

NUMA support has also been added to Windows Server 2022 with KB5016693.

This Microsoft YouTube video demonstrates the enhancement.

Schema updates

vNEXT adds one new class, eight attributes, and one optional feature to the AD DS schema. These new classes, attributes, and optional feature enable support for dMSAs and the 32KB database page size optional feature that were mentioned previously.

The AD LDS schema gets two new attributes and one optional feature to support the 32KB database page size enhancement.

The schema extension contents are summarized in Table 1.

NameobjectClassDirectoryDescription
ms-DS-Delegated-Managed-Service-AccountclassSchemaAD DSThe new object class for dMSAs
ms-DS-Superseded-Service-Account-StateattributeSchemaAD DSA new attribute for user objects (service accounts) that tracks the status of the migration to a dMSA
ms-DS-Delegated-MSA-StateattributeSchemaAD DSAn attribute of a dMSA that indicates if the dMSA is linked to a service account
ms-DS-Superseded-Managed-Account-LinkattributeSchemaAD DSAn attribute of the service account that indicates the dMSA it is linked to; this is a forward link
ms-DS-Superseded-Managed-Account-LinkBLattributeSchemaAD DSAn attribute of the dMSA that indicates the service account it is linked to; this is a back link
Ms-DS-Managed-Account-Preceded-By-LinkattributeSchemaAD DSAn attribute of a dMSA that indicates the service account it is linked to; this is a forward link
ms-DS-Managed-Account-Preceded-By-LinkBLattributeSchemaAD DSAn attribute of a service account that indicates the dMSA it is linked to; this is a back link
Ms-DS-JetGetRecordSize3attributeSchemaAD DS/LDSA new attribute that exists on all objects, which contains information about the object’s usage requirements in the database
ms-DS-JetDB-Page-SizeattributeSchemaAD DS/LDSA new attribute that shows the supported database page size
Database 32k Pages FeaturemsDS-OptionalFeatureAD DS/LDSThe new optional feature that must be enabled to make use of the “Database 32k Pages Feature”
Table 1 – Schema extensions in vNEXT for AD DS/LDS

For more information regarding the schema changes in vNEXT, please refer to sch89.ldf and sch90.ldf, which can be found on the ISO image for vNEXT in the \support\adprep folder. The AD LDS schema updates can be found in the MS-ADAM-Upgrade-3.ldf file, which is in the C:\Windows\ADAM folder once the AD LDS feature is installed.

Supportability enhancements

Microsoft added supportability enhancements to improve client DC discovery and monitoring of your AD environment.

Performance Monitor

Performance Monitor is also getting additional performance counters for AD DS/LDS:

  • LSA Lookups – Useful for monitoring and troubleshooting lookups for Name and SID values
  • DC Locator – Helpful for monitoring and troubleshooting DC location issues; new counters are available for clients and DCs
  • LDAP Client – Facilitates monitoring and troubleshooting the execution of LDAP client binds and connections

DC-location algorithm

Enhancements have been made to the DC discovery process and to mapping of domain short name (NetBIOS) to DNS fully qualified domain names (FQDNs).

DC location is essential for clients wanting to interact with AD. There are two main methods of DC location:

  • DNS-based discovery – Clients locate DCs by querying DNS for service (SRV) records, performing an LDAP ping to the DCs, and connecting to the one that responds first.
  • NetBIOS-based discovery – Clients locate DCs by querying Windows Internet Name Service (WINS) for records, which were registered by the DCs. The clients then ping the DCs returned by WINS.

Windows clients no longer use Remote Mailslots when discovering DCs. WINS and Remote Mailslots are not secure, and Microsoft notes that both features are being deprecated. This Microsoft article describes the new process for mapping NetBIOS domain names to DNS domain names.

To read more about the DC locator process, see the Microsoft article How domain controllers are located.

Active Directory lives to see another day!

Microsoft hasn’t abandoned AD DS/LDS quite yet. It continues to be the core identity system for many organizations and must continue to be secured from evolving threats. It is great to see Microsoft continue to make investments in these older technologies. While some of us were hoping for native multifactor authentication (MFA) in AD DS without the need for smart cards or Microsoft Entra ID Privileged Identity Management (PIM)-like functionality, we’ll have to wait for now.

Many organizations at least started their migrations to the cloud and are working toward reducing their reliance on AD DS and AD LDS; however, complete migration off of Microsoft’s LDAP directories is not likely to occur anytime soon. Once it becomes generally available, you’ll need to upgrade to vNEXT to benefit from all the new security, scalability, and supportability enhancements.

If you need assistance with planning your upgrade to vNEXT, contact the experts at Ravenswood Technology. We’re happy to help!

[RELEVANT BLOG CONTENT]

6 Tips to Harden Your Windows LAPS Deployment

In a previous blog post, we covered how to migrate to Windows Local Administrator Password Solution (LAPS). With Windows LAPS deployments gaining traction, it’s important

Migrating to Windows LAPS

Windows Local Administrator Password Solution (LAPS), now integrated into the OS, is the replacement for Microsoft LAPS, which was a separate installation. Windows LAPS is

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.