[Updated February 14, 2024; originally published November 29, 2021] The number and scope of confusing and risky security settings in Active Directory are becoming better known with every new cyberattack. Many of these vulnerabilities can be attributed to risky configurations that have accumulated in legacy environments over time. But IT teams have still needed to watch for problematic settings that come out of the box in Windows Server 2022. Unfortunately, the same is true of the upcoming Windows Server 2025. One Active Directory setting that every IT team should immediately address is the pre-populated Pre-Windows 2000 Compatible Access group with the Authenticated Users security principal. This setting can leave an open door for intruders, as I’ll demonstrate.

To understand why the Pre-Windows 2000 Compatible Access setting is so problematic, let’s look at the history of delegating permission and assigning policies in Active Directory. That way, you can make an informed decision about how to handle this setting in your organization.

Related reading: What is Active Directory security?

To be or not to be … compatible with Windows NT?

There’s a good reason that we don’t talk much about Windows NT these days. It’s history. It’s technology from the past century.

Windows NT was a great step forward for Microsoft and equated the company’s entry into the enterprise market in 1993. But the operating system has been replaced with newer and safer versions since the release of Windows 2000 at the beginning of this century. On the server side, Microsoft has kept to the naming standard of adding the year closest to the release date.

As I write this update, Windows Server 2022 is the latest Microsoft OS. But in January 2024, the naming for the upcoming “vNext” release was (unsurprisingly) confirmed as Windows Server 2025. We expect the new OS version to be released before the end of 2024.

What changed in Windows 2000?

A key change in Windows 2000 was the replacement of the Windows NT domain concept—which was a flat directory to authenticate users and machines in a company’s network—with the much more scalable and secure Active Directory. Next to the concept of domains, Active Directory introduced domain trees and forests. The service also enabled the creation of a hierarchical structure of organizational units (OUs) for objects within a domain. This structure was useful for delegating permissions and assigning specific policies.

Another key difference was just as important. Active Directory introduced the ability to set permissions not only at the object level (e.g., users, groups, computers) but also at the attribute level (e.g., department, phone number, group memberships) of each object. Admins could now nicely differentiate between being able to “read” or “write” all attributes of a given Active Directory object or just those attributes relevant for a given task.

The key to the least privilege principle

This capability was key to enabling companies to follow the least-privilege mantra of any good security plan: Grant only as many permissions to your users as they need to do their job. Don’t grant users more permissions to access data that they don’t need. Otherwise, a user—especially a compromised one—might misuse those permissions and hurt the company.

In any file server or SharePoint structure that shares documents for users throughout the company, the most natural approach would be to follow that least-privilege rule. For example, users must be made members of a proper security group to allow them to view documents that contain financial or otherwise sensitive data of a company—or to even list the file’s existence.

You might still choose to make specific, non-sensitive data available to all your users via some public document share that all users have access to, without needing to be added to a special group. That access would typically be granted to your Domain Users group or even to the Authenticated Users or Everyone security principals.

Unfortunately, most companies do not treat Active Directory this way. Part of the reason is due to the default permissions with which Microsoft has deployed—and still deploys—new Active Directory domains.

What is the Pre-Windows 2000 Compatible Access group?

Take the Pre-Windows 2000 Compatible Access group. Microsoft decided to introduce this group—which would more appropriately be called the Less Secure Windows NT Permissions group—when it released Windows 2000. The problem: Even in a new deployment of a brand-new Active Directory forest on Windows Server 2022 servers—and yes, Windows Server 2025 servers—Microsoft pre-populates the Pre-Windows 2000 Compatible Access group with the Authenticated Users security principal.

Default membership in the Pre-Windows 2000 Compatible Access group in newly deployed Active Directory domain on Windows 2025 Server

So, why does this matter, and why should you care?

As its name implies, the Pre-Windows 2000 Compatible Access group was created to be compatible with Windows NT. In other words, the group enables you to grant object-level permissions on Active Directory objects that are compatible with the less secure Windows NT, instead of using more granular attribute-level permissions. Microsoft does not hide the potentially risky implications in the description of the group: “A backward compatibility group which allows read access on all users and groups in the domain.

Description of the pre-Windows 2000 compatible access group does not hide its purpose

And because Microsoft wants to “help” you with that backward compatibility as much as possible, it grants full READ permissions for the respective objects (users and groups) right on the top of each domain in your forest, allowing it to inherit down the whole OU hierarchy.

Permissions on root of each domain

These default permissions are set, although Microsoft no longer asks you whether you want to deploy your new AD forest in a way that is compatible with pre-Windows 2000 versions of Windows (i.e., Windows NT). This option was available in the earlier OS when promoting a new AD forest. If you had indeed chosen this option a few years ago, you would even have added Anonymous Users and Everyone to the Pre-Windows 2000 Compatible Access group, thus granting those security principals powerful read access to your Active Directory. Users would not even need to authenticate to read your AD! I certainly hope that you’ve already cleaned up those legacy permissions, which every security check would have warned you about by now.

Can you leave Authenticated Users in the Pre-Windows 2000 Compatible Access group?

