Built-in Misconfigurations - Pre-Windows 2000 Compatible Access

Apr 22, 2024 (Updated: Jul 9, 2026)

#Active Directory #Ping Castle #Internal Pentest

Pre-Windows 2000 Compatible Access, AD group, risks and hardening with PingCastle

Diese Seite ist auch auf Deutsch verfügbar.

This is the first part of a series in which we look into default insecure configurations in Active Directory. This part covers the Pre-Windows 2000 Compatible Access group. What is it? What are the risks? And what can we do about it?

For this exercise, I set up a brand new preview version of Windows Server 2025 with Active Directory to ensure we have the latest (and hopefully greatest) version. I will then run PingCastle (opens in a new tab) to find misconfigurations and try to fix them. These default settings are common in many environments that haven’t been specifically hardened. If you are overhauling your AD for any reason, it’s crucial to address these vulnerabilities from the start.

Posts in this series

What is Pre-Windows 2000 Compatible Access?

Active Directory as we know it was introduced with Windows 2000. Earlier similar functionality was much more limited. One difference: it was flat, not hierarchical. So everyone could read every attribute of every object. Active Directory limits that. A normal user can no longer read sensitive attributes of other users (for example pwdLastSet). The problem: some applications need that access. So Microsoft introduced the Pre-Windows 2000 Compatible Access group, which grants read access to all attributes of all objects again. They also added Authenticated Users to this group. This is still the default in Windows Server 2025, about 25 years after Windows 2000.

Pre Win2K Group

What are the risks?

PingCastle reports this only as informational. I think that’s too low. If Authenticated Users is not in this group, life gets harder for attackers. One important attribute they can’t read anymore is pwdLastSet. So it’s much harder to find accounts with old or weak passwords. I recommend fixing this.

This is exactly the kind of default I check first in an Active Directory Audit: cheap to fix, high impact, and still on by default in most environments I see.

But there’s a caveat. This is a default in AD, and some tools depend on it. So don’t change it on a Friday afternoon. In large environments it may be very hard or impossible. You’ll need thorough testing and may have to re-add specific accounts to the group.

How to fix it?

The fix is simple: remove Authenticated Users from the Pre-Windows 2000 Compatible Access group. At least in an empty lab like mine. In bigger environments you’ll need a lot of testing first (see above). Below: what a normal user can see about another user when Authenticated Users is still in the group (default).

PS C:\Users\alice> Get-ADUser bob -Properties *

AccountExpirationDate                :
accountExpires                       : 9223372036854775807
AccountLockoutTime                   :
AccountNotDelegated                  : False
AllowReversiblePasswordEncryption    : False
AuthenticationPolicy                 : {}
AuthenticationPolicySilo             : {}
BadLogonCount                        : 0
badPasswordTime                      : 0
badPwdCount                          : 0
CannotChangePassword                 : False
CanonicalName                        : vidrasec.lab/Users/bob
Certificates                         : {}
City                                 :
CN                                   : bob
codePage                             : 0
Company                              :
CompoundIdentitySupported            : {}
Country                              :
countryCode                          : 0
Created                              : 4/19/2024 12:35:21 AM
createTimeStamp                      : 4/19/2024 12:35:21 AM
Deleted                              :
Department                           :
Description                          :
DisplayName                          : bob
DistinguishedName                    : CN=bob,CN=Users,DC=vidrasec,DC=lab
Division                             :
DoesNotRequirePreAuth                : False
dSCorePropagationData                : {12/31/1600 4:00:00 PM}
EmailAddress                         :
EmployeeID                           :
EmployeeNumber                       :
Enabled                              : True
Fax                                  :
GivenName                            : bob
HomeDirectory                        :
HomedirRequired                      : False
HomeDrive                            :
HomePage                             :
HomePhone                            :
Initials                             :
instanceType                         : 4
isDeleted                            :
KerberosEncryptionType               : {}
LastBadPasswordAttempt               :
LastKnownParent                      :
lastLogoff                           : 0
lastLogon                            : 0
LastLogonDate                        :
LockedOut                            : False
logonCount                           : 0
LogonWorkstations                    :
Manager                              :
MemberOf                             : {}
MNSLogonAccount                      : False
MobilePhone                          :
Modified                             : 4/19/2024 12:35:21 AM
modifyTimeStamp                      : 4/19/2024 12:35:21 AM
msDS-User-Account-Control-Computed   : 0
Name                                 : bob
nTSecurityDescriptor                 : System.DirectoryServices.ActiveDirectorySecurity
ObjectCategory                       : CN=Person,CN=Schema,CN=Configuration,DC=vidrasec,DC=lab
ObjectClass                          : user
ObjectGUID                           : 00045a31-db0a-43a2-81b3-030b71475f3e
objectSid                            : S-1-5-21-3820918346-3820853946-976116511-1105
Office                               :
OfficePhone                          :
Organization                         :
OtherName                            :
PasswordExpired                      : False
PasswordLastSet                      : 4/19/2024 12:35:21 AM
PasswordNeverExpires                 : False
PasswordNotRequired                  : False
POBox                                :
PostalCode                           :
PrimaryGroup                         : CN=Domain Users,CN=Users,DC=vidrasec,DC=lab
primaryGroupID                       : 513
PrincipalsAllowedToDelegateToAccount : {}
ProfilePath                          :
ProtectedFromAccidentalDeletion      : False
pwdLastSet                           : 133579857214640950
SamAccountName                       : bob
sAMAccountType                       : 805306368
ScriptPath                           :
sDRightsEffective                    : 0
ServicePrincipalNames                : {}
SID                                  : S-1-5-21-3820918346-3820853946-976116511-1105
SIDHistory                           : {}
SmartcardLogonRequired               : False
State                                :
StreetAddress                        :
Surname                              :
Title                                :
TrustedForDelegation                 : False
TrustedToAuthForDelegation           : False
UseDESKeyOnly                        : False
userAccountControl                   : 512
userCertificate                      : {}
UserPrincipalName                    : bob@vidrasec.lab
uSNChanged                           : 16438
uSNCreated                           : 16433
whenChanged                          : 4/19/2024 12:35:21 AM
whenCreated                          : 4/19/2024 12:35:21 AM

