Pre-Windows 2000 Compatible Access: Removing Authenticated Users Safely

Pre-Windows 2000 Compatible Access is a built-in Active Directory group that grants its members read access to every user and group in the domain. When it contains Authenticated Users, every authenticated account, including accounts from trusted domains, gets that access. Fix it by removing Authenticated Users from the group after confirming no legacy application depends on it.

What the scanner is actually detecting

This is a directory configuration finding, not a host vulnerability. The check reads the member attribute of the built-in group whose well-known SID is S-1-5-32-554 and looks for the Authenticated Users SID, S-1-5-11. Active Directory stores that well-known principal as a foreign security principal, so the member value looks like CN=S-1-5-11,CN=ForeignSecurityPrincipals,DC=contoso,DC=com. The result applies to the whole domain, whichever domain controller answered the query.

The two vendors disagree, and you should know that before opening a change ticket. PingCastle describes removal as a “special hardening measure” because it can have side effects, and in the rule source it triggers on presence with zero points at maturity level 5. Tenable’s guidance states that Authenticated Users in this group does not pose a security risk and recommends against removing it, because doing so can reduce visibility of AD attributes for software, including Tenable Identity Exposure itself.

Real-world risk

Microsoft documents that members of this group have read access to all users and groups in the domain, and that the group exists for backward compatibility with Windows NT 4.0 and earlier. In domains created in the Windows 2000-only permissions mode, Authenticated Users is the group’s default member, so on most domains this finding describes the stock configuration rather than something an administrator broke.

The exposure is authenticated reconnaissance. Nobody gets in without credentials; that is the separate, more serious Everyone and Anonymous Logon case. What the membership does is give every domain user and computer, plus any principal from a trusted domain (Microsoft’s definition of Authenticated Users covers all trusted domains), the extra read permissions this group holds on user and group objects. PingCastle adds that the membership can increase the impact of legacy protocol flaws, citing a PrintNightmare patch bypass on domain controllers.

Treat it as a low-priority hardening item for mature environments, not an urgent fix. It belongs with other tier 0 work in your Windows Server hardening checklist, scheduled after dependencies have been checked.

How to confirm it

From any machine with the ActiveDirectory PowerShell module (RSAT), query the group by SID so the command also works on localized domain controllers where the group name is translated:

Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
$au = "CN=S-1-5-11,CN=ForeignSecurityPrincipals,$domainDN"

$members = (Get-ADGroup -Identity 'S-1-5-32-554' -Properties member).member
$members                  # full member list
$members -contains $au    # True means the finding is valid

On an English-language domain controller, the classic command gives the same answer in friendlier form:

net localgroup "Pre-Windows 2000 Compatible Access"

Look for NT AUTHORITYAuthenticated Users, and note anything else listed. Everyone or ANONYMOUS LOGON is a bigger problem than this finding, and named user or computer accounts mean someone added them for a reason you need to find out.

How to fix it

Step 1: Record the current membership

(Get-ADGroup -Identity 'S-1-5-32-554' -Properties member).member |
  Out-File C:Tempprewin2000-members-before.txt

Step 2: Find what depends on the group

• Applications that read tokenGroupsGlobalAndUniversal (TGGAU). Microsoft KB 331951 explains that functions such as AuthzInitializeContextFromSid and LsaLogonUser read this attribute, and that access to it historically came through this group. Callers running as ordinary accounts fail with access denied once it is gone. The documented alternative is the Windows Authorization Access Group (S-1-5-32-560).
• AD CS with certificate manager restrictions. PingCastle’s rule documentation points to guidance that a CA on a member server with Restrict certificate managers enabled (CA properties, Certificate Managers tab) needs its computer account in this group.
• Legacy devices and services that look up users and groups with an ordinary domain account: NT4-era tools, older NAS appliances, Samba-based file servers and legacy remote access servers.
• AD security and reporting tools running under unprivileged service accounts. Tenable explicitly lists its own product; check your other vendors’ requirements.

For TGGAU readers, move the service or computer account into the Windows Authorization Access Group. Microsoft notes that in domains upgraded from Windows 2000 this group was not automatically granted access to TGGAU, so check that the permission exists first:

$acl = Get-Acl -Path "AD:$((Get-ADDomain).DistinguishedName)"
$acl.Access | Where-Object { $_.IdentityReference -like '*Windows Authorization Access*' } |
  Select-Object IdentityReference, ActiveDirectoryRights, InheritanceType

Add-ADGroupMember -Identity 'S-1-5-32-560' -Members 'svc-reporting'   # computer accounts end in $

Adding accounts directly to Pre-Windows 2000 Compatible Access also works, but PingCastle’s A-PreWin2000Other rule will flag every account you add, so reserve that for dependencies you cannot solve any other way and record them as exceptions.

Step 3: Remove Authenticated Users