Yes, you should remove Authenticated Users from the Pre-Windows 2000 Compatible Access groups in every domain of your AD forest—even though Microsoft still adds it as a default for new AD deployments. Leaving Authenticated Users in the group grants full READ permissions, enabling any user and domain-joined computer to read the respective data on any such object.

Note that every domain-joined computer is also an Authenticated User in your Active Directory forest. Even if no user is logged on to those computers, a process—possibly a trojan—running in the system context of a domain-joined computer has the same access to Active Directory as your users do.

To better understand the impact, we must dig a bit deeper and check which permissions Authenticated Users is granted by default on all the user and group objects in your domain. After all, whenever you create an object, Active Directory adds the default security descriptor for the given object to the new object. Those permissions are explicitly granted on the object (i.e., not inherited). As such, they have the highest priority when the overall permissions to the object are determined. Note that this configuration also grants those default permissions a higher priority than an inherited deny permission, which often confuses admins.

Permissions on group objects

For group objects, the Pre-Windows 2000 Compatible Access permissions don’t make a difference. Authenticated Users is granted full READ on every group object.

Default permissions on group objects

Even if you remove Authenticated Users from the Pre-Windows 2000 Compatible Access group, all your users can still read the memberships of all groups in your Active Directory forest. Unless you remove that permission from selected groups, any user in your forest—including a potential intruder—can easily determine who is a member of any group in your domain. For your most sensitive AD groups, such as Domain Administrators or Enterprise Administrators, you’ll need a few extra steps to remove this READ permission. (These groups are controlled by permissions on a special object called AdminSDholder. You can learn more about AdminSDholder and Active Directory security in this white paper.)

Permissions on user objects

However, the situation is quite different for user objects. The default permissions granted to Authenticated Users on user objects are also quite extensive, including reading all general and personal information attributes. However, the permissions are less pervasive than allowing the reading of all attributes of the users.

Default permissions on user objects

This means that various sensitive user attributes can NOT be accessed by Authenticated Users via those default object permissions. These include the userAccountControl, memberOf, and all logon-related attributes, such as the last logon or when the password was last changed. Beware that when you’re granted read access to the userAccountControl attribute, you are allowed to figure out which users have the PasswordNotRequired flag set and other information that might enable discovery of unsecure objects in your AD forest. Users who are configured with the PasswordNotRequired flag might have been created ages ago for some application and might truly have no password if the Active Directory admin chose to set it this way. As such, they are easy bait for an intruder.

So, if you choose to keep Authenticated Users in your Pre-Windows 2000 Compatible Access group, every user and computer in the domain is automatically assigned the permissions of that group at logon. And with this assignment, any process—including malicious code that an intruder might execute on a domain-joined client without any logged-on user—is allowed to enumerate any user attributes in your domain.

While intruders often use specific tools and scripts to scan Active Directory and find vulnerabilities, don’t think that your normal users would have a hard time doing the same. Even without admin rights on their client, they can just download the latest Sysinternals AD explorer from Microsoft (https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer) and happily sniff around in your Active Directory forest. The following images show how easy this is.

Sysinternals AD Explorer logon with a simple domain account
Sysinternals AD Explorer object and attribute viewer with Authenticated Users still in the Pre-Windows 2000 Compatible Access group
Sysinternals AD Explorer object and attribute viewer with Authenticated Users removed from the Pre-Windows 2000 Compatible Access group

Removing Authenticated Users from the Pre-Windows 2000 Compatible Access group

This step is just one of many in increasing the security posture of your Active Directory. There is no need these days to maintain compatibility with the Windows NT security model.

Your users don’t need the permissions granted by the Pre-Windows 2000 Compatible Access group. They can still log on. Domain-joined computers and servers also don’t need the permissions; they will keep working in your domain just fine. Group Policy processing is also unaffected by this change. Active Directory admins don’t need these permissions, either, as they are otherwise granted the same and more permissions.

Nonetheless, removing Authenticated Users from the Pre-Windows 2000 Compatible Access group is not a change that you just quickly perform in your Active Directory on a Monday morning. First, test the potential impact of the change in your own environment. You might be using tools or solutions that have come to expect those pre-Windows 2000 permissions to be configured in your AD and are using them for legitimate reasons.

Examples of solutions or tasks that by default use the permissions granted via Authenticated Users in the Pre-Windows 2000 Compatible Access group:

Some security scanning tools that are not executed with a privileged account or are running in the security context of a machine might be challenged to read the security-sensitive user attributes discussed in this article. As a result, those tools might fail to warn you if a user is configured with the PasswordNotRequired flag. You can choose to add the respective service account used by the tool or its computer account to the Pre-Windows 2000 Compatible Access group, or you can grant the required permissions separately.

Beware of applications that bind to Active Directory via LDAP to enumerate group memberships for security within the app.

If you use AD Federation Services (ADFS), depending on your setup you could impact the WebForms Authentication, which might need to be addressed with dedicated read permissions for your ADFS servers or by using the Windows Authorization Access Group (WAAG).

