Pre-Windows 2000 Compatible Access Group Active Directory

What Is the Pre-Windows 2000 Compatible Access Group?

The Pre-Windows 2000 Compatible Access group in Active Directory can grant broad directory read access, but the attributes a caller can read depend on the object's ACEs. “Directory-wide read” does not mean every secret is readable, and membership does not guarantee anonymous LDAP enumeration. Microsoft documents both object access checks and a separate LDAP restriction. Network management access requirements, anonymous LDAP restrictions.

Pre-Windows 2000 Compatible Access is the built-in security group identified by S-1-5-32-554, located under CN=Builtin in the domain. Microsoft describes it as a compatibility mechanism for Windows NT 4.0 and earlier clients, with read access to user and group information. It is not protected by AdminSDHolder, and Microsoft's group table says it cannot be moved out of its default container. Review its members rather than deleting or relocating the group. Active Directory security groups.

The useful investigation has four questions: which principals are members, which permissions they receive, which interface accepts their requests, and which applications still need those reads. Keep those answers separate in the change record. A member count supplies the first clue; it does not settle the other three.

Set the review's success criteria before changing access. For an unnecessary anonymous path, the desired result is a documented reduction in that path while required authenticated functions still work. For a service account, it may be replacing broad compatibility permissions with verified access to the attributes it actually requests. For an unresolved dependency, the outcome may be an owned exception and a test plan. These are proposed operational outcomes, not observations about your domain or a claim that every membership is exploitable.

Initial membership depends on domain creation

The protocol specification ties initial membership to the operating system of the domain's first domain controller and the permissions mode selected by the administrator. It documents these cases. MS-ADTS 6.1.1.4.12.14.

“Everyone is always the default” loses this distinction. Microsoft's application-access guidance also explains that adding a Windows Server 2003 DC to an existing Windows 2000 domain does not change its previous compatibility selection. An upgraded domain can therefore retain an older choice. KB331951: applications and authorization information.

Use this history to interpret a baseline, not to approve every current member. A historical default may no longer serve a business need, while a later addition may support an application. The current list cannot tell you who added an entry or why. Record “origin unknown” when deployment records and retained change logs do not answer that question.

How It Works: Membership, ACEs, and Protocol Gates

Everyone alone is not Anonymous

Microsoft's NetAPI requirements explicitly require Anonymous membership for anonymous access to group information: the normal anonymous token does not include the Everyone SID. Windows 2000 behavior and the EveryoneIncludesAnonymous=1 override are exceptions documented on the same page. On a modern system using the normal token behavior, Everyone alone is not equivalent to Anonymous Logon. Explicit Anonymous membership supplies an authorization path, subject to the interface's remaining restrictions. Network management access requirements.

Read access and enumeration have their own conditions. NetQueryDisplayInformation returns information the caller can read; it requires List Contents on the Domain object and Enumerate Entire SAM Domain on the SAM Server object in the System container. This is a concrete permission path to investigate, rather than a promise that any network client can list every object. NetQueryDisplayInformation.

LDAP has a separate gate

Windows Server 2003 introduced a default block on anonymous LDAP operations beyond binds and rootDSE searches. The seventh character of dsHeuristics, set to 2, overrides that block; operations still need ACL permission. Adding Anonymous to this group does not change that attribute. Conversely, checking the LDAP gate does not establish the safety of another enumeration interface. KB326690: anonymous LDAP operations.

For that separate mechanism, read anonymous LDAP access and the dsHeuristics gate. Its subject is the LDAP setting and bind/search verification. Here the subject is the compatibility group's authorization path. Use the linked article to investigate that gate, while validating technical decisions against Microsoft documentation.

Where the inherited read permissions come from

The published Domain-DNS default security descriptor contains permissions for RU. Microsoft's SID-string reference defines RU as the alias for Pre-Windows 2000 Compatible Access. This excerpt is from the page's Windows 2000 Server section. It shows root-level and inheritable permissions; compare the appropriate version and your domain's actual DACL before relying on it. Domain-DNS class, SID strings.

(A;CI;LC;;;RU)
(A;;RC;;;RU)
(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)

In SDDL, A and OA are allow ACE forms; CI indicates container inheritance and IO inheritance only. RP means Read Property, LC List Children, LO List Object, and RC Read Control. The rights mask and inheritance flags are separate fields, so an inherited object-specific entry should not be interpreted as an unrestricted permission on the root itself. ACE strings.

The two inherited-class GUIDs identify User and Group. Computer is a subclass of User: include computers in the review, without inventing a separate Computer-targeted ACE in this excerpt. The class references publish versioned default descriptors; the older User entry is not evidence that every current user has an identical DACL. User class, Group class, Computer class.

