Built-in Misconfigurations - Pre-Windows 2000 Compatible Access
This page is also available in English.
Dies ist der erste Teil einer Serie zu unsicheren Standardeinstellungen in Active Directory. Dieser Teil behandelt die Pre-Windows 2000 Compatible Access-Gruppe. Was ist das? Welche Risiken gibt es? Und was kannst du dagegen tun?
Für diese Übung habe ich eine brandneue Preview von Windows Server 2025 mit Active Directory eingerichtet, um sicherzustellen, dass wir die neueste (und hoffentlich beste) Version haben. Dann werde ich PingCastle verwenden, um Fehlkonfigurationen zu finden und zu versuchen, sie zu beheben. Diese Standardeinstellungen sind in vielen Umgebungen üblich, die nicht speziell gehärtet wurden. Wenn das AD aus irgendeinem Grund grundlegend überarbeitet wird, ist es entscheidend, diese Schwachstellen von Anfang an anzugehen.
Posts in dieser Serie
Was ist Pre-Windows 2000 Compatible Access?
Active Directory, wie wir es kennen, kam mit Windows 2000. Ältere Funktionalität war stark begrenzt. Ein Unterschied: Die Struktur war flach, nicht hierarchisch. Dadurch konnte jeder alle Attribute jedes Objekts lesen. Active Directory schränkt das ein. Ein normaler User kann sensible Attribute anderer User (z. B. pwdLastSet) nicht mehr lesen. Das Problem: Manche Anwendungen brauchen genau diesen Zugriff. Dafür führte Microsoft die Pre-Windows 2000 Compatible Access-Gruppe ein – sie gewährt wieder Leseberechtigung auf alle Attribute aller Objekte. Zusätzlich wurden Authenticated Users in diese Gruppe aufgenommen. Das ist noch immer der Standard in Windows Server 2025, etwa 25 Jahre nach Windows 2000.
Welche Risiken gibt es?
PingCastle stuft diese Schwachstelle nur als informativ ein. Das finde ich zu niedrig. Ohne Authenticated Users in dieser Gruppe wird es für Angreifer deutlich schwieriger. Ein wichtiges Attribut, das sie dann nicht mehr lesen können, ist pwdLastSet. So finden sie Konten mit alten oder schwachen Passwörtern kaum noch. Ich empfehle, die Schwachstelle zu beheben.
Wichtig: In AD ist das ein Standard, von dem manche Tools abhängen. Also nicht einfach am Freitagnachmittag ändern. In großen Umgebungen kann die Änderung sehr aufwändig oder unmöglich sein. Dann sind umfangreiche Tests nötig, und ggf. müssen bestimmte Konten wieder in die Gruppe.
Hinweis: Im Text steht „Authenticated Users“; in der deutschen AD-Oberfläche heißt die Gruppe „Authentifizierte Benutzer“.
Wie kannst du es beheben?
Die Lösung: Authenticated Users aus der Pre-Windows 2000 Compatible Access-Gruppe entfernen. Zumindest in einer leeren Lab-Umgebung. In größeren Umgebungen ist vorher viel Testarbeit nötig (siehe oben). Unten siehst du, welche Informationen ein normaler User über einen anderen User in der Standardeinstellung erhält.
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
Nachdem alle Konten aus der Pre-Windows 2000 Compatible Access-Gruppe entfernt wurden, konnten nur sehr begrenzte Informationen über den User Bob eingesehen werden. Bei mir hat es circa 10 Minuten gedauert bis diese Einstellung wirksam wurde. Dies ist die Ausgabe des Get-ADUser-Befehls nach der Änderung (und 10 Minuten warten):
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
Fazit
Meiner Meinung nach ist dies eine sehr wichtige Sicherheitsmaßnahme. Besonders wenn das AD komplett neu aufgebaut werden muss, sollte damit begonnen werden! Am Anfang ist dies noch einfach zu implementieren.
Wer mehr zu diesem Thema lesen möchte, findet viele großartige Informationen in diesem Beitrag: Semperis: Sicherheitsrisiken der Pre-Windows-2000-Kompatibilität (Windows 2022)
Ich werde weiterhin empfohlene Sicherheitsmaßnahmen für Active Directory erklären. Bei weiteren Fragen oder Interesse an einem Active Directory Audit oder Penetrationstest, wie immer, einfach kontaktieren!
martin@vidrasec.com | +43 670 3081275 | +43 670 3081275 | Termin auswählen |