After removing all members from the Pre-Windows 2000 Compatible Access group, we could only see very limited information about the user Bob. I actually had to wait for approximately 10 minutes for this change to take effect. This is the output of the Get-ADUser command after the change:

PS C:\Users\alice> Get-ADUser bob -Properties *

AccountExpirationDate                :
accountExpires                       :
AccountLockoutTime                   :
AuthenticationPolicy                 : {}
AuthenticationPolicySilo             : {}
BadLogonCount                        :
CannotChangePassword                 : False
CanonicalName                        :
Certificates                         : {}
City                                 :
CN                                   : bob
codePage                             : 0
Company                              :
CompoundIdentitySupported            : {}
Country                              :
countryCode                          : 0
Created                              :
Deleted                              :
Department                           :
Description                          :
DisplayName                          : bob
DistinguishedName                    : CN=bob,CN=Users,DC=vidrasec,DC=lab
Division                             :
EmailAddress                         :
EmployeeID                           :
EmployeeNumber                       :
Fax                                  :
GivenName                            : bob
HomeDirectory                        :
HomeDrive                            :
HomePage                             :
HomePhone                            :
Initials                             :
instanceType                         :
isDeleted                            :
KerberosEncryptionType               : {}
LastBadPasswordAttempt               :
LastKnownParent                      :
LastLogonDate                        :
LogonWorkstations                    :
Manager                              :
MemberOf                             : {}
MobilePhone                          :
Modified                             :
Name                                 : bob
nTSecurityDescriptor                 : System.DirectoryServices.ActiveDirectorySecurity
ObjectCategory                       : CN=Person,CN=Schema,CN=Configuration,DC=vidrasec,DC=lab
ObjectClass                          : user
ObjectGUID                           : 00045a31-db0a-43a2-81b3-030b71475f3e
objectSid                            : S-1-5-21-3820918346-3820853946-976116511-1105
Office                               :
OfficePhone                          :
Organization                         :
OtherName                            :
PasswordLastSet                      :
POBox                                :
PostalCode                           :
PrimaryGroup                         : CN=Domain Users,CN=Users,DC=vidrasec,DC=lab
primaryGroupID                       : 513
PrincipalsAllowedToDelegateToAccount : {}
ProfilePath                          :
ProtectedFromAccidentalDeletion      : False
SamAccountName                       : bob
sAMAccountType                       : 805306368
ScriptPath                           :
sDRightsEffective                    : 0
ServicePrincipalNames                : {}
SID                                  : S-1-5-21-3820918346-3820853946-976116511-1105
SIDHistory                           : {}
State                                :
StreetAddress                        :
Surname                              :
Title                                :
userCertificate                      : {}
UserPrincipalName                    : bob@vidrasec.lab

Conclusion

In my view this is a very important hardening step. If you ever rebuild AD from scratch, start here. Early on it’s still easy to do.

If you want to read more on this topic, there is a lot of amazing information in this post: Semperis: Security risks of Pre-Windows 2000 compatibility (Windows 2022) (opens in a new tab)

I will continue explaining recommended Active Directory hardening measures. If you’d like a full review of defaults like this one across your whole environment, that’s exactly what an Active Directory Audit covers. And whether misconfigurations like this are actually exploitable in your network is what internal infrastructure penetration testing answers. Questions? Just contact me, as always.

If you’re weighing whether to bring in outside help for hardening work like this, the Penetration Testing Buyer’s Guide covers how to scope and budget for it.