The last major Active Directory Domain Services (AD DS) update came with the release of Windows Server 2016. While there was a schema update with Windows Server 2019, it was only to provide a unique geolocation for employees of multinational companies for Microsoft Office 365/Microsoft Entra. After two major OS releases without an upgrade for AD DS, some might have lost hope of ever seeing an enhancement again.
However, with the release of Windows Server 2025, Microsoft included several AD DS updates. While there are always benefits to upgrading to the latest OS, are there any features in Windows Server 2025 that would drive an upgrade of an AD DS infrastructure? In this article, we will discuss two AD DS enhancements:
- Scalability improvement: 32k database page size optional feature
- Security improvement: delegated Managed Service Accounts (dMSAs)
For a summary of the enhancements for Active Directory (AD) in Windows Server 2025, see this article: Active Directory: The End of the Road? Not Quite Yet! – Ravenswood Technology Group
New Optional Feature: 32k Database Page Size
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Starting with Windows Server 2008 R2, Microsoft supported a set of optional features for AD DS. Since these are optional features, they are not enabled by default and must be enabled. Optional features are enabled within a scope (forest or domain), which determines the domain controllers (DCs) the feature is enabled on. Microsoft has released three optional features for AD DS, all of which have a forest scope.
The optional features Microsoft previously released are:
- Recycle Bin (required a Windows Server 2008 R2 forest)
- Privileged Access Management (required a Windows Server 2016 forest)
The optional feature Microsoft released with Windows Server 2025 is:
- Database 32k Pages (requires a Windows 2025 forest)
The Recycle Bin feature can be enabled utilizing the Active Directory Administrative Center or PowerShell, but the only way to enable the other optional features is to utilize the PowerShell cmdlet Enable-ADOptionalFeature. For more information about this cmdlet see “EnableADOptionalFeature (ActiveDirectory) | Microsoft Learn.”
The first enhancement for AD DS that we are focusing on in this article is the new “Database 32k Pages” feature, which increases the AD database page size.
AD DS and Active Directory Lightweight Directory Services (AD LDS) are built using an Extensible Storage Engine (ESE) database. From Windows 2000 Server onward, the ESE database (NTDS.DIT) has utilized an 8k page size. Beginning with Windows Server 2025, Microsoft will now support a 32k database page.
What does this mean for you? In AD, multi-valued attributes can either be linked or non-linked. With a multi-valued linked attribute, each value is a pointer to another object within the directory. If you query an object’s multi-valued linked attribute, you can then run another query against each value and find that object in the directory. An example of a multi-valued linked attribute is member. In the example below, the member attribute for Group01 can contain thousands of values, as the member property points to other objects in the directory.
With a multi-valued non-linked attribute, the data is independent and, as the name implies, it is not a pointer to another object. Instead, the values are stored directly within the attribute of the object. An example of a multi-valued non-linked attribute is proxyAddresses. If you queried User01 for the value of the attribute proxyAddresses, the data is stored within the attribute and does not have a corresponding object within the directory. Due to the way this data is stored, multi-valued nonlinked attributes are limited in how many values they can store. The approximate limit is around 1200-1300 values.
LDAP error 0x00000b or 0x0b – “LDAP_ADMIN_LIMIT_EXCEEDED” Once you pass the 1200-1300 limit in a multi-valued non-linked attribute, you may start to see the following errors:
Active Directory replication error 8304 (0x2070): - “The maximum size of an object has been exceeded”
Directory Service event log – Event ID 1084 –
“Active Directory Domain Services could not update the following object with changes received from the following source directory service. This is because an error occurred during the application of the changes to Active Directory Domain Services on the directory service.”
The ‘additional data’ field of the event contains the root cause of the event, in this instance it would be that the maximum size of an object has been exceeded.
Directory Service event log – Event ID 1093 –
“Active Directory Domain Services could not update the following object with attribute changes because the incoming change caused the object to exceed the maximum object record size. The incoming change to the following attribute will be reversed in an attempt to complete the update.” You might see this issue with the following multi-valued non-linked attributes:
- dnsRecord
- proxyAddresses
- registeredAddress
- servicePrincipalName
- userCertificate
A full list of multi-valued attributes with a non-linked value can be obtained by querying the schema partition. Search for attributes that are defined as isSingleValued equal to FALSE and linkID is <not set>.
This is a high-level summary of how AD DS stores data in the ESE database. For an in-depth understanding of the ESE database and the limitations with 8k page sizes, please see “Ask the Directory Services Team – ESE Deep Dive: Part1: The Anatomy of an ESE database.” – Microsoft
When the optional 32k database page size feature is enabled, AD DS can support multi-valued attributes with approximately 3,200 values. While that is great news for organizations that have run into issues with the previous size limitation, the following requirements must be met first.
- Every DC in the forest is running Windows Server 2025 or later.
- A DC upgraded from a previous version to Windows Server 2025 (an in-place upgrade) will not support the 32k page database size.
- The forest and domain functional levels must be set to Windows Server 2025 or later.
- The optional feature for 32k database pages must be enabled utilizing the PowerShell command Enable-ADOptionalFeature.
- Prior to running this command, even if all DCs are running Windows Server 2025 and the forest functional level is set correctly, the DCs will still be using an 8k page size.
Important Notes
- Prior to enabling this option in your production environment, validate your backup software is capable of backing up and restoring a 32k page database format with a test environment.
- Enabling this optional feature is an irreversible action; you cannot revert to the previous 8k database page size.
- Any 8k page backup media created prior to enabling the feature will no longer be usable unless a complete authoritative forest recovery is performed.
- Enabling the larger 32k page sizes can impact your DC’s performance due to increased memory usage.
Delegated Managed Service Accounts (dMSAs)
When you don’t want to do something, many times you find a reason to push it out for another day. For many people, this applies to changing passwords on service accounts because doing so comes with risks, including:
- If you change the account password, it may require changing credentials throughout the application for the new account to work.
- If you change the password on the existing account, you must know all the places that account is utilized and the password in case you have to revert the change. If you don’t know the password (or worse yet, thought you knew the password but didn’t), that is when this task can get ugly.
This is where dMSA comes in. dMSA is a new account type that works like a group Managed Service Account (gMSA) but has new security features that will help environments with service accounts running on Window servers. One security benefit of a dMSA over a gMSA is the authentication request is linked to the device identity, meaning the account can only be utilized by specified machine identities that have been mapped in AD DS. When a computer tries to authenticate with Kerberos against a dMSA, if that computer isn’t mapped to the account, the authentication request is rejected. No more Kerberoasting. Another advantage of a dMSA comes into play when you migrate from a standard service account to a dMSA. We will discuss that more in a moment.
For a comparison of some of these features, see the table below.
Standard Service Account | gMSA | dMSA | |
|---|---|---|---|
Password Management | Set upon creation and rotated manually | Machine generated and auto rotated | Randomized secret held by the DC and auto rotated |
Security | Basic | Secured with machine-generated and auto-rotated passwords | Authentication linked to device identity |
Migration | Build new account and reconfigure all hosts | Build new account and reconfigure all hosts to utilize new gMSA | Replace existing service accounts, blocking the old password |
A dMSA can be created as a standalone account, or it can be created to replace or supersede an existing standard service account. There currently isn’t a migration path from managed service accounts (MSA) or gMSAs to dMSAs. When a dMSA is created as a standalone account, it works primarily like a gMSA, but with the additional security benefits listed in the table above.
One major benefit of using a dMSA is evident when it replaces or supersedes a standard service account. In this scenario, the original account on the server remains unchanged throughout the migration. Once the migration is completed, the standard service account is still configured on the server, but the authentication is redirected to the dMSA. The only configuration required on the server is the creation of a registry key. After that, no further work is required on the server to migrate to the dMSA.
On each server that will utilize a dMSA, whether standalone or to supersede an existing service account, the following setting must be enabled through either a Group Policy Object (GPO) or manually through a registry key, as shown below.
Group Policy setting (supported on Windows 11 Version 24H2 and later):
- Under System\Kerberos – ‘Enable Delegated Managed Service Account logons’
- This policy setting enables or disables dMSA logons for this machine. If you enable this policy setting, dMSA logons will be supported by the Kerberos client. Note that this policy has certain prerequisites. The prerequisites and the directions to create a new dMSA can be found here. If you disable or do not configure this policy setting, dMSA logons will not be supported.
Registry key:
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"
Name = "DelegatedMSAEnabled"
Value = 1
Type = "DWORD" To replace an existing service account, the first thing that must be done is to create a standalone dMSA that will shortly be linked to the standard service account. The same PowerShell cmdlet that is used to create a gMSA is used but with the parameter CreateDelegatedServiceAccount set to True.
Note: Prior to creating your first dMSA, the KDS root key must be generated on the DC. You can use Get-KDSRootKey in PowerShell to verify if the key is available. If a key is not available, one can be added by running Add-KDSRootKey in PowerShell.
In the image below, Server1 has a service that uses a standard service account (Domain\SrvAcct). A new dMSA is created (referred to as dMSA in the image) that will be used to supersede the standard service account.
After the account is created, any machines that will utilize the new dMSA will need to be allowed to retrieve the password. This is accomplished one of two ways:
- Setting the PrincipalsAllowedToDelegateToAccount value to the distinguished name of the member server(s) that will be using the dMSA
- Learned by AD (this only applies to service accounts that are being superseded by a dMSA)
To begin the migration process, the first step is to run the cmdlet Start-ADServiceAccountMigration. This will link the two accounts within AD, allowing the dMSA to learn all the devices the service account is used on. Each device that is utilizing the superseded service account will be added to the PrincipalsAllowedToRetrieveManagedPassword attribute on the dMSA. This can be viewed using the Get-ADServiceAccount cmdlet.
An account in this state will have the msDS-DelegatedMSAState set to 1. It is recommended to let at least two Kerberos ticket lifetimes (14 days) go by with the account in this state so that the account reauthenticates at least twice prior to migration.
Once you are ready to complete the migration process, the PowerShell cmdlet Complete-ADServiceAccountMigration is run. At this point:
- The server is still configured to use the standard service account.
- Authentication requests are redirected to the dMSA utilizing the randomized secret to authenticate the service instead of the legacy password.
- To further enhance security, the legacy service account is disabled.
- The msDS-DelegatedMSAState is set to 2.
Once the migration is complete and the service is restarted, the following events are logged in the security event log:
- Event ID 4648 – Logon – Account Name will show the dMSA account instead of the standard service account
- Event ID 4624 – Logon – Security ID and Account Name will show the dMSA account instead of the standard service account
- Event ID 4672 – Special Logon – Security ID and Account Name will show the dMSA account instead of the standard service account
If the service is restarted and the error message “Error 1069: The service did not start due to a logon failure” appears, verify the registry key DelegatedMSAEnabled is set correctly. You may also see the following in the security event log:
- Event ID 4625 – Logon – Account Name is the legacy service account, and the failure reason is Account currently disabled
If you run into any issues, you can back out the changes quickly (this is where one of the real benefits comes in).
- Undo-ServiceAccountMigration reverts the accounts back to the state where the accounts are still linked but the standard service account is enabled and being used for authentication.
- Reset-ServiceAccountMigration resets the accounts to where they are not linked, and you have two separate accounts.
One important note: You need to exclude the disabled service account from any automated cleanup processes, as the account is required unless all servers are reconfigured to use the dMSA account.
Requirements for a dMSA account:
- Must have a single Windows Server 2025 DC that is discoverable by the client or member server. It is recommended to have at least two for redundancy.
- A KDS root key must be generated on the DC before a dMSA is created.
- All clients and/or servers must be running on dMSA-supported OSs. Currently, dMSAs are supported only on Windows Server 2025.
Conclusion
While there are many benefits that come from the updates with Windows Server 2025, this article focused on two that can improve both your security and scalability. Using a 32k database page size in AD DS significantly enhances scalability. It reduces page fragmentation and supports larger objects more efficiently. And dMSAs offer enhanced security by binding authentication to specific machine identities, which helps prevent credential harvesting attacks like Kerberoasting. They also simplify the migration from standard service accounts to dMSAs by removing the need to reconfigure services manually on a server.
Whether you can benefit from the increased scalability in the AD database, want to take advantage of the increased security with dMSAs, or want to take advantage of some of the other updates, the enhancements to Windows Server 2025 are exciting. While upgrading an OS on DCs and forest functional levels can be a daunting task, there are some great benefits that come with Windows Server 2025 that may be worth it for your organization.
If you need help understanding the benefits specific to AD or in planning your upgrade to Windows Server 2025, contact the experts at Ravenswood Technology. We are happy to help!