The full Domain-DNS descriptor also includes User property-set read ACEs. The Sam-Server reference separately shows an RU entry with RPLCLORC. These defaults explain paths to measure; they do not replace inspection of a live domain's inheritance, explicit entries, and protected objects. Domain-DNS descriptor, Sam-Server class.

Measure the Actual Group and Read Permissions

The examples below adapt documented cmdlet parameters and dsacls syntax. They have not been executed against a domain. Replace the fictional server and distinguished names with values resolved in your environment. Run them from an appropriate administrative workstation with the required tools and read permissions. Keep each command's output and errors separately so an unsuccessful lookup cannot masquerade as a clean result.

Step 1: Capture direct members

Start with the familiar English name when it exists. This adapts the membership cmdlet's documented Identity and Server parameters. Get-ADGroupMember.

Get-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" -Server "dc01.contoso.com"

Then identify the built-in group by its stable SID and request the raw member property. Microsoft's Get-ADGroup example uses this pattern with another built-in SID; this adaptation substitutes SID 554. Get-ADGroup.

Get-ADGroup -Identity "S-1-5-32-554" -Properties member -Server "dc01.contoso.com"

Use that identity for the direct membership view too. The cmdlet accepts a SID as Identity. Get-ADGroupMember identity options.

Get-ADGroupMember -Identity "S-1-5-32-554" -Server "dc01.contoso.com"

Compare the resolved members with raw references, especially where special identities or foreign security principal resolution fails. Record the group's DN and SID, the contacted DC, and each member's identity. A resolution error is not an empty group. Investigate the referenced object before drawing a conclusion or preparing a removal.

Keep this direct view for comparison with the collector's membership count. -Recursive asks a different question: the cmdlet traverses the group's hierarchy to return members without child objects. A separately recorded recursive review can help investigate nested principals, but it should not silently replace the direct baseline. Get-ADGroupMember recursive behavior.

In the proposed evidence record, label successful lookup, failed lookup, and unresolved reference explicitly. Preserve the original raw values alongside your annotations. This makes later comparison reviewable: a disappearing display name might be a resolution difference, while a changed raw membership value deserves investigation. Avoid turning a convenient formatted report into the only retained evidence, particularly when another reviewer will need to reproduce the decision.

Step 2: Inspect the root and representative descendants

With an object DN and no mutation switches, dsacls displays the object's ACEs. The tool can also change permissions, so preserve the read-only form shown here. Microsoft's reference requires an elevated command prompt and Read permission on the target object. These four commands are adaptations using fictional objects. Dsacls reference.

dsacls "DC=contoso,DC=com"

dsacls "CN=Alice,OU=Users,DC=contoso,DC=com"

dsacls "CN=AppReaders,OU=Groups,DC=contoso,DC=com"

dsacls "CN=PC01,OU=Computers,DC=contoso,DC=com"

For each sample, record the trustee, allow or deny type, rights, inheritance, class scope, and property-set scope. Identify entries for SID 554 even when the display name is localized. Include objects used by the applications under review and examples with different inheritance settings. A single ordinary user object is a sample, not a domain-wide effective-access result.

The distinction matters for password writeback: Microsoft documents required root permissions and inherited descendant permissions, then asks administrators to inspect the connector account's effective permissions. Reading a DACL and testing a caller's operation answer different questions. Use both when validating a dependency. Password writeback permissions.

Step 3: Build a dependency record

For each retained principal, propose a record containing its owner, application/version, calling identity, requested attributes, protocol, target objects, and functional test. Include the failure that would justify rollback. An account name that resembles a product is a lead for investigation, not proof of an installer action.

This review also differs from Everyone and Authenticated Users in privileged AD groups. That article examines broad identities placed directly in privileged groups and standing privileged membership. Here, the group's documented role is compatibility read authorization; do not convert its member count into a claim of direct administrative membership.

Detection: Establish State and Monitor Membership Changes

Combine the SID-based inventory with a change trail. Microsoft's Security event documentation places 4732 and 4733 in Audit Security Group Management, with one event per added or removed member. They can be generated on domain controllers, member servers, and workstations; select the DC records relevant to the domain group. Event 4732, Event 4733.

A proposed monitoring rule should match TargetSid to S-1-5-32-554, retain MemberSid and the subject fields, and compare changes with approved work. Matching SIDs avoids depending on a translated group name. Test the field mapping in your collection pipeline before treating the rule as coverage. The field names come from the event XML examples; this rule is an operational proposal, not a deployed SIEM detection. 4732 event fields.

These events record membership changes. They do not show which attributes were read, discover every application dependency, or confirm successful anonymous enumeration. Missing events are inconclusive without working audit policy, collection, and retention. Pair logs with the saved state and authorized functional tests rather than treating either as a complete access assessment.

Remediation: Remove Unnecessary Access in Stages