In Active Directory Users and Computers: select the domain, open the Builtin container, open Pre-Windows 2000 Compatible Access, go to the Members tab, select Authenticated Users, click Remove, then OK. Or in PowerShell, as a Domain Admin:

$domainDN = (Get-ADDomain).DistinguishedName
$au = "CN=S-1-5-11,CN=ForeignSecurityPrincipals,$domainDN"
Set-ADGroup -Identity 'S-1-5-32-554' -Remove @{member = $au}

The group itself cannot be deleted or renamed; you are only changing its membership.

Step 4: Handle the other members

If Everyone or Anonymous Logon is also a member, removing Authenticated Users achieves nothing, because Everyone covers every authenticated user anyway. PingCastle’s A-PreWin2000Anonymous guidance is to remove Everyone and Anonymous Logon first. Review any named accounts the same way as in Step 2.

Step 5: Let the change take effect

The change replicates to every domain controller, but existing sessions keep the access token they were issued, so breakage can appear hours or days later as sessions re-authenticate. PingCastle’s guidance for the sibling rules is to reboot each domain controller after changing this group’s membership. Doing that inside the change window surfaces problems while the change team is still watching.

How to verify the fix and rescan

1. Confirm every domain controller has the new membership:

   Get-ADDomainController -Filter * | ForEach-Object {
     $m = (Get-ADGroup -Identity 'S-1-5-32-554' -Properties member -Server $_.HostName).member
     [pscustomobject]@{ DC = $_.HostName; AuthUsersPresent = [bool]($m -match '^CN=S-1-5-11,') }
   }

2. Rerun the healthcheck, for example PingCastle.exe –healthcheck –server contoso.com, and confirm A-PreWin2000AuthenticatedUsers is gone.
3. Exercise every dependency found in Step 2: a certificate request if you restrict certificate managers, a NAS or Samba share permission lookup, a VPN or dial-in logon, and the reports your AD tools produce.
4. Watch application logs and help desk tickets for access denied errors for at least a full business cycle.

What can break and how to roll back

• Services calling Authz or S4U APIs under ordinary accounts fail when they cannot read TGGAU.
• A member server CA with Restrict certificate managers enabled loses the group membership that guidance says it needs.
• NAS, Samba and legacy access servers may fail to resolve group membership for users.
• AD auditing tools, including Tenable Identity Exposure, may report less than before.

Rollback is a single command, followed by the same domain controller reboot or session refresh:

$domainDN = (Get-ADDomain).DistinguishedName
$au = "CN=S-1-5-11,CN=ForeignSecurityPrincipals,$domainDN"
Set-ADGroup -Identity 'S-1-5-32-554' -Add @{member = $au}

You can also add Authenticated Users back from the Members tab in Active Directory Users and Computers, and use the file saved in Step 1 to restore any other members exactly.

Common false positive reasons

• It is Microsoft’s default. The finding is accurate, but it describes the stock configuration. If you decide to keep the membership, record it as an accepted risk rather than a scanner error.
• Replication lag. PingCastle queries one domain controller. A scan that hit a DC which had not yet received the change still reports the member.
• Wrong rule. After removal, Tenable’s indicator or PingCastle’s A-PreWin2000Anonymous and A-PreWin2000Other can still fire because of Everyone, Anonymous Logon or added accounts. Those are different findings.
• Name-based scripts on localized DCs. Custom checks that search for the English group name return nothing on a translated domain controller; query SID S-1-5-32-554 instead.

FAQ

Is Authenticated Users in this group a vulnerability?

Not in the sense of an exploitable flaw. It is the default membership, and it widens what an already authenticated account can read. PingCastle treats removal as advanced hardening and Tenable recommends keeping it.

Can I delete the Pre-Windows 2000 Compatible Access group?

No. Microsoft states the group cannot be renamed, deleted or removed. You can only change its members.

Do I have to reboot the domain controllers?

Existing sessions keep their old token until they re-authenticate. PingCastle’s sibling rules recommend rebooting each DC after a membership change, which also exposes any breakage while you are still watching.

Does this affect users in trusted domains?

Yes. Authenticated Users includes authenticated principals from any trusted domain, so removal also withdraws the extra read access from them.

Tracking this finding across many hosts

This is a domain-wide setting, but it tends to land in the same backlog as thousands of host findings. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners into one queue and merges duplicates per scanner, so two tools reporting the same condition stay as separate records. Its AI triage suggests likely false positives with supporting evidence for a human to decide, which suits a finding like this where the correct outcome may be a documented exception rather than a change.

Sources

• Microsoft Learn: Active Directory security groups (Pre-Windows 2000 Compatible Access, Windows Authorization Access)
• Microsoft Learn: Security identifiers
• Microsoft Learn: Some applications and APIs require access to authorization information on account objects (KB 331951)
• Tenable: Accounts Using a Pre-Windows 2000 Compatible Access Control
• PingCastle: rule descriptions (A-PreWin2000AuthenticatedUsers and related rules)