Service Account PSO Abdeckung: jedes Konto prüfen

Was die Service Account PSO Abdeckung belegen muss

Service Account PSO Abdeckung bezeichnet den Nachweis, dass jede Dienstidentität im vereinbarten Prüfumfang anhand ihres tatsächlichen Modells zur Verwaltung von Anmeldedaten und ihrer genehmigten Passwortbaseline geprüft wurde. Bei einem herkömmlichen Domänenbenutzer, unter dem ein Dienst läuft, bedeutet dies, das resultierende Password Settings Object (PSO) auszulesen oder die Domänenstandardrichtlinie zu dokumentieren, wenn kein PSO gilt. Eine Richtlinie zu finden, die mit einem Dienstkonto verknüpft ist, belegt keine Abdeckung der übrigen Konten dieser Gruppe.

Das praktische Ergebnis ist eine Matrix: Konto, Dienst, Verantwortlicher, resultierendes PSO, Nachweis der Domänenstandardrichtlinie und Entscheidung über Ausnahmen. Fehler bei der Datenerfassung müssen in dieser Matrix sichtbar bleiben. Eine nicht zugängliche Richtlinie ist eine offene Nachweislücke; sie darf nicht stillschweigend als „geschützt“ oder „keine Richtlinie“ gelten.

Diese Unterscheidung ist bei der Interpretation eines automatisierten Befunds entscheidend. Die hier geprüfte Implementierung von etc-collector ermittelt, ob irgendein ausgewähltes Dienstkonto eine qualifizierende FGPP-Verknüpfung besitzt. Sie beantwortet nicht, ob jedes ausgewählte Konto eine genehmigte resultierende Richtlinie erhält. Ein unauffälliger Befund erfordert daher eine Abdeckungsprüfung, bevor er eine Abschlussentscheidung stützen kann.

Wie sich eine Richtlinienverknüpfung von einer resultierenden Richtlinie unterscheidet

Microsofts Referenz zu Get-ADUserResultantPasswordPolicy benennt msDS-ResultantPSO als Attribut der resultierenden Richtlinie. Direkte Zuweisungen haben Vorrang vor über Gruppen verknüpften Richtlinien. Innerhalb der jeweils anwendbaren Ebene gewinnt der niedrigste Wert von msDS-PasswordSettingsPrecedence; bei gleichen Werten entscheidet die niedrigste objectGUID, wie in Microsofts Algorithmus für das resultierende PSO festgelegt. Eine mögliche Richtlinienverknüpfung belegt somit nicht, welche Richtlinie gewinnt.

Die Abdeckungsprüfung sollte die zurückgegebene Richtlinienidentität und ihre Einstellungen festhalten, statt die wirksame Richtlinie aus einem Gruppennamen abzuleiten. Besteht neben einer scheinbar starken, über eine Gruppe verknüpften Richtlinie eine andere direkte Zuweisung, prüfen Sie das resultierende Objekt, bevor Sie die Gruppe als Schutznachweis akzeptieren. Dies ist ein Beispiel für die Schlussfolgerung, kein Bericht über eine beobachtete Fehlkonfiguration.

Davon getrennt ist die Frage, welche Identitäten in die Prüfung gehören. Microsofts Leitfaden zu Dienstkonten unterscheidet herkömmliche Dienstkonten auf Basis von Domänenbenutzern von verwalteten und virtuellen Identitäten. Er beschreibt die automatische gMSA-Passwortverwaltung und nennt keine universelle Mindestlänge für Dienstkonten. Die Prüfung muss diese Unterschiede erhalten, statt jeden dienstähnlichen Namen als gewöhnlichen Benutzer mit manuell gepflegtem Passwort zu behandeln.

Erkennung und Verifizierung: die Abdeckungsmatrix erstellen

1. Den Kontenkreis mit den Dienstverantwortlichen abstimmen