When using the Effective Access tab in the advanced security settings on your file servers to check what permission a given user may have on a folder, the server uses its computer account to read the group memberships of the user. This process will fail after Authenticated Users is removed from the Pre-Windows 2000 Compatible Access group. The true value of the Effective Access tab is generally questionable, as it fails to properly consider nested groups. However, if you still want to use it, you could again add your file-server computer accounts to the Pre-Windows 2000 Compatible Access group or otherwise grant the respective read-permissions on user objects.

Ivanti File Director client has issues reading the homeDirectory and userAccountAttribute. Users will fail to log on to this software unless you either add the service account it uses to the Pre-Windows 2000 Compatible Access group or grant the proper permissions directly on your user objects.

An additional benefit of emptying your Pre-Windows 2000 Compatible Access group: Doing so would have protected you from the PrintNightmare vulnerability before you patched your domain controllers with the critical CVE-2021-1675 patch from the summer of 2021. Likewise, emptying the group will protect you from other Zero Day vulnerabilities that use these default permissions in Active Directory.

In any case, for normal and safer operations of your Active Directory, Authenticated Users is not required to be a member in the Pre-Windows 2000 Compatible Access group. Neither is Everyone or Anonymous Users. Keeping the group empty—or at least populated with only the few dedicated users and computers that might require it —will certainly help to reduce the attack surface of your Active Directory. This configuration makes it much harder for intruders to enumerate weak accounts and extract other security sensitive data from your AD.

How to fix this issue in a large environment

Writing about the need to improve your security is easy. But actually changing a default group membership that Microsoft has decided to leave in place—even in its newest OS release—can be quite a challenge, especially in large environments.

As already mentioned, start by protecting your most critical groups (e.g., Domain Admin, Enterprise Admin) from being read by everyone. After all, neglecting to do so makes it tremendously easy for intruders to plan proper attack paths against the most sensitive user objects in your Active Directory forest. This task is best addressed by updating the AdminSDholder template, which is used to update the permissions on all these sensitive objects.

In smaller environments, “cleaning” the Pre-Windows 2000 Compatible Access group might be possible over a weekend—with some initial testing of the core business systems to confirm that everything is still working as expected. But this approach can be a bit daunting in large enterprises. After all, you don’t want to cause a larger business impact simply because you were tightening your Active Directory security.

As with any large task, I recommend splitting up the work. Even though the choice is ultimately a binary one—the Authenticated Users is either in the Pre-Windows 2000 Compatible Access group or not—the permissions for this group are inherited to different objects in your Active Directory forest from the root of each domain in that forest. So, you do have the option of locking down individual OUs by:

Disabling inheritance on the OUs

Copying all existing permissions

Removing only the Pre-Windows 2000 Compatible Access group from the resulting set of explicit permissions

For the objects in the respective OU, the effect is the same as if you had removed Authenticated Users from the group at the root of the domain. In other words, the Pre-Windows 2000 Compatible Access group has no more permissions on the objects in the respective OU.

Naturally, you’ll want to test the impact of such permission changes before performing them. I suggest that you record the current permissions on any OU that you want to modify. It’s helpful to 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! Semperis Directory Service Protector (DSP) is such a tool, but you can also use publicly available scripts and your own screenshots to document your work.

Ideally, you have test plans and stakeholders ready to validate the most critical apps, tools, and user- and client-management processes. You’ll need to gather feedback after making the permission change. Running your tests against objects in the first locked down OU will provide insights into potential problems that you must address before locking down another OU, and so on.

Eventually, you’ll be ready to remove the Authenticated Users group completely from the Pre-Windows 2000 Compatible Access group. When you reach that point, be sure to re-enable permission inheritance on the OUs that you used for testing. Revert them to the previous explicit permissions that were granted at that level. Using the proper tools to catch all changes in your Active Directory forest will reduce your efforts during this step, too.

Key takeaways for Pre-Windows 2000 Compatible Access settings in Windows Server 2025 and earlier

Active Directory is full of security minefields that cyberattackers can exploit. (To identify potential security gaps in your environment, download Purple Knight, a free Active Directory security assessment tool that identifies 100+ indicators of exposure or compromise with guidance on how to address them.) But adopting Windows Server 2025 or Windows Server 2022 doesn’t necessarily mean that you leave all those legacy settings behind.

If nothing else, consider making these changes in configuration settings related to pre-Windows 2000 compatibility:

Don’t think twice to remove Anonymous and Everyone from the pre-Windows 2000 compatible access group in every domain of your AD forest.

Do the same for Authenticated Users but beware of the potential impact and be ready to re-populate the group with systems or users that might rely on the permissions it grants them.

Remove the default read permissions for Authenticated Users from sensitive groups to restrict who can enumerate their memberships. Check my blog on how to do so for the built-in AD admin groups.

You must decide on your own whether to remove the Authenticated Users group to increase your Active Directory security posture. You might choose to accept the risk and keep living with those old Windows NT-like permissions in your Active Directory. But follow that path only after carefully understanding the potential danger.


The post Understanding the Risks of Pre-Windows 2000 Compatible Access Settings appeared first on Semperis.