AD-Passwortrichtlinie: warum ANSSI- und CIS-Prüfungen abweichen

Was bedeutet Konformität der AD-Passwortrichtlinie?

Die Konformität der AD-Passwortrichtlinie hängt von der konkret geprüften Regel ab. Eine Domäne kann die für EtcSecs ANSSI-Passwortrichtlinienprüfung zitierten numerischen Kriterien erfüllen und mit derselben Konfiguration dennoch die CIS-Prüfung nicht bestehen. Die Prüfungen lesen teilweise dieselben Attribute, wenden jedoch unterschiedliche Schwellenwerte an und decken unterschiedliche Einstellungen ab.

Die nützliche Frage lautet deshalb: Welches Attribut ist fehlgeschlagen, gegenüber welcher dokumentierten Referenz und mit welcher Detektorversion? Ein als ANSSI oder CIS gekennzeichnetes Ergebnis sollte zu diesen Nachweisen führen. Für sich allein kann es keine Konformität mit einer gesamten Veröffentlichung belegen.

Dieser Vergleich trennt die beiden in einer Collector-Analyse vom September 2026 dokumentierten Detektorprädikate von den zugrunde liegenden Empfehlungen. Der Dokumentvergleich verwendet CIS Microsoft Windows Server 2012 R2 Benchmark v2.2.0 vom 28. April 2016, Abschnitte 1.1 und 1.2. Dies ist eine historische Ausgabe. Der aktuelle CIS-Katalog führt Server 2022 v5.1.0 auf; diese Ausgabe wurde für diesen Artikel nicht gelesen.

Unser praktischer ANSSI-Leitfaden für Active Directory erklärt, warum ein AD-Sicherheitsprogramm einen definierten Satz ergänzender Dokumente benötigt und keine Konformitätsbehauptung, die auf einer einzigen PDF beruht.

Wie sich die ANSSI- und CIS-Prüfungen unterscheiden

Die folgende Tabelle unterscheidet Quellenempfehlungen von den für Detect() zitierten Bedingungen. Die Werte beschreiben die Konfiguration, die die zitierten numerischen Bedingungen erfüllt, und nicht die Fehlerausdrücke selbst.

Die Collector-Analyse zitiert ad/compliance/anssi/r1-password-policy.go und ad/compliance/cis/password-policy.go. Die vollständigen Go-Dateien waren für diesen Vergleich nicht verfügbar. Die Tabelle erlaubt daher Schlussfolgerungen zu diesen Auszügen; sie belegt keine nicht zitierten Verzweigungen, Fehlerbehandlung oder Abdeckung fehlender Erfassungsdaten.

Quellen für die Dokumentspalten sind ANSSI-PG-078 und die historische PDF CIS Server 2012 R2 v2.2.0. Die Detektorspalten stammen aus den unten wiedergegebenen zitierten Prädikaten. Es handelt sich um Implementierungsschwellenwerte; nicht jede Zahl wird ANSSI zugeschrieben. Auch die Unterschiede von 60/365 Tagen und 10/5 Versuchen zeigen, warum eine Aussage auf Dokumentebene die Ausgabe nennen muss.

Komplexität ist eine eigene Frage

Microsoft definiert pwdProperties als Bitfeld der Domänenrichtlinie für Komplexität und Speicherbeschränkungen. Sein Flag DOMAIN_PASSWORD_COMPLEX hat den Wert 1. Die Prüfung von Länge, Historie und Alter kann den Zustand dieses Flags nicht belegen.

Eine vollständige Bewertung muss Komplexität deshalb ausdrücklich erfassen. Die für diese beiden Prüfungen bereitgestellten Auszüge zeigen keine Komplexitätsbedingung. Das ist eine Grenze der verfügbaren Implementierungsnachweise, kein Beweis dafür, dass die vollständigen Detektoren sie ignorieren. Ein undokumentiertes Feld darf nicht als bestandene Prüfung angenommen werden.