Beginnen Sie mit dem Dienstinventar und gleichen Sie es mit Kandidaten aus dem Verzeichnis ab. Erfassen Sie die stabile Kennung des Kontos, die zugehörigen Dienste, den Betriebsverantwortlichen, den Aktivierungsstatus, den Identitätstyp und die Zuständigkeit für die Verwaltung der Anmeldedaten. Dient ein Konto mehreren Anwendungen, halten Sie jede Abhängigkeit fest, statt einen passenden Dienstnamen auszuwählen.

Die Kandidatenliste des Detektors ist eine nützliche Eingabe, aber kein maßgebliches Dienstinventar. Eine Namensheuristik kann unbeteiligte Benutzer einschließen und einen Dienst übersehen, der unter einem unerwarteten Namen ohne SPN läuft. Klären Sie diese Unterschiede mit den Verantwortlichen. Unsere Prüfung von Kontonamen und wirksamen Richtlinien erläutert, warum Namen Kandidaten auswählen, ohne eine Passwortschwäche zu beweisen; verwenden Sie diese bestehende Anleitung für die weitergehende Untersuchung der Benennung.

Führen Sie deaktivierte Konten mit einer eigenen Einordnung weiter: aus dokumentiertem Grund beibehalten, zur Stilllegung vorgesehen oder mit Genehmigung von der Baseline aktiver Dienste ausgenommen. Werten Sie die Richtlinie eines deaktivierten Kontos nicht als Nachweis, dass die Population aktiver Dienste abgedeckt ist. Der Detektor trifft diese Unterscheidung nicht.

Bei verwalteten Identitäten unterstützt die dokumentierte Filterfunktion von Get-ADServiceAccount diese ausschließlich lesende Anpassung zur Inventarisierung:

Get-ADServiceAccount -Filter * -Server dc01.contoso.com

Der Befehl liefert Objekte verwalteter Dienstkonten zurück, kein vollständiges Inventar aller Dienste oder herkömmlicher Dienstkonten auf Benutzerbasis. Gleichen Sie die Ergebnisse anhand von Objektidentität und Typ mit dem Dienstinventar ab. Fordern Sie für diese Prüfung kein Material verwalteter Passwörter an. Erfassen Sie gMSAs unter ihrem Prüfpfad für verwaltete Anmeldedaten, statt sie allein deshalb als fehlerhaft zu markieren, weil ein PSO-Feld für herkömmliche Benutzer leer oder nicht anwendbar ist.

2. Für jedes herkömmliche Benutzerkonto eine resultierende Richtlinie auslesen

Führen Sie die folgende Anpassung der dokumentierten Identitäts- und Serverparameter für jedes genehmigte herkömmliche Dienstkonto auf Benutzerbasis aus. Ersetzen Sie den beispielhaften DN und Domänencontroller durch das verifizierte Ziel:

Get-ADUserResultantPasswordPolicy -Identity "CN=svc-sql,OU=Service Accounts,DC=contoso,DC=com" -Server dc01.contoso.com -ErrorAction Stop

Die Cmdlet-Referenz dokumentiert diese Parameter, die allgemeine Fehlerbehandlung und Fehler bei Verzeichnisberechtigungen. Bewahren Sie den Befehl, die abgefragte Identität, den Server, den Zeitstempel, das zurückgegebene Objekt und den Fehlerdatensatz auf. Eine erfolgreiche Antwort mit einem Richtlinienobjekt liefert Identität und Einstellungen des resultierenden PSO. Ein Fehler belegt einen erfolglosen Lesezugriff; er liefert kein Urteil über die Richtlinienabdeckung.

Wiederholen Sie den Lesezugriff für jedes Konto im Kreis herkömmlicher Benutzer. Bewahren Sie erfolgreiche Zeilen auf, wenn ein anderes Konto fehlschlägt, und lassen Sie die fehlgeschlagene Zeile offen. Wandeln Sie einen fehlgeschlagenen Aufruf in einem Export nicht in einen Nullwert der Richtlinie um und entfernen Sie fehlgeschlagene Zeilen nicht aus dem Nenner. Jede Automatisierung zur Erfassung der Matrix sollte neben dem Richtlinienfeld ein eigenes Feld für den Lesestatus führen.

