Understanding the Risks of Pre-Windows 2000 Compatibility Settings in Windows 2022

The number and scope of confusing and risky security settings in Active Directory are becoming better known with every new cyberattack. While it’s true that many of these vulnerabilities can be attributed to risky configurations that have accumulated in legacy environments over time, IT teams still need to watch for problematic settings that come out of the box in Windows Server 2022.

One 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 this setting is so problematic, let’s look at the history of delegating permission and assigning policies in AD so you can make an informed decision about how to handle this setting in your organization.

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

Never thought I’d write a new article that rhymes with NT. There’s a good reason that we don’t talk about Windows NT these days. It’s history. It’s technology from last century. While it was a great step forward for Microsoft and equated its entry into the enterprise market in 1993, the Windows NT operating system has been replaced with newer and safer versions since the release of Windows 2000 at the very beginning of this century. And on the server side, Microsoft even kept to the naming standards of adding the year close to the release date to the name of the OS. So, just a few weeks back, Windows Server 2022 was released.

A key change with 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, AD introduced domain trees and forests, and allowed creation of a hierarchical structure of Organizational Units for objects within a domain, which were useful for delegating permissions and assigning specific policies.

Just as important was another key difference from its predecessor: AD introduced the ability to set permissions not only at the object level (e.g., users, groups, computers, etc.) but also at the attribute level of each object (e.g., department, phone number, group memberships, etc.). Not yet possible in Windows NT, the admins could now nicely differentiate between being able to “read” or “write” all attributes of a given AD object, or just the ones relevant for a given task.

This capability was key for companies to allow following 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 them more permissions to access data that they don’t need. Otherwise, a user—especially a compromised user—might misuse those permissions and hurt the company.

In any fileserver or SharePoint structure, where documents for users of the whole company are shared, it is the most natural thing to follow that “least-privilege” rule. For example, users must be made a member of a proper security group to allow viewing documents that contain financial or otherwise sensitive data of a company—or even listing 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 the “Authenticated Users” or “Everyone” security principals.

Unfortunately, most companies are not treating their AD the same way. And part of the reason is the default permissions, with which Microsoft has been—and still is—deploying new AD domains. Instead of naming it the “Less Secure Windows NT permissions” group, Microsoft decided to introduce a group called “Pre-Windows 2000 compatible access” group when they released Windows 2000.

The problem: Even in new deployments of a brand-new AD forest on Windows Server 2022 servers, Microsoft chose to pre-populate the “Pre-Windows 2000 compatible access” group with the “Authenticated Users” security principal.

 

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

As the name implies, the “Pre-Windows 2000 compatible access” group was created to be just that: to be compatible with Windows NT, i.e., to grant object-level permissions on objects in your Active Directory that are compatible with the less secure Windows NT, instead of using the more granular attribute-level permissions. To shorten this article somewhat, I’ll just call it the “Pre-Win2K” group from now on.

Microsoft does not hide the potentially risky implications in the description of the group, where it says: “A backward compatibility group which allows read access on all users and groups in the domain.”

 

And because Microsoft wants to “help” you with that backward compatibility as much as they can, they grant 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.

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 (Windows NT). This option was shown to you in the earlier OS when promoting a new AD forest—and if you had indeed chosen this option a few years ago, you would even have added “Anonymous Users” and “Everyone” to the Pre-Win2Kgroup and thus granted them powerful read access to your AD—i.e., users would not even have 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.

Is it OK to leave “Authenticated Users” in the Pre-Win2Kgroup in Windows Server 2022?

You are granting “full READ” permissions on the users and groups with this configuration, which means that any user and domain-joined computer can read the respective data on any such object. Note that every domain-joined computer is also an Authenticated User in your AD forest. This means that 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 that same access to your AD as your users.

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

For group objects, the Pre-Win2Kpermissions don’t make a difference, as Authenticated Users is anyways granted full READ on every group object.

This means that even if you remove Authenticated Users from the Pre-Win2Kgroup, all your users will still be able to read the memberships of ALL groups in your AD forest. Unless you were to 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, which I’ll cover in a different blog.

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

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 last logon or when the password was last changed. Beware that when you’re granted read access to the userAccountControl attribute, this also allows you to figure out which users have the “PasswordNotRequired” flag set and other information that might allow 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 AD 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 AD 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 AD forest. The following images show how easy this is:

 

 

 

Should I remove Authenticated Users from the pre-Win2Kgroup in Windows Server 2022?

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. This is just one of many important steps 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-Win2Kgroup. 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 not affected by this change. AD admins don’t need these permissions, either, as they are otherwise granted the same and more permissions.

Nonetheless, removing Authenticated Users from the Pre-Win2Kgroup is not a change that you just quickly perform in your AD on a Monday morning. First, test the potential impact of the change in your own environment as you might be using tools or solutions that have come to expect those pre-Win2Kpermissions 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-Win2Kgroup:

• Some security scanning tools that are not executed with a privileged account or are running in the security context of a machine might likewise be challenged to read those 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 user or computer account to the pre-Win2Kgroup, or grant the required permissions separately.
• Beware of applications that bind to AD 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 may need to be addressed with dedicated read permissions for your ADFS servers or by utilizing 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 once Authenticated Users is removed from the pre-Win2Kgroup. While the true value of the “Effective Access” tab is generally questionable, since it fails to properly consider nested groups, if you still want to use it, you could again add your file-server computer accounts to the pre-Win2Kgroup or otherwise grant the respective read-permissions on user objects.
• Ivanti File Director client has issues reading the homeDirectory and userAccountAttribute, so users will fail to logon to this software unless you either add the account it uses to the Pre-Win2Kgroup, or grant the proper permissions directly on your user objects.

An additional benefit of emptying your Pre-Win2k group is that it would even have protected you from the PrintNightmare vulnerability prior to you having patched your Domain Controllers with the critical CVE-2021-1675 patch from this summer (also see https://www.theregister.com/2021/07/01/printnightmare_windows_fix).

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. And of course neither are “Everyone” or “Anonymous Users.” Keeping the group empty—or at least populated only with a few dedicated users and computers that may require it —will certainly help to reduce the attack surface of your AD. This configuration makes it much harder for intruders to enumerate weak accounts and extract other security sensitive data from your AD.

Key takeaways for pre-Win2K compatibility settings in Windows Server 2022 and earlier OSs

Active Directory is full of security minefields that cyberattackers can exploit. (To identify potential security gaps in your environment, download Purple Knight, a free AD security assessment tool that identifies 80+ indicators of exposure or compromise with guidance on how to address them.) But adopting 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-Win2K compatibility:

1. Don’t think twice to remove Anonymous and Everyone from the pre-Windows 2000 compatible access group in every domain of your AD forest.
2. 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.
3. Remove the default read permissions for Authenticated Users from sensitive groups to restrict who can enumerate their memberships. Check my upcoming 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 AD 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 Compatibility Settings in Windows 2022 appeared first on Semperis.

*** This is a Security Bloggers Network syndicated blog from Semperis authored by Guido Grillenmeier. Read the original post at: https://www.semperis.com/blog/security-risks-pre-windows-2000-compatibility-windows-2022/