Fälle mit unterschiedlichen Ergebnissen

Diese Beispiele sind hypothetische Konfigurationen, die anhand der zitierten numerischen Prädikate bewertet werden. Sie sind keine Ergebnisse aus einer Kundenumgebung oder einem tatsächlich ausgeführten Collector-Lauf. Für diese Beispiele wird angenommen, dass Zeiträume in Tagen angegeben werden, kein Ablauf als maxPwdAge == 0 dargestellt wird und die übrigen Felder gültige Werte enthalten. Diese Annahmen entsprechen den zitierten Vergleichen; die Umwandlung der Verzeichniswerte durch den Collector wurde nicht überprüft.

Jede Zeile isoliert einen Grund für die Abweichung. Eine reale Richtlinie kann mehrere Bedingungen gleichzeitig verletzen; behalten Sie deshalb alle fehlgeschlagenen Attribute bei, statt nur das zuerst gefundene zu melden. So wird der Behebungsplan konkret: Ein Fehler bei der Historie erfordert eine Änderung der Historie, während ein Altersfehler eine ausdrückliche Entscheidung zum Ablauf erfordert.

Kann auch das Gegenteil eintreten?

Für diese zitierten Prädikate mit denselben gültigen Eingaben gilt: Wer die numerischen CIS-Bedingungen erfüllt, erfüllt auch die numerischen ANSSI-Bedingungen. Eine Mindestlänge von 14 erfüllt auch 12; eine Historie von 24 erfüllt 12; eine Sperrschwelle zwischen 1 und 5 liegt auch zwischen 1 und 10. Die nur bei CIS vorhandenen Altersbedingungen ergänzen Anforderungen, ohne die gemeinsamen Anforderungen abzuschwächen.

Für dieses Paar von Auszügen gibt es daher kein belegtes Beispiel mit bestandener CIS- und fehlgeschlagener ANSSI-Prüfung. Meldet ein Audit diese Kombination, vergleichen Sie die erfassten Werte, die Detektorversion und die vollständigen Finding-Details, bevor Sie sie als Unterschied zwischen Standards erklären. Unterschiedliche Eingaben, Implementierungen oder Auditumfänge benötigen eigene Nachweise.

Auch die letzte Zeile belegt keine vollständige Benchmark-Konformität. Sie sagt nur, dass diese fünf numerischen Eingaben die zitierten Ausdrücke erfüllen. Komplexität bleibt eine separate Prüfung, und ein vollständiger Benchmark enthält weitere Kontrollen.

Erkennung: die Standard-Passwortrichtlinie der Domäne lesen

Verwenden Sie das Active-Directory-PowerShell-Modul, um die Standardrichtlinie der Domäne zu erfassen. Ersetzen Sie die Beispieldomäne durch die untersuchte Domäne:

Get-ADDefaultDomainPasswordPolicy -Identity 'example.com' |
    Select-Object DistinguishedName, MinPasswordLength, PasswordHistoryCount,
        LockoutThreshold, MaxPasswordAge, MinPasswordAge, ComplexityEnabled

Dies ist eine einzelne schreibgeschützte Pipeline auf Grundlage der Microsoft-Dokumentation zu Get-ADDefaultDomainPasswordPolicy. Sie wurde für diesen Artikel nicht in einer realen Domäne ausgeführt.

Lesen Sie die Ausgabe als Nachweis für eine bestimmte Domäne und einen bestimmten Erfassungszeitpunkt. Bewahren Sie den Distinguished Name zusammen mit den Werten auf, damit eine spätere Prüfung feststellen kann, ob die beiden Auditergebnisse tatsächlich dieselbe Richtlinie beschreiben. Vergleichen Sie keine aus dem Gedächtnis bekannte GPO-Einstellung mit einem frischen Collector-Ergebnis unter der Annahme identischer Eingaben.

