Guido Grillenmeier

Properly securing your Active Directory (AD) has never been easy. The same is true for granting rights to change things in AD. After all, you don’t want your most privileged admin accounts (e.g., Domain Admins) performing everyday directory operations, but granting too many privileges threatens your AD security stance. That’s where delegation of permissions to AD objects comes in.

The granularity of permissions in Active Directory is powerful but can be overwhelming. Over the years, Microsoft has added a few options and rights to enable administrators to grant capabilities at a more granular level. However, efforts to provide backwards compatibility with existing delegated permissions have also made securing your AD even trickier. I’ve written previously about some of the potential AD security consequences. Unfortunately, these issues remain in the most recent OS version, Windows Server 2025.

Here’s how you can use Windows password options with delegation management to support your user management structure without sacrificing the security of your Active Directory.

Delegation of user management and the principle of Least Privilege

When designing an AD delegation model, administrators need to carefully differentiate who can see or do what in which part of the directory. Delegated administrators should be granted only the least privileges they require to perform their necessary administrative tasks—no more, no less.

For example, say the role of a helpdesk operator is to reset users’ passwords. Operators do not need Full Control of the organizational unit (OU) containing all user accounts. Doing so would allow the helpdesk operators to perform many other changes to user accounts and other objects in that OU. Even if you want to grant regional operators permissions—up to or including Full Control—to manage more user aspects, you still want them to follow your overall security rules, especially concerning different password options for the users they manage.

Password options management vs password policy

The original permissions model that Microsoft released with Windows Server 2000 was impressively complete and enabled admins to grant capabilities down to an object’s attribute (as opposed to just the object itself). However, limitations around restricting the setting of specific password options had the potential to conflict with corporate password policy.

The issue with the original AD release is that it could not distinguish between the following security-sensitive password management options (Figure 1):

  • Store password using reversable encryption
  • Password never expires
  • Password Not Required Bit
Figure 1: Critical password account options in Account tab

The Password Not Required Bit is unavailable in native Windows UIs. But the bit can be set programmatically; for example via PowerShell:

Get-ADUser -Identity Bob | Set-ADUser -PasswordNotRequired $true

These options, when used, can easily undermine your corporate password policy, putting your company at risk. The options don’t have their own attribute where they are stored but instead are part of a user’s userAccountControl attribute in AD. This attribute is a collection of various settings that control many aspects of a user account by flipping a binary switch to the correct position.

Unfortunately, any delegated permission that grants an operator Full Control over users in an OU—or even simply grants the right to Write AccountRestrictions on those user objects—also allows the operator to set these sensitive password options on any accounts under their control.

Allowing delegated admins to choose these password options for accounts that they manage often leads to unpleasant results. For example, delegated administrators who are not security-aware might configure a high percentage of their users with the Password never expires option simply to avoid issues when users change their passwords. Naturally, such a practice undermines any password age policies set at the domain level … even those set for groups through fine-grained password policies.

The problem with Authenticated Users

Microsoft didn’t take long to combat this problem. With the release of Windows Server 2003, Microsoft introduced three new control access rights, aka extended rights:

  • Enable Per User Reversibly Encrypted Password
  • Unexpire Password (which enables the setting of the Password never expires flag)
  • Update Password Not Required Bit

In contrast to extended rights such as Reset-Password, which needs to be set directly for user objects, these three extended rights were implemented to apply at the domain level. With these rights, only operators who were granted Full Control or Write AccountRestrictions to a set of users (e.g., in an OU) in combination with one of those special password permissions on root of the domain could actually set these sensitive password options on the accounts they control.

However, Microsoft being Microsoft, the need for backward compatibility with existing delegated permissions and the need for “things to work as they did before” took priority over encouraging customers to improve the AD security in their delegation models.

To solve this dilemma, Microsoft chose to grant the Authenticated Users group these rights at the root of the domain during the Windows Server 2003 upgrade of existing AD domains and forests. Unfortunately, it also set those permissions on any newly deployed AD domain.

Sound familiar? Yes, the Authenticated Users appears all over the place … and not always in your favor (Figure 2).

Figure 2: Default Permissions for Authenticated Users at the root of the AD domain

This has been the status quo since that Windows Server 2003 update … and it’s still happening in new AD deployments based on Windows Server 2022 and even Windows Server 2025. That means you’ll almost certainly find these default permissions still active in your AD deployment—and they are likely preventing you from tightening up password security in your Active Directory.

How to improve AD password security

So, how can you improve your AD password security? First, you’ll need to remove the default permission for Authenticated Users for those three extended rights from the root of your domains. Then, you’ll need to choose proper replacements—should you choose to delegate those permissions at all. Remember: These three extended rights must be set at the domain level. Granting them at the OU level has no effect.

My recommendation:

  1. Create a separate group for each of these sensitive extended rights.
  2. Grant each group the respective permission at the root of the domain. These groups belong in your Tier 0 OU, where only Domain Admins can make changes.
  3. In a multidomain forest, create the groups as universal groups in your root domain. That way, you can add selected users of every domain to the groups, which will then be able to grant the respective permissions in any domain.

For example, you might create the following three groups:

  • SVC-ADconfig-PerUserReversiblyEncryptedPwd
  • SVC-ADconfig-UnexpirePassword
  • SVC-ADconfig-PwdNotRequiredBit

Next, replace the extended rights granted to Authenticated Users with each corresponding group (Figure 3).

Figure 3: Replaced Permissions with special groups per permission at the root of the AD domain

Now, suppose you want an operator, Fred, to have permissions to manage a user. You can still grant Fred Full Control or Write AccountRestrictions for all users in the OU for which he is responsible. But Fred will not be able to set any of the three sensitive password options on those user accounts.

Now, if you add Fred to the SVC-ADconfig-UnexpirePassword group, he will be able to set the Password never expires option for the users that he manages. It’s likely best not to give Fred this option, but you could if there was a valid need.

Hopefully, you already have test plans and a list of people responsible for validating the most critical apps, tools, and user- and client-management processes and a process for gathering feedback after making these permission changes. And naturally, before performing such changes in your production AD environment, you should record the current permissions and test your new settings before rolling out the changes.

Ideally, you have a solution that records all changes in your Active Directory, including the nTsecurityDescriptor attribute, which essentially stores the permission of the respective object. Even better would be a solution that can also undo such changes in AD.

Yes, full disclosure: Semperis Directory Service Protector (DSP) can do both these things. There are also publicly available scripts that you can use with your own screenshots to document your work.

Key takeaways for sensitive password options in Windows Server 2025 and earlier

Active Directory is full of security surprises. To identify potential security gaps in your environment, download Purple Knight, a free AD security assessment tool that identifies 150+ indicators of exposure and indicators of compromise and provides guidance on how to address them.

Just be aware that adopting Windows Server 2025 doesn’t necessarily mean that you leave problematic legacy settings behind. If nothing else, consider changing configuration settings related to the delegation of sensitive password options.

  1. If you have delegated the administration of user objects to non-Domain Admins, determine whether those people need the ability to set sensitive options like Password never expires on the user accounts they manage.
  2. Replace the default permissions for Authenticated Users at the domain root for the three extended rights discussed in this article with groups that only Domain Admins can manage.
  3. Selectively add delegated admins to the newly created groups—but only if there is a true business need for them to manage any of these sensitive password options.

Making these changes has little risk and big benefits for Active Directory security and effective delegation management.

Need assistance with AD Security?

Tap into Semperis expertise. Request a Security Configuration Review and our team will employ automated tools and manual methods to find misconfigurations and attack paths that an attacker could leverage to compromise your environment.

Further reading