Built-in Misconfigurations - Pre-Windows 2000 Compatible Access
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 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.
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.
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)
I will continue explaining recommended Active Directory hardening measures. If you have any other questions or are interested in an Active Directory Audit or Penetration test, as always, just contact me!
martin@vidrasec.com | +43 670 3081275 | +43 670 3081275 | Book appointment |