--- title: Built-in Misconfigurations - Pre-Windows 2000 Compatible Access url: https://www.vidrasec.com/de/blog/built-in-insecurities-win2k/ description: Die Pre-Windows 2000 Compatible Access-Gruppe ist eine eingebaute AD-Fehlkonfiguration. Was sie ist, welche Risiken sie birgt und wie du dein AD absicherst. date: 2024-04-22 --- 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](https://www.pingcastle.com/) 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. ## 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. ![Pre Win2K Gruppe](https://www.vidrasec.com/images/blog/pre-win2k-group.webp) ## 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. Genau solche Standardeinstellungen prüfe ich als Erstes in einem [Active Directory Audit](/de/services/active-directory-audit/): günstig zu beheben, mit hoher Wirkung, und in den meisten Umgebungen, die ich sehe, immer noch aktiv. **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. ``` powershell 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): ``` powershell 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)](https://www.semperis.com/blog/security-risks-pre-windows-2000-compatibility-windows-2022/) Ich werde weiterhin empfohlene Sicherheitsmaßnahmen für Active Directory erklären. Wenn du eine vollständige Überprüfung solcher Standardeinstellungen in deiner gesamten Umgebung willst, ist genau das der Inhalt eines [Active Directory Audits](/de/services/active-directory-audit/). Und ob solche Fehlkonfigurationen in deinem Netzwerk tatsächlich ausnutzbar sind, beantwortet ein [interner Infrastruktur-Penetrationstest](/de/services/internal-it-infrastructure-penetration-test/). [Bei Fragen, wie immer, einfach kontaktieren!](/de/contact/) Falls du überlegst, dir für Härtungsarbeit wie diese externe Unterstützung zu holen: Der [Penetrationstest-Käuferratgeber](/de/blog/penetration-testing-buyers-guide/) erklärt, wie man das scopt und budgetiert.