3. Die Domänenstandardrichtlinie erfassen und konkurrierende Verknüpfungen erklären

Verwenden Sie das Identitätsbeispiel und den Serverparameter, die für Get-ADDefaultDomainPasswordPolicy dokumentiert sind, angepasst an die vorgesehene Domäne:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com -Server dc01.contoso.com

Bewahren Sie die Standardrichtlinie als domänenbezogenen Nachweis auf. Wird ein Benutzer erfolgreich ausgelesen, ohne dass ein PSO zurückgegeben wird, verifizieren Sie Identität und Abfragekontext und dokumentieren Sie anschließend den geltenden Standard und seine Bewertung anhand der Baseline. Lassen Sie die Zeile offen, wenn Vollständigkeit des Lesezugriffs oder Berechtigungen unklar bleiben. Ein leeres PSO-Feld allein reicht nicht aus, um die Zeile zu genehmigen.

Um mögliche Richtlinienverknüpfungen zu untersuchen, verwenden Sie die dokumentierte Filterfunktion von Get-ADFineGrainedPasswordPolicy:

Get-ADFineGrainedPasswordPolicy -Filter * -Server dc01.contoso.com

Prüfen Sie die zurückgegebenen Werte für AppliesTo, Precedence und die Einstellungen zusammen mit dem Ergebnis je Benutzer. Das Richtlinieninventar erklärt mögliche Zuweisungen; es ersetzt nicht das Auslesen der resultierenden Richtlinie. Speichern Sie nur die für die Prüfung erforderlichen Richtlinien- und Identitätsnachweise.

Ist ein verschachtelter Mitgliedschaftspfad relevant, dokumentieren Sie die Kette vom Konto zur Gruppe, das Richtlinienziel, die autorisierten Mitgliedschaftsnachweise und die zurückgegebene resultierende Richtlinie. Kennzeichnen Sie eine unvollständige Kette als unverifiziert. Leiten Sie kein wirksames PSO aus einem rekursiv wirkenden Diagramm oder dem Vergleich direkter Mitglieder durch den Detektor ab. Bitten Sie den Verzeichnisverantwortlichen, widersprüchliche Mitgliedschafts- und Richtliniennachweise abzugleichen, bevor Sie die Zeile schließen.

4. Explizite Ergebnisse je Zeile verwenden

Das folgende Schema ist ein Vorschlag für Nachweise, kein Beispiel realer Konten oder Testergebnisse:

Eine abgeschlossene Zeile kann durch ein verifiziertes resultierendes PSO, durch eine genehmigte Domänenstandardrichtlinie oder durch einen separat begründeten Kontrollpfad für verwaltete Identitäten genehmigt werden. Dies sind unterschiedliche Ergebnisse. „Zugriff verweigert“, „fehlgeschlagen“ und „Anwendbarkeit offen“ bleiben offene Nachweislücken. Eine Ausnahme ist eine dokumentierte Entscheidung, kein automatisches Bestehen.

Gleichen Sie die Matrix mit dem vereinbarten Kontenkreis ab, bevor Sie sie zusammenfassen. Berichten Sie offene Lesezugriffe und ausgeschlossene Identitäten ausdrücklich. Das Ausbleiben eines automatisierten Befunds darf diese Zeilen nicht verschwinden lassen.

Die Baselinelücke jedes Kontos beheben (Remediation)

1. Einstellungen anhand des Dienstkontexts genehmigen

Ermitteln Sie anhand der Matrix, welche herkömmlichen Konten ihre genehmigte Baseline nicht erfüllen. Lassen Sie Dienst- und Verzeichnisverantwortliche die erforderlichen Passworteinstellungen, die betriebliche Kompatibilität, die Pflege der Anmeldedaten und den Rolloutplan abstimmen. Prüfen Sie die zurückgegebenen Einstellungen als Ganzes; ein Vergleich der Mindestlänge allein reicht für eine lokal genehmigte Baseline nicht aus.

