Collections
Deploying Active Directory
Security
Compability Access Group

Compability Access Group

The Pre-Windows 2000 Compatible Access group is a security group introduced with Windows 2000 to maintain backwards compatibility for applications or services designed for Windows NT.

In this article, we’ll walk through why the default settings of this group are now considered insecure and how best to migrate to a more secure security posture.

The Problem

In its default configuration, the Pre-Windows 2000 Compatible Access group grants any authenticated account whether a user or computer account, with the ability to view all attributes of all objects within Active Directory; assuming no modifications have been made to the permissions of the directory.

Put another way, if a hacker gained access to either a domain-tied user account or the SYSTEM account on domain-joined workstation, they would be able to enumerate across the domain and view every setting on every user, group and computer object.

While not a (further) compromise in and of itself, it provides the hacker with a treasure trove of information to help move laterally across the domain.

ℹ️
For a in-depth discussion of the history and current concerns with the Pre-Windows 2000 Compatible Access group I highly recommend Semperis’ article.

The fix for this is easy, but preparations are required.

The Fine Print

At first glance, clearing this group would lead you to believe that:

  1. Enumeration will no longer be possible.
  2. Access to attributes outside of your account will be restricted.

Unfortunately this is not true.

Once complete, clearing this group will only reduce the amount of available information when enumerating the domain. Specifically, more sensitive attributes such as password reset dates will be restricted from view but a user’s contact details will still be visible. Additionally this change will have no effect on viewing any group attributes including membership information.

Restricting Access

Restricting access is as simple as clearing the Pre-Windows 2000 Compatible Access group however before we do, we first need to make sure these changes will not adversely affect existing services which rely on these additional permissions to function correctly. Some services which I can personally confirm will be affected include:

  1. Fortinet’s Active Directory Connector for EMS.
  2. Snipe-IT.
  3. Various printer tie-ins.

To approach this issue, I recommend adding all of your service accounts (user or (g)MSA accounts) to the Pre-Windows 2000 Compatible Access group. Once included clear out the default groups and then systematically remove each service account, testing for functionality, including login and synchronization.

Locate the Group

First locate the Pre-Windows 2000 Compatible Access security group and view its members:

  1. Open Active Directory Users & Computers.
  2. Select the Builtin OU.
  3. Locate the Pre-Windows 2000 Compatible Access security group and open its Properties.
  4. Select the Members tab.

By default, you’ll likely see a mix of the following members:

  • Authenticated Users
  • Everyone
  • Anonymous Users

Add Service Accounts

Add any service accounts (aka. user accounts) or (g)MSA accounts of the third-party services which may rely on this group to function.

Remove Default Groups

Remove the default Authenticated Users group from being a member of the Pre-Windows 2000 Compatible Access group. If you have other groups added such as Everyone or Anonymous Users remove those as well.

Test

Remove one service account and test the application’s functionality. Ensure you test any synchronization functionality not just signing in or out. If its affected, re-add the service account.

Finalize

After walking through all service accounts, you now know which applications were affected by this change. I recommend adding all of these accounts into a central group for easy management and documenting the purpose of the group.

Known Issues

One issue I encountered after clearing the Pre-Windows 2000 Compatible Access group was with regards to Remote Desktop Services running on a Windows Server 2016 host.

After implementing the above changes, I found I could no longer sign-in via the RDS Web Client. To resolve this issue I had to add the server’s computer object into the RAS and IAS Servers security group.

  1. Open Active Directory Users & Computers.
  2. Browse to the builtin Users OU.
  3. Locate the RAS and IAS Servers security group.
  4. Add the RDS server as a member of this group.
Administrative RightsDisable TLS 1.0 & 1.1