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. There was already similar functionality before, but it was much more limited. One difference is that it was not a hierarchical structure, but flat. This means that everyone could read all attributes of every object. Active Directory limits this. A normal user cannot read sensitive attributes of other users, like the pwdLastSet attribute, anymore. The problem was and is, some applications need to have access to this information. This is why Microsoft introduced the Pre-Windows 2000 Compatible Access group, which grants read privileges on all attributes of all objects again. And just to be sure, they added Authenticated Users to this group. And this is still the default in Windows Server 2025, approximately 25 years after Windows 2000.
What are the risks?
PingCastle reports this vulnerability only as informational. I find this a little bit too low because if Authenticated Users is not in this group, it can be very annoying for attackers. As I have said before, one interesting attribute that an attacker will not be able to read anymore is pwdLastSet. This means it will be much harder for attackers to find accounts with old and potentially weak passwords. Because of this, I really recommend fixing this vulnerability.
However, there is a caveat! Because this is a default vulnerability in AD, some tools rely on this “functionality.” So, this is sadly not something you should change on a Friday afternoon. In large environments, this might even be quite impossible to change. You will have to do a lot of testing and re-add specific accounts to this group.
How to fix it?
The fix is easy: just remove Authenticated Users from the Pre-Windows 2000 Compatible Access group. At least if your environment is empty like mine. As said above, this will require a lot of testing depending on the size of your environment. But let’s see what happens. Below you can see the information a normal user can get about another user in the default config that Authenticated Users is in Pre-Windows 2000 Compatible Access.
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 opinion, this is a very important hardening measure. Especially if you have to rebuild your AD completely, start with this! In the beginning, this is still easy to implement.
If you want to read more on this topic, there is a lot of amazing information in this post: https://www.semperis.com/blog/security-risks-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!