Der Wert 20 des Detektors ist ein Implementierungsschwellenwert. Machen Sie daraus keine Microsoft-Anforderung für alle Dienste und übernehmen Sie keine Richtlinieneinstellungen aus Demonstrationen als Produktionsempfehlungen. Halten Sie die genehmigte Baseline des Dienstes und ihre Begründung bei der Kontozeile fest.

2. Zuweisungen und Nachweislücken gezielt korrigieren

Wo eine genehmigte FGPP vorgesehen ist, planen Sie die erforderliche Korrektur von Zuweisung oder Vorrang über den Änderungsprozess des Verzeichnisses. Berücksichtigen Sie konkurrierende direkte Zuweisungen und andere Nutzer derselben Richtlinie, bevor Sie die Änderung vornehmen. Erstellen Sie nicht lediglich eine qualifizierende Verknüpfung, um den Zähler des Detektors zu senken.

Ein verweigerter Lesezugriff benötigt autorisierten Zugang oder einen anderen genehmigten Weg zur Nachweiserfassung, bevor über die Abdeckung entschieden werden kann. Erfassen Sie den ursprünglichen Fehler und den anschließenden erfolgreichen Lesezugriff gemeinsam. Die Korrektur der Erfassung ist eine Voraussetzung für die Interpretation der Richtlinie; sie behebt selbst keine Probleme mit den Anmeldedaten des Kontos.

Dokumentieren Sie bei beibehaltenen Ausnahmen die Dienstabhängigkeit, den Verantwortlichen, kompensierende Maßnahmen, den Genehmigenden und das nächste Prüfdatum. Halten Sie die Ausnahme der Zeile in künftigen Abdeckungsberichten sichtbar. Eine Ausnahme ohne Verantwortlichen oder mit abgelaufener Gültigkeit sollte erneut geprüft werden.

3. Entscheidungen zu verwalteten Konten und Stilllegung trennen

Bewerten Sie bei einem für gMSA geeigneten Dienst mit dem Verantwortlichen eine Migration zu einer verwalteten Identität und validieren Sie Kompatibilität und autorisierten Abruf der Anmeldedaten. Dies ist eine andere Änderung als die Zuweisung einer FGPP an ein herkömmliches Konto. Bewahren Sie Klassifizierungsentscheidung und Migrationsnachweise in der Matrix auf.

Klären Sie bei deaktivierten Identitäten die Abhängigkeiten und den Grund für ihre Aufbewahrung vor der Stilllegung. Entfernen Sie Konten nicht massenhaft, weil sie in einer Abdeckungsprüfung auftauchen. Lassen Sie umgekehrt nicht zu, dass eine ungenutzte, aber qualifizierende Identität Lücken bei aktiven Diensten verdeckt.

Zur Angriffsexposition behandelt unser Kerberoasting-Leitfaden zu Diensttickets und Geheimnissen von Dienstkonten die separate Untersuchung von Tickets, Geheimnissen und Berechtigungen. Diese Matrix belegt die Abdeckung der Richtlinienprüfung; sie beweist weder Widerstandsfähigkeit gegen Offline-Cracking noch die Abwesenheit böswilliger Aktivitäten.

4. Die Lesezugriffe nach genehmigten Änderungen wiederholen

Führen Sie nach der genehmigten Änderung den Befehl für die resultierende Richtlinie je Benutzer sowie die relevanten Inventarabfragen erneut aus. Fügen Sie jeder betroffenen Zeile Vorher- und Nachher-Nachweise hinzu und lassen Sie anschließend die Verantwortlichen den Dienstbetrieb und den Plan zur Pflege der Anmeldedaten validieren. Ein verändertes PSO-Ergebnis belegt ein Richtlinienergebnis, nicht die Qualität eines bestehenden Geheimnisses.

Wie EtcSec dies erkennt