MinPasswordLength ist eine Zeichenanzahl. PasswordHistoryCount entspricht der Anzahl gespeicherter Passwörter; Microsoft dokumentiert das Verzeichnisattribut auf der Schemaseite zu pwdHistoryLength. Die Alterseigenschaften sind Zeiträume, während Länge, Historie und Sperrschwelle Anzahlen sind. Behalten Sie diese Einheiten ausdrücklich bei, wenn Sie Nachweise in ein Audit-Arbeitsblatt übertragen.

Der Befehl liefert die Standardrichtlinie der Domäne. Er belegt nicht die effektive Richtlinie jedes Benutzers, wenn fein abgestufte Passwortrichtlinien gelten. Microsoft dokumentiert eine separate Abfrage der resultierenden Passwortrichtlinie für Benutzer; dehnen Sie ein Ergebnis zur Domänenstandardrichtlinie nicht zu einer kontenweisen Konformitätsaussage aus.

Behebung (Remediation): das fehlgeschlagene Attribut anhand einer benannten Referenz korrigieren

Entscheiden Sie zuerst, welche Referenz und Ausgabe die Änderung bestimmen. Dokumentieren Sie das erforderliche Ergebnis und ändern Sie dann die Attribute, die es nicht erfüllen. Eine Einstellung, die ein Finding beseitigt, kann ein anderes unverändert lassen, wie die Beispieltabelle zeigt.

Ein Beispiel, das beide zitierten numerischen Prädikate und die numerischen Kriterien der historischen Tabelle erfüllt, verwendet Länge 14, Historie 24, Sperrschwelle 5, Höchstalter 60 Tage und Mindestalter 1 Tag. Der Wert von 60 Tagen stammt aus dem historischen CIS-Abschnitt 1.1.2; die strengere Wahl von 5 Versuchen stammt aus dem CIS-Detektorauszug. Aktivieren Sie Komplexität für das separate Komplexitätskriterium des zitierten Dokuments. Dies ist ein Vergleichsbeispiel und keine Empfehlung, heute einen historischen Benchmark einzuführen.

Das folgende Konfigurationsbeispiel verwendet Parameter, die Microsoft für Set-ADDefaultDomainPasswordPolicy dokumentiert:

Set-ADDefaultDomainPasswordPolicy -Identity 'example.com' `
    -MinPasswordLength 14 -PasswordHistoryCount 24 -LockoutThreshold 5 `
    -MaxPasswordAge '60.00:00:00' -MinPasswordAge '1.00:00:00' `
    -ComplexityEnabled $true -WhatIf

-WhatIf zeigt die vorgeschlagene Operation in einer Vorschau, ohne sie anzuwenden. Dieses Beispiel wurde anhand der Dokumentation geprüft; es wurde nicht in einer realen Domäne ausgeführt. Ein Administrator sollte die beabsichtigte Änderung testen, sie dann über den verwalteten Richtlinienprozess der Organisation anwenden und die obige schreibgeschützte Abfrage wiederholen. Eine Vorschau ist kein Nachweis einer erfolgreichen Behebung.

Den Ablauf bewusst festlegen

ANSSI-PG-078 R24 rät von einem standardmäßigen Ablauf für nicht sensible Konten ab, wenn robuste Passwörter und unterstützende Systeme dies erlauben; R25 behält den Ablauf für privilegierte Konten bei. Der vorangehende Text bevorzugt für diese Konten die Zwei-Faktor-Authentifizierung und behandelt den Ablauf bei reiner Passwortauthentifizierung. Diese Unterscheidung der Konten lässt sich nicht durch einen einzigen domänenweiten Alterswert feststellen. Das Fehlen eines Alters-Findings des ANSSI-Detektors bestätigt nicht die gesamte Ablaufrichtlinie.

Wenn Ihre gewählte Referenz ein Höchstalter ungleich null verlangt, behalten Sie diese Anforderung bei oder dokumentieren Sie die Ausnahme über Ihren Auditprozess. Das Beseitigen eines Dashboard-Findings und das Begründen einer Ausnahme sind unterschiedliche Ergebnisse; halten Sie fest, welches Sie erreicht haben.

Die Änderung und das verbleibende Risiko überprüfen

Bewahren Sie die Richtlinienausgabe vor und nach der Änderung, die Ausgabe der Referenz und den Grund für jedes geänderte Attribut auf. Führen Sie beide Prüfungen erneut mit derselben frischen Erfassung aus und prüfen Sie verbleibende Findings einzeln. Wenn sich die Konfiguration geändert hat, das Finding jedoch nicht, gleichen Sie den Erfassungszeitpunkt und die gemeldeten Werte ab, bevor Sie eine weitere Richtlinienänderung vornehmen.

Die Konformität der Passwortrichtlinie benötigt auch einen betrieblichen Kontext. Unser Artikel über Password Spraying erklärt, wie wenige, auf viele Konten verteilte Versuche offensichtliche Sperren einzelner Konten vermeiden können und warum die Risikominderung Passwortkontrollen, stärkere Authentifizierung und korrelierte Überwachung kombiniert. Eine bestandene Sperrschwellenprüfung sollte nicht als Nachweis gelten, dass Spraying beseitigt wurde.

Wie EtcSec dies erkennt

Der Katalog der Website enthält sowohl ANSSI_R1_PASSWORD_POLICY als auch CIS_PASSWORD_POLICY. Die Collector-Analyse liefert folgende Fehlerbedingungen für ihre jeweiligen Detect()-Implementierungen:

ANSSI_R1_PASSWORD_POLICY
ad/compliance/anssi/r1-password-policy.go
minPwdLength < 12 OR pwdHistoryLength < 12
OR lockoutThreshold == 0 OR lockoutThreshold > 10

CIS_PASSWORD_POLICY
ad/compliance/cis/password-policy.go
minPwdLength < 14 OR pwdHistoryLength < 24
OR maxPwdAge > 365 OR maxPwdAge == 0
OR minPwdAge < 1 OR lockoutThreshold > 5 OR lockoutThreshold == 0

Die obigen Altersschwellenwerte werden für diesen Vergleich in Tagen angegeben, entsprechend dem Beispiel maxAge=120j der Analyse (Zeile 127). Die Auszüge belegen nicht, wie der Collector rohe LDAP-Intervalle umwandelt oder Richtlinien ohne Ablauf darstellt. Sie erklären, warum dieselbe Richtlinie unterschiedliche Findings erzeugen kann und warum jedes Finding das fehlgeschlagene Attribut benennen sollte.

Der Implementierungsnachweis ist die Collector-Analyse unter docs/research/ad/2026-09-13-ad-catalogue-gap-diff.md, Zeilen 123 beziehungsweise 124. Diese Zeilen zitieren die benannten Go-Dateien; Zeilennummern des Go-Quellcodes waren nicht verfügbar. Die vollständigen Quelldateien waren in dieser Analyse nicht verfügbar. Die Komplexitätsabdeckung, das Verhalten bei fehlenden Daten und alle weiteren nicht zitierten Verzweigungen bleiben ungeprüft. Diese Findings sind nützliche Konfigurationssignale; ihre Namen machen aus einem Teilprädikat keine vollständige ANSSI- oder CIS-Bewertung.

Primärquellen

• ANSSI: Recommandations de sécurité relatives à Active Directory, DAT-NT-17 v1.1, 10. September 2014; R1, gedruckte Seite 8.
• ANSSI: Empfehlungen zur Authentifizierung und zu Passwörtern, ANSSI-PG-078 v2.0, 8. Oktober 2021; R10 und R21–R25.
• CIS: Microsoft-Windows-Server-Benchmark-Katalog und Auswahl der Ausgabe. Historischer Vergleich: Server 2012 R2 v2.2.0, 28. April 2016; Abschnitte 1.1.1–1.1.5 und 1.2.2, PDF oben verlinkt. Server 2022 v5.1.0 wurde nicht gelesen.