This is a proposed change process based on the documented mechanisms, not a universal Microsoft instruction to empty the group. Keep a before-state, test dependencies, and change selected members. Membership is a domain-group change: calling it an “OU pilot” does not confine the effect of removing a member to one OU.

Step 1: Separate historical defaults from later drift

Use the SID inventory and raw member values above. Compare them with available creation and upgrade records, then classify entries as explained defaults, documented application additions, or unexplained membership. Give each category the same current-need review. The initial-membership table explains origin; it is not an exemption from review. MS-ADTS membership specification.

Step 2: Resolve documented dependencies before removal

The following sources provide specific dependencies and alternatives to investigate. Preserve their boundaries rather than extending them to every remote-access or synchronization deployment.

Sources: NT4 VPN troubleshooting, register an NPS, TGGAU access, password writeback permissions.

NPS registration is not evidence of an Anonymous requirement. For TGGAU, the Windows Authorization Access alternative needs its own permission verification: Microsoft's guidance distinguishes new domains from mixed-mode and upgraded domains where the group was not automatically granted the required access. Do not substitute a privileged group simply to make an access-denied error disappear. TGGAU and WAA.

The Entra Connect guidance explicitly warns about writeback issues when Authenticated Users is missing, especially with older versions. Its SAM-server section also distinguishes direct Authenticated Users permissions from access through this group. This documented dependency prevents a blanket recommendation to remove every broad identity. Writeback troubleshooting.

Exchange remains unproven as an automatic source of membership here. Appendix B says installing Exchange can create additional accounts and groups in Builtin and Users; it does not establish automatic additions to SID 554 or affected versions. Treat Exchange-named entries and appliances as questions requiring product-specific evidence and functional tests. Appendix B.

Step 3: Simulate a selected removal

Prioritize investigating Anonymous, then Everyone with the actual token behavior, and accounts without a confirmed need. Preserve Authenticated Users until its dependencies are understood. Choose the exact resolved member and rehearse in a representative test domain before scheduling the production domain change.

The following adaptation uses documented SID identifiers and -WhatIf. It simulates removal of Anonymous; it is not a command executed for this article. Validate the resolved principal first. Remove-ADGroupMember.

Remove-ADGroupMember -Identity "S-1-5-32-554" -Members "S-1-5-7" -Server "dc01.contoso.com" -WhatIf

After the tests and administrator's change decision, perform only the selected removal with normal confirmation. The cmdlet documents confirmation behavior; avoid a loop that empties the group or suppresses review of every member. A -WhatIf preview does not perform the removal or prove that it would succeed; it cannot predict application behavior after a real change. Removal and confirmation parameters.

Step 4: Verify function, permissions, and the change trail

Propose a domain change window, one member at a time, with a named rollback owner. Re-read membership on the DCs used by affected services after replication, then repeat the application's authorized operations in the relevant security context. Microsoft's writeback guidance specifically discusses replication delays and using a preferred DC while fixing permissions. Replication considerations.

Review application access errors and 4733 for the intended removal; watch 4732 for additions, including a controlled rollback. If function regresses, restore only the changed membership through the approved recovery process and investigate the dependency. Do not prescribe an arbitrary monitoring duration or universal DC restart: the NT4 VPN document's restart instruction belongs to its specific historical scenario. 4733, 4732, NT4 scenario.

How EtcSec Detects This

The etc-collector check PRE_WINDOWS_2000_ACCESS is implemented in ad/groups/membership/pre-windows-2000-access.go:24. The reviewed Detect() lowercases each group's CN and SAMAccountName, then selects the first group whose name contains pre-windows 2000 compatible access. Its Count is len(targetGroup.Members): all collected members count, including Authenticated Users and application accounts. The reviewed catalogue classifies it as Medium with weight 1.

The function returns a finding even when no matching group is found or the count is zero. Details and the affected group are included only when IncludeDetails is enabled, a group was found, and the count is positive. These statements describe the reviewed implementation, not an audit executed against your domain.

The check does not verify the group or member SIDs, inspect ACEs, read dsHeuristics, expand nested membership in this function, or test an application's access. English substring matching can miss localized names and can select an unintended matching name; missing input can also produce zero. Use the SID-based measurements to qualify the signal. A positive count is not proof of Anonymous membership, and zero is not proof that every read path is restricted.

COMPUTER_PRE_WINDOWS_2000 is explicitly outside this article's scope and tags. Its separately reviewed Detect() in ad/computers/other/pre-windows-2000.go:43 matches nonempty OperatingSystem values against Windows 95|Windows 98, case-insensitively. It does not inspect this group's members or permissions.

Close the review with the facts established: identities resolved, ACL paths inspected, protocol restrictions checked, dependencies tested, and selected changes monitored. The membership detector helps prioritize that work; the evidence determines which access can safely be removed.