Die Prüfung SERVICE_ACCOUNT_WEAK_PASSWORD_POLICY von etc-collector hat die Kategorie Password und den Schweregrad Medium. Diese Beschreibung stammt aus public/internal/audit/detectors/ad/password/service-account-password-policy.go:39 beim Collector-Commit 0423094759d50002457031317098417993e19510.

Sie wählt erfasste Benutzer mit einem SPN oder einem wahrscheinlichen Dienstnamen aus: den Präfixen svc_, svc-, sa_, sa-, sql, iis oder app oder der Teilzeichenfolge service, nachdem sAMAccountName in Kleinbuchstaben umgewandelt wurde. Ausgewählte Konten müssen einen nicht leeren DN besitzen. Die resultierende DN-Menge wird dedupliziert, ohne deaktivierte Konten auszuschließen oder gMSAs getrennt zu behandeln.

Die Prüfung sucht anschließend in den erfassten FGPPs nach einer Mindestlänge von mindestens 20. Eine direkte Übereinstimmung von AppliesTo mit einem ausgewählten Konto oder eine Übereinstimmung mit der direkten Members-Liste einer Gruppe, die ein solches Konto enthält, setzt ihr Abdeckungsflag. Die Suche endet nach der ersten qualifizierenden Beziehung.

Folglich bedeutet Count=1, dass ausgewählte Konten existieren und in den erfassten Daten keine qualifizierende Beziehung gefunden wurde. Count=0 bedeutet entweder, dass keine Konten ausgewählt wurden, oder dass mindestens eine qualifizierende Beziehung gefunden wurde. Count ist binär, nicht die Anzahl unabgedeckter Konten. Die Details enthalten serviceAccountCount: die Größe der ausgewählten DN-Menge, keine Abdeckungssumme.

Die Prüfung liest msDS-ResultantPSO nicht aus, berechnet keinen wirksamen Vorrang, löst keine verschachtelten Gruppen auf, vergleicht nicht jedes Konto mit einer Baseline, untersucht kein bestehendes Passwort und verifiziert keine MFA. Ihr Beschreibungstext darf nicht als Nachweis behandelt werden, dass diese Kontrollen getestet wurden.

Auch die Erfassung begrenzt die Schlussfolgerung. In public/internal/providers/ldap/client.go:1835 liefert GetFGPPs bei einem fehlgeschlagenen Suchzugriff auf den Richtliniencontainer nil, nil zurück. Die Engine akzeptiert einen nil-Fehler in public/internal/audit/engine.go:557; dieser Pfad unterscheidet für diesen Detektor nicht zwischen einem unzugänglichen Container und einer leeren Richtlinienliste. Bei ausgewählten Konten kann diese leere Eingabe zu Count=1 führen. Untersuchen Sie die Erfassung, bevor Sie behaupten, es gebe keine Richtlinien.

Entscheidungen vor dem Abschluss dokumentieren

Klären Sie drei Fragen mit den zuständigen Verantwortlichen:

1. Welche Identitäten führen tatsächlich Dienste aus, einschließlich deaktivierter und verwalteter Konten, und welcher Kontrollpfad gilt jeweils?
2. Wie wurden verweigerte Lesezugriffe, fehlgeschlagene Abfragen und relevante verschachtelte Mitgliedschaften dokumentiert und abgeglichen?
3. Welche Baseline ist für jeden Dienst genehmigt, und welche beibehaltenen Ausnahmen besitzen einen Genehmigenden und ein Prüfdatum?

Bewahren Sie die Definition des Kontenkreises, die Richtlinienabfragen, Erklärungen zu Mitgliedschaften, Änderungsnachweise und Entscheidungen gemeinsam auf, ohne Geheimnisse zu exportieren. Die abschließende Aussage zur Abdeckung sollte die tatsächlich geprüften Konten und die weiterhin offenen Lücken beschreiben. Sie darf niemals aus einer einzigen qualifizierenden FGPP-Beziehung universellen Schutz ableiten.