AD Konformitaetsscore Geltungsbereich: Was die Zahl belegen kann
Der AD Konformitaetsscore Geltungsbereich bestimmt, welche Aussagen eine Zahl in einem Audit stützen kann. In der am 4. Oktober 2026 geprüften Implementierung von etc-collector beginnt der Score bei 100 und zieht Punkte für vier Werte der Domänen-Passwortrichtlinie sowie für die Anzahl aktivierter Benutzer mit adminCount=1 ab. Er fasst weder alle Befunde zusammen noch bewertet er ein vollständiges Compliance-Rahmenwerk.
Ein Score von 100 bedeutet, dass bei den bereitgestellten Eingaben keine dieser fünf Abzugsbedingungen ausgelöst wurde. Er zertifiziert weder Active Directory noch belegt er, dass alle relevanten Objekte erfasst wurden oder unabhängige Kontrollen bestanden sind. Bevor Sie die Zahl in einem Bericht verwenden, rekonstruieren Sie ihre Eingaben und die Nachweise zu deren Erfassung.
Diese Analyse bezieht sich auf die Collector-Revision 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85, insbesondere auf public/internal/audit/detectors/ad/compliance/score.go, beginnend mit Detect() in Zeile 23. Die folgenden Beispiele sind Berechnungen aus diesem Code, keine Messungen einer realen Domäne. Für diesen Artikel wurden keine Windows-Befehle gegen eine Umgebung ausgeführt.
Wie die fünf Abzüge funktionieren
Bei einem nicht-null DomainInfo wird jede Bedingung unabhängig geprüft. Die fünfte Eingabe wird aus der bereitgestellten Users-Sammlung abgeleitet. Dies sind Produktschwellenwerte; ihre Verwendung zur Reproduktion eines Ergebnisses belegt nicht, dass sie der genehmigten Baseline der Organisation entsprechen.
| Vom Detektor verwendete Eingabe | Abzugsbedingung | Abgezogene Punkte | Abzugsschlüssel |
|---|---|---|---|
MinPwdLength | Unter 14 | 10 | weak_password_length |
PwdHistoryLength | Unter 24 | 5 | weak_password_history |
LockoutThreshold | Über 10 oder gleich 0 | 5 | weak_lockout_policy |
MaxPwdAge, in ganzen Tagen des Collectors | Über 90 oder gleich 0 | 5 | weak_password_age |
Anzahl bereitgestellter Benutzer mit Disabled=false und AdminCount=true | Über 20 | 10 | excessive_admins |
Gleichheit ist entscheidend: Länge 14, Historie 24, Sperrschwellenwert 10, Höchstalter 90 Tage und Anzahl 20 lösen den jeweiligen Abzug nicht aus. Der Zähler zählt jedes passende Objekt einmal; er berechnet kein Verhältnis von Administratoren zu Benutzern.
Ist DomainInfo null, überspringt der Detektor alle vier Richtlinienbedingungen und zieht unter no_domain_info 15 Punkte ab. Anschließend prüft er dieselbe Bedingung zur Benutzeranzahl. Ein null-Objekt ist somit ein anderer Berechnungszweig, kein Nachweis für vier fehlgeschlagene Richtlinienkontrollen.
Den erreichbaren Wertebereich nachweisen
Bei vorhandenem DomainInfo beträgt der größtmögliche Abzug 10 + 5 + 5 + 5 + 10 = 35. Der kleinste ist null. Die Scores liegen daher zwischen 65 und 100, in Schritten von fünf Punkten. Die vorsorgliche Begrenzung auf null wird durch diese Bedingungen nie erreicht.
Ohne DomainInfo beträgt der Score 85, wenn die Anzahl passender Benutzer höchstens 20 ist, oder 75, wenn sie 20 überschreitet. In diesem Zweig sind keine anderen Werte möglich.
Werden beispielsweise alle vier Richtlinienbedingungen ausgelöst, ergibt eine Anzahl von 20 den Wert 75; eine Anzahl von 21 ergibt 65. Ein null-Domänenobjekt mit Anzahl 20 ergibt 85. Diese hypothetischen Fälle erklären, warum eine besser aussehende Zahl mit schwächeren Richtliniennachweisen einhergehen kann.
Der Befund enthält Interpretationsbereiche wie 50-69 und 0-49. Im ersten Bereich ist nur 65 erreichbar; der zweite ist vollständig unerreichbar. Werte unter 65 können aus dieser Berechnung allein nicht entstehen. Diese Anzeigebezeichnungen erweitern weder die Abdeckung des Detektors noch machen sie dessen oberen Bereich zu einem Compliance-Urteil.
Erkennung: Eingaben mit unabhängigen Abfragen abgleichen
Beginnen Sie mit der Domäne, dem gewählten Domänencontroller, dem Erfassungszeitpunkt und dem Inventarumfang. Eine neue unabhängige Abfrage an einem anderen DC oder mit einer engeren Suchbasis kann andere Nachweise liefern. Dokumentieren Sie diese Unterschiede, bevor Sie eine Abweichung als Detektorfehler behandeln.
Microsoft dokumentiert Get-ADDefaultDomainPasswordPolicy als Cmdlet zum Abrufen der Standardrichtlinie einer Domäne. Dieses rein lesende Beispiel verwendet die dokumentierten Parameter -Identity und -Server. Ersetzen Sie die beispielhafte Domäne und den DC durch die geprüften Ziele:
Get-ADDefaultDomainPasswordPolicy -Identity 'example.com' -Server 'dc01.example.com'
Bewahren Sie das vollständige zurückgegebene Objekt auf und vergleichen Sie Mindestlänge, Passworthistorie, Sperrschwellenwert und Höchstalter mit den Collector-Eingaben. Behalten Sie die Zeiteinheiten bei: Der Provider wandelt das Verzeichnisintervall für das Höchstalter in ganze Tage um. Vergleichen Sie weder ein rohes Verzeichnisintervall noch eine formatierte Zeichenfolge für die Dauer direkt mit der Ganzzahl 90.
Der Collector liest diese Richtlinienattribute aus dem Domänenobjekt. Für diesen Score verwendet er nicht das resultierende Passwort-Einstellungsobjekt (PSO) jedes Benutzers. Microsoft dokumentiert Get-ADUserResultantPasswordPolicy für diese gesonderte Frage auf Kontoebene. Halten Sie solche Nachweise außerhalb des reproduzierten Scores, statt die Richtlinie eines ausgewählten Benutzers an die Stelle der Domäneneingaben zu setzen.
adminCount lesen, ohne die Population umzubenennen
Microsofts Attributdefinition für adminCount beschreibt ein Objekt, dessen ACLs das System aufgrund direkter oder transitiver Mitgliedschaft in einer administrativen Gruppe verschärft hat. Dies beschreibt eine Schutzhistorie; es ist keine Abfrage der aktuellen Mitgliedschaft in Domain Admins.
Der Provider wandelt die exakte LDAP-Zeichenfolge "1" in den Benutzer-Booleschen Wert AdminCount=true um. Der Detektor schließt anschließend deaktivierte Benutzer aus. Obwohl Beschreibung und Umfangstext des Befunds „Domain Admins count“ sagen, ermittelt das tatsächliche Prädikat diese Gruppe nie. Bewahren Sie diese Unterscheidung bei der Erläuterung des Ergebnisses.
Verwenden Sie die dokumentierten Such- und Eigenschaftsparameter von Get-ADUser, um die zugrunde liegenden Benutzerdatensätze aufzubewahren:
Get-ADUser -Filter * -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties adminCount,Enabled
Dies ist ein angepasstes Dokumentationsbeispiel, keine ausgeführte Inventarisierung. Gleichen Sie anhand der zurückgegebenen Datensätze die aktivierten Benutzer, deren rohes adminCount gleich 1 ist, mit der passenden Population des Collectors ab. Bewahren Sie Objektidentitäten und Ausnahmen auf, nicht nur die Endsumme. Ein fehlendes Attribut, eine eingeschränkte Suchbasis oder eine Erfassungsgrenze müssen eingeordnet werden, bevor eine niedrige Anzahl interpretiert wird.
Ein Blatt für Berechnung und Herkunft erstellen
Füllen Sie für ein tatsächliches Audit die folgende Aufzeichnung mit beobachteten Werten aus. „Erfassung bestätigt“ bedeutet, dass die erforderliche Antwort und die Attribute für den angegebenen Umfang erfolgreich gelesen wurden; eine nicht-null Struktur allein belegt dies nicht.
| Eingabe | Collector-Quelle | Erforderlicher Nachweis zur Bestätigung der Erfassung | Zu reproduzierende Berechnung |
|---|---|---|---|
| Mindestlänge | Domänenattribut minPwdLength, zugeordnet zu MinPwdLength | Identität des Domänenobjekts, zurückgegebenes Attribut, erfolgreiches Parsen, DC und Zeitpunkt | 10 abziehen, wenn unter 14 |
| Historie | Domänenattribut pwdHistoryLength, zugeordnet zu PwdHistoryLength | Dieselbe Domänenidentität sowie Attribut- und Parsing-Nachweise | 5 abziehen, wenn unter 24 |
| Sperrschwellenwert | Domänenattribut lockoutThreshold | Attributantwort und Parsing-Nachweis; jeden Nullwert einordnen | 5 abziehen, wenn über 10 oder null |
| Höchstalter | Domänenattribut maxPwdAge, umgerechnet in ganze Tage | Rohwert, Umrechnungsergebnis und Einheiten; jeden Nullwert einordnen | 5 abziehen, wenn über 90 oder null |
| Aktivierte adminCount-Population | Bereitgestellte Users, geparstes adminCount und Deaktivierungsflag | Suchbasis, Population/Filter, Grenzen, zurückgegebene Attribute und Objektidentitäten | 10 abziehen, wenn die Anzahl 20 überschreitet |
Ergänzen Sie jede Zeile um den tatsächlichen Wert, das Erfassungsergebnis, den unabhängig ermittelten Wert und den resultierenden Abzug. Wo Nachweise fehlen, schreiben Sie „unbekannt“ in die Nachweisspalte und bewahren dabei die numerische Eingabe, die der Code verwendet hat. Ersetzen Sie die Eingabe nicht stillschweigend durch einen geschätzten Wert.
Behebung: Nachweislücken vor Richtlinienänderungen schließen (Remediation)
Gleichen Sie zunächst die Berechnung ab. Bewahren Sie den Score des Befunds, die Abzugstabelle, die Benutzerstatistiken und die Collector-Revision auf. Berechnen Sie das Ergebnis mit den bereitgestellten Eingaben erneut und ermitteln Sie, ob das Domänenobjekt vorhanden, unvollständig oder null war. Dies trennt eine arithmetische Abweichung von einer unvollständigen Beobachtung.
Ordnen Sie anschließend die Erfassung ein. Eine null kann bei diesem Provider einen konfigurierten Wert oder einen fehlenden/nicht geparsten Wert darstellen. Beschaffen Sie die entsprechende Domänenantwort und eine unabhängige Abfrage am dokumentierten DC. Gleichen Sie bei Benutzern Suchumfang und Grenzen mit der vorgesehenen Population ab. Ein erfolgreicher GetUsers-Aufruf ist ein notwendiger Nachweis, zeigt für sich allein aber nicht, dass ein absichtlich begrenztes Inventar die gesamte Domäne abdeckt.
Ist die Erfassung unvollständig, beheben Sie das konkrete Erfassungsproblem und führen Sie ein neues Audit aus. Bewahren Sie das vorherige Ergebnis als unvollständige Beobachtung auf. Beschreiben Sie den Wechsel von 85 auf 100 nach Wiederherstellung der Domäneninformationen nicht als Behebung von vier Richtlinienkontrollen, solange Richtliniennachweise vor und nach der Änderung fehlen.
Ermitteln Sie anschließend die Baseline der Organisation samt Ausgabe, Verantwortlichem und Ausnahmen. Unser Vergleich der ANSSI- und CIS-Prädikate für Passwortrichtlinien erläutert, warum verschiedene Prüfungen bei überlappenden Attributen zu unterschiedlichen Ergebnissen kommen können. Die fünf Abzüge dieses Scores sind eine gesonderte Produktberechnung; sie bilden keine dritte Rahmenwerk-Baseline.
Bei einer bestätigten Konfigurationslücke setzen Sie die genehmigte Richtlinienänderung über den etablierten Administrationsprozess um, bewahren ihren Änderungsnachweis auf, wiederholen die unabhängige Abfrage und auditieren denselben Umfang erneut. Bei einer adminCount-Abweichung untersuchen Sie die tatsächlichen Objekte und die aktuellen privilegierten Mitgliedschaften gesondert. Den Marker nur zu löschen, um den Zähler zu senken, belegt nicht, dass Privilegien oder ACL-Schutz korrekt sind.
Fügen Sie abschließend unabhängige Kontrollnachweise bei. Unsere Zuordnung von AD- und Azure-Compliance-Anforderungen zu benannten Identitätskontrollen liefert den Kontext für diese Arbeit. Protokollierung, Protokollschutz, Zugriffs-Governance und Entra-Kontrollen benötigen eigene Ergebnisse. Dieser Score untersucht diese Kontrollen nicht und kann ihre Nachweislücken nicht schließen.
Wie EtcSec dies erkennt
COMPLIANCE_SCORE ist der einzige hier behandelte Detektor. Sein Detect() liest DomainInfo und Users, wendet die fünf oben beschriebenen Bedingungen an und gibt immer einen Info-Befund mit Count=1 zurück, auch bei Score 100. Count 1 bezeichnet den zurückgegebenen Score-Befund, nicht einen betroffenen Benutzer oder eine fehlgeschlagene Kontrolle.
Die Details enthalten score, maxScore=100, deductions, totalUsers, enabledUsers und adminCount. Die Benutzersummen beschreiben die bereitgestellte Sammlung. Sie belegen keine vollständige Verzeichnisabdeckung.
Die Provider-Pfade erklären die Grenzen:
public/internal/providers/ldap/client.go:569erstellt vor der Abfrage von RootDSE und der Domäne ein Domäneninformationsobjekt. Fehlgeschlagene oder leere Antworten können ein unvollständiges Objekt mit Nullwerten hinterlassen. Die vier Richtlinienwerte stammen aus dem Domänenobjekt, nicht aus einem resultierenden PSO pro Benutzer.public/internal/providers/ldap/parser.go:155definiert den BenutzerwertAdminCountanhand des exakten ZeichenfolgenvergleichsadminCount == "1". Seine Ganzzahl-Hilfsfunktion gibt bei fehlenden Werten null zurück und ignoriert Fehler beim Parsen von Ganzzahlen.public/internal/audit/engine.go:512behandelt einen zurückgegebenenGetDomainInfo-Fehler als nicht fatal und liefert null-Domäneninformationen. Dieser Zweig ergibt 85 vor dem optionalen adminCount-Abzug von 10 Punkten. Dagegen bricht der frühere Fehlerpfad vonGetUsersdie Erfassung ab.- Die erreichbaren Berechnungswerte sind 65–100 mit einem Domänenobjekt oder 75/85 ohne eines. Ein nicht-null Objekt beweist keine erfolgreiche Attributerfassung; Interpretationsbereiche unter 65 sind für diesen Detektor unerreichbar.
Alle obigen Codeverweise beziehen sich auf die geprüfte Revision. Berichten Sie das Ergebnis als partiellen Produktindikator, gestützt auf eingeordnete Eingaben. Ein Score von 100 belegt lediglich, dass diese fünf Abzugsbedingungen nicht ausgelöst wurden; Gesamt-Compliance und Zertifizierung erfordern unabhängig definierte Kontrollen und Nachweise.
Entdecken Sie die Identity-Security-Seiten zu diesem Thema