Kontonamen Passwortmuster Active Directory: Namensprüfung

Was gebräuchliche Kontonamen tatsächlich anzeigen

Der Ausdruck Kontonamen Passwortmuster Active Directory beschreibt eine Heuristik für Namen, keinen Passworttest. Ein aktiviertes Konto namens admin, test oder temp verdient eine Prüfung seiner Zuständigkeit und Exposition. Sein Name verrät weder das Passwort noch beweist er dessen Schwäche oder einen erfolgten Angriff. Diese Unterscheidung ergibt sich unmittelbar aus der Implementierung von PASSWORD_COMMON_PATTERNS in public/internal/audit/detectors/ad/password/common-patterns.go:26.

Ein generischer Name kann dazu führen, dass eine Identität leichter in eine durch Raten erstellte Zielliste aufgenommen wird. Das ist eine Schlussfolgerung zur Auswahl von Kandidaten, keine gemessene Rangfolge der ersten Ziele von Angreifern. Microsofts ältere Referenz zum Umbenennen von Administrator beschreibt einen begrenzten Vorteil durch die Änderung dieses bekannten Kontonamens sowie die Einschränkung durch seine bekannte SID. Sie bestätigt weder eine allgemeingültige Rangfolge von admin, test und temp noch die fünfzehn Muster des Collectors.

Die hilfreiche Frage lautet daher: Welche Aufgabe hat diese Identität, wer ist dafür verantwortlich und welche Kontrollen schützen ihre tatsächlichen Authentifizierungswege? Behandeln Sie den Befund als Warteschlange für Prüfungen. Ein aussagekräftiger Dienstname kann legitime Abläufe unterstützen; ein wie ein Personenname wirkender Name kann dennoch einen schlechten Umgang mit Zugangsdaten verbergen. Der Detektor kann diese Fälle nicht unterscheiden, weil er Namen statt Geheimnissen oder Aktivitäten untersucht.

Wie Password Spraying funktioniert

Microsofts Leitfaden zur Klassifizierung von Password Spraying beschreibt, wie eine kleine Auswahl häufig verwendeter Passwörter bei vielen Konten ausprobiert wird. Das unterscheidet sich vom wiederholten Erraten vieler Passwörter für eine einzelne Identität. Die Kontobenennung betrifft die Zielliste; Password Spraying betrifft Authentifizierungsversuche. Ein Inventar passender Namen belegt Ersteres, nicht Letzteres.

Das Playbook zur Untersuchung von Password Spraying unterscheidet außerdem zwischen der Kompromittierung eines Passworts und der eines Kontos. Ein Angreifer kann das richtige Passwort finden, während MFA den Zugriff verhindert. Bei der Untersuchung müssen erfolgreiche und unterbrochene Authentifizierungen, MFA-Ergebnisse und nachfolgende Aktivitäten geprüft werden. Ein gescheiterter abschließender Anmeldevorgang beweist nicht, dass das Passwort unbekannt geblieben ist.

Die zu untersuchende Angriffskette

Eine belastbare Untersuchung folgt dem in diesen Microsoft-Playbooks dokumentierten Ablauf: mögliche Zielkonten und Authentifizierungswege identifizieren, verdächtige Versuche korrelieren, feststellen, ob ein Passwort akzeptiert wurde, und daraus entstandene Zugriffe untersuchen. Generische Namen können den ersten Schritt unterstützen. Für die weiteren Schritte liefern sie keine Belege. Langsame, unauffällige Aktivitäten können unterhalb der Sperrschwellen bleiben; eine fehlende Kontosperre ist daher kein Grund, den Verdacht automatisch zu verwerfen.

Für den umfassenderen Mechanismus, die Ermittlung von Benutzernamen, die Erkennung und die Kontrollen in beiden Umgebungen verwenden Sie unseren Leitfaden zu Password Spraying in Active Directory und Entra ID. Dieser Artikel konzentriert sich auf das genaue Namensprädikat, falsche Annahmen dazu und die Belege, die zur Klärung eines Namensbefunds erforderlich sind.

Keine Namensliste erfasst sämtliche möglichen Ziele von Password Spraying. Prüfen Sie auch Identitäten außerhalb dieser Muster, wenn die Authentifizierungstelemetrie dies nahelegt. Umgekehrt dürfen Sie nicht jedes passende Konto als kompromittiert einstufen: Microsofts Klassifizierungsprozess verlangt ausdrücklich, bösartige Aktivitäten von Fehlalarmen zu unterscheiden.

Konten und ihre wirksame Richtlinie erfassen

1. Ein Inventar erstellen, ohne Geheimnisse zu sammeln

Die folgenden Befehle sind dokumentierte Beispiele oder Parameteranpassungen für einen autorisierten Administrator. Für diesen Artikel wurden sie nicht gegen eine Domäne ausgeführt. Verwenden Sie das Modul ActiveDirectory, geeignete Verzeichnisberechtigungen und den vorgesehenen Domänen- oder Serverkontext. contoso.com und die Kontonamen dienen der Veranschaulichung; prüfen Sie das Ziel, bevor Sie einen verändernden Befehl verwenden.

Get-ADUser dokumentiert die Filterung, das Abrufen aktivierter Konten und die Anforderung zusätzlicher Eigenschaften. Dieser defensive Filter passt diese Möglichkeiten an die dreizehn vollständigen Namen, eine Teilzeichenfolge und eine Endung des Collectors an. Die Liste stammt aus dem Detektor, nicht aus einem Microsoft-Beispiel, das diese Namen als Beweis für schwache Passwörter anerkennt.

Get-ADUser -Filter 'Enabled -eq $true -and (SamAccountName -eq "admin" -or SamAccountName -eq "administrator" -or SamAccountName -eq "test" -or SamAccountName -eq "user" -or SamAccountName -eq "guest" -or SamAccountName -eq "temp" -or SamAccountName -eq "default" -or SamAccountName -eq "support" -or SamAccountName -eq "service" -or SamAccountName -eq "backup" -or SamAccountName -eq "demo" -or SamAccountName -eq "sa" -or SamAccountName -eq "dba" -or SamAccountName -like "*password*" -or SamAccountName -like "*123")' -Properties DisplayName,Enabled

DisplayName unterstützt hier die menschliche Prüfung. Es ist kein Bestandteil des Detektors. Ein Konto mit dem Anzeigenamen Test und dem sAMAccountName alex.smith wird durch das Muster test nicht ausgewählt. Umgekehrt passt User123 zur Endung, obwohl es nicht dem Ausdruck für den vollständigen Namen user entspricht. Diese Beispiele ergeben sich aus den Abgleichregeln des Codes.

Dokumentieren Sie neben dem Inventar auch Verantwortliche, Kontozweck, Abhängigkeiten und Prüfentscheidung. Bevor Sie die Anzahl lokaler Ergebnisse mit einem Collector-Ergebnis vergleichen, gleichen Sie Verzeichnisumfang, Erfassungszeitpunkt, Aktivierungszustand und Abgleichverhalten ab. Gehen Sie nicht davon aus, dass die kurze Namensliste in einem Befund sämtliche betroffenen Konten enthält.

2. Die Domänenrichtlinie lesen

Dies passt Beispiel 3 aus Get-ADDefaultDomainPasswordPolicy an eine Beispieldomäne an:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com

Prüfen Sie MinPasswordLength, ComplexityEnabled, PasswordHistoryCount, LockoutThreshold, LockoutDuration und LockoutObservationWindow. Das sind Richtlinienbelege. Der Kontoname liefert für keine dieser Eigenschaften einen Wert. Das Lesen der domänenweiten Richtlinie stellt außerdem nicht fest, ob für einen ausgewählten Benutzer ein anderes resultierendes Password Settings Object gilt.

3. Granulare Richtlinien inventarisieren

Verwenden Sie die von Get-ADFineGrainedPasswordPolicy dokumentierte Filterfunktion, um die Richtlinienobjekte abzurufen:

Get-ADFineGrainedPasswordPolicy -Filter *

Prüfen Sie AppliesTo und Precedence ebenso wie die tatsächlichen Einstellungen. Microsofts Leitfaden zu granularen Passwortrichtlinien erklärt, dass diese Richtlinien auf Benutzerobjekte und globale Sicherheitsgruppen angewendet werden. Sie gelten nicht unmittelbar für eine OU. Ein generisches Konto in einer administrativen OU unterzubringen, begründet daher für sich allein keine stärkere wirksame Passwortrichtlinie.

4. Die resultierende Richtlinie des ausgewählten Benutzers prüfen

Dies passt das Identitätsbeispiel aus Get-ADUserResultantPasswordPolicy an:

Get-ADUserResultantPasswordPolicy -Identity test

Dieses Cmdlet ruft das resultierende PSO des Benutzers ab. Ein direkt dem Benutzer zugewiesenes PSO hat Vorrang vor PSOs, die über globale Sicherheitsgruppen geerbt werden. Gelten mehrere PSOs unmittelbar, gewinnt darunter der niedrigste Rangfolgewert; gruppenverknüpfte PSOs werden nur verglichen, wenn keines direkt gilt. Gilt kein PSO, bewerten Sie den Domänenstandard. Ein leeres PSO-Ergebnis ist keine Messung der Passwortstärke.

Unser Leitfaden zur Passwortsicherheit in Active Directory untersucht sechs weitere Aspekte: Ablaufkennzeichen, Richtlinienschwächen, Kennzeichen für nicht erforderliche Passwörter, offengelegte Geheimnisse in Beschreibungen, WDigest und NTLMv1 sowie FGPP und den Umgang mit Dienstkonten. Diese unterscheiden sich von diesem Namensprädikat. Ersetzen Sie die Prüfung dieser Kontrollen nicht durch einen behobenen Namensbefund und übernehmen Sie keine Richtlinienwerte aus Demonstrationen als Sicherheitsbaseline.

Erkennung: 4625, 4740 und 4771 korrelieren

Die richtigen Systeme und Felder erfassen

Bauen Sie die Beweislage um den Authentifizierungsweg herum auf. Ereignis 4625 wird auf dem Computer aufgezeichnet, auf dem die fehlgeschlagene Anmeldung stattfindet; das kann ein Domänencontroller, Mitgliedsserver oder eine Arbeitsstation sein. Die Erfassung nur eines DC garantiert nicht, dass alle fehlgeschlagenen Anmeldungen abgedeckt sind. Prüfen Sie die Abdeckung von Audit Logon und Audit Account Lockout entsprechend den dokumentierten Unterkategorien des Ereignisses.

Beziehen Sie für Domänenkonten die Security-Protokolle der DCs für Ereignis 4740 unter Audit User Account Management und Ereignis 4771 unter Audit Kerberos Authentication Service ein. Microsoft dokumentiert, dass 4771 ausschließlich auf DCs auftritt und fehlt, wenn das Konto keine Kerberos-Präauthentifizierung benötigt.

Die Fehlercodes präzise auslegen

Die Überwachungsreferenz zu 4625 beschreibt 0xC000006A als falsches oder falsch eingegebenes Passwort, 0xC0000064 als falschen oder falsch geschriebenen Kontonamen und 0xC000006D als falschen Benutzernamen oder falsche Authentifizierungsinformationen. Die Ereignisdokumentation beschreibt 0xC0000234 als gesperrtes Konto. Bewahren Sie Status und SubStatus; reduzieren Sie die Untersuchung nicht auf eine einzige allgemeine Fehlerbezeichnung.

Bei 4771 bedeutet 0x18 KDC_ERR_PREAUTH_FAILED: ungültige Präauthentifizierungsinformationen, wobei ein falsches Passwort als Ursache dokumentiert ist. 0x6 ist KDC_ERR_C_PRINCIPAL_UNKNOWN und bedeutet, dass der Client nicht in der Kerberos-Datenbank gefunden wurde. 0x12 ist KDC_ERR_CLIENT_REVOKED und bedeutet, dass die Clientanmeldeinformationen widerrufen wurden. Setzen Sie 0x12 nicht automatisch ausschließlich mit einer Kontosperre gleich und behandeln Sie diese Codes nicht als austauschbar mit den Statusfeldern von 4625.

Diese Unterscheidungen helfen dabei, Versuche mit unbekannten Namen von Versuchen mit falschen Passwörtern und den Folgen von Kontosperren zu trennen. Sie offenbaren dennoch nicht das ausprobierte Passwort. Eine auf diesen Ereignissen beruhende Korrelationsregel kann nicht beweisen, dass bei jedem Konto dasselbe Geheimnis übermittelt wurde.

Verhalten korrelieren und anschließend die Erklärung prüfen

Ein redaktioneller Erkennungsentwurf besteht darin, Fehlschläge nach Zeitfenster und Quelle zu gruppieren, unterschiedliche Zielkonten zu zählen und diese Identitäten mit dem Namensinventar zu verknüpfen. Ermitteln Sie eine lokale Baseline, bevor Sie ein Zeitfenster oder eine Alarmschwelle wählen. Dies ist ein zu implementierender und zu validierender Entwurf, keine kopierte Microsoft-Abfrage oder gemessene Schwelle für Ihre Umgebung.

Vergleichen Sie das Muster mit erwartbaren Benutzereingabefehlern und Diensten, die alte Zugangsdaten erneut verwenden. Erweitern Sie die Suche bei wechselnden Quellen und untersuchen Sie dann erfolgreiche oder unterbrochene Anmeldungen sowie ungewöhnliche nachfolgende Aktivitäten. Microsofts Spraying-Playbooks unterstützen die Korrelation von Zeitverlauf, Quelle, Konto und Folgeaktivitäten. Eine Kampagne kann unter der Sperrschwelle bleiben; 4740 zwingend vorauszusetzen, würde daher eine Erkennungslücke hinterlassen.

Beziehen Sie in einer hybriden Umgebung Entra-Anmelde- und MFA-Datensätze sowie gegebenenfalls die Protokolle des föderierten Identitätsanbieters ein. Das Untersuchungsplaybook erklärt, dass der Speicherort der Protokolle von verwalteter oder föderierter Authentifizierung abhängt. Ein akzeptiertes Passwort mit anschließend gescheiterter MFA verdient eine Untersuchung, auch wenn letztlich kein Anwendungszugriff erfolgte. Ein unauffälliger Kontonamenbericht kann diesen Vorfall nicht klären.

Behebung: Zweck, Exposition und Kontrollen klären (Remediation)

1. Jede Identität mit ihren Verantwortlichen prüfen

Unterscheiden Sie in einem Prüfprotokoll zwischen menschlichen, gemeinsam genutzten, Test-, Dienst-, integrierten und Wiederherstellungsidentitäten. Diese Klassifizierung ist eine betriebliche Empfehlung, keine Berechnung der Regex. Fragen Sie, wofür das Konto noch benötigt wird, wer es verwenden kann, welche Authentifizierungswege es akzeptieren und was von seinem aktuellen Namen oder seinen Zugangsdaten abhängt.

Bevorzugen Sie persönlich zuordenbare Zugriffe und dokumentieren Sie Ausnahmen, Verantwortliche und Ablaufdaten für vorübergehende Anforderungen. Prüfen Sie Berechtigungen gesondert: support belegt keine Helpdesk-Berechtigungen, und backup belegt nicht, auf welche Ressourcen das Konto zugreifen kann. Der Namenscode enthält kein Prädikat für Gruppenmitgliedschaften oder Berechtigungen.

Für Tests behandelt Microsofts Leitfaden für Entra-Testumgebungen dedizierte Mandanten oder angemessen isolierte Ressourcen und App-Registrierungen. Dies ist ein Verfahren für Entra-Anwendungen, keine Anleitung für eine native AD-Bereitstellung. Sein Isolierungsprinzip auf AD-Testidentitäten anzuwenden, ist eine Governance-Empfehlung: Definieren Sie eine Testgrenze und einen für Ihre Domäne geeigneten Lebenszyklus.

2. Unnötige Konten nach Prüfung der Abhängigkeiten stilllegen

Bei einem gewöhnlichen Konto, dessen Entbehrlichkeit bestätigt wurde, prüfen Sie zuerst mit den Verantwortlichen abhängige Dienste, geplante Aufgaben, Anwendungen und Wiederherstellungsvorkehrungen. Planen Sie anschließend eine gezielte Deaktivierung. Dies passt Beispiel 1 aus Disable-ADAccount an eine beispielhafte, überprüfte Testidentität an:

Disable-ADAccount -Identity test

Verwenden Sie das Namensinventar nicht als Eingabe für eine massenhafte Deaktivierung. Der Filter kann nicht erkennen, ob eine Identität betrieblich unverzichtbar ist. Eine geplante Umbenennung ist eine weitere mögliche administrative Maßnahme, nachdem die Nutzer des aktuellen Namens geprüft wurden. Folgendes verwendet die dokumentierten Identitäts- und SamAccountName-Parameter von Set-ADUser:

Set-ADUser -Identity test -SamAccountName app-validation

Das ändert den SAM-Kontonamen. Es ändert weder das Passwort noch reduziert es Berechtigungen, erzwingt MFA oder beweist, dass das Konto nicht mehr auffindbar ist. Wählen Sie Namen für betriebliche Klarheit und Nachvollziehbarkeit; eine niedrigere Anzahl von Regex-Treffern rechtfertigt eine Umbenennung nicht ausreichend.

3. Die Wiederherstellungsrolle des integrierten Administrator bewahren

Ein aktivierter Administrator wird vom Detektor erfasst, weil es keine Ausnahme für SIDs oder integrierte Konten gibt. Stellen Sie vor einer Stilllegungsentscheidung fest, welches Konto Sie prüfen. Deaktivieren Sie den integrierten Administrator der Domäne nicht unbesehen, weil er in der Namensliste auftaucht.

Microsofts Leitfaden zum integrierten Administrator sieht dessen Verwendung für den anfänglichen Aufbau und eine mögliche Notfallwiederherstellung vor. Die Seite hat ihre frühere Deaktivierungsempfehlung ausdrücklich entfernt, weil die Gesamtstrukturwiederherstellung dieses Konto verwendet, einschließlich der Anmeldung ohne Global-Catalog-Server. Stattdessen beschreibt sie Einschränkungen und die Überwachung der Verwendung, von Passwortzurücksetzungen und Kontoänderungen.

Wenden Sie Einschränkungen im Rahmen eines überprüften Wiederherstellungsplans und des dokumentierten Geltungsbereichs an. Die Seite warnt davor, die GPO mit den Einschränkungen auf Domänenebene zu verknüpfen, da Administrator dadurch während der Wiederherstellung unbrauchbar werden kann. Übertragen Sie die historischen Aussagen zur Kontosperre aus der alten Seite zum Umbenennen von Administrator nicht auf eine ungeprüfte Behauptung über alle Windows-Versionen und -Konfigurationen.

4. gMSAs für AD-Dienste und verwaltete Identitäten für Azure verwenden

Prüfen Sie für Windows-Dienste mit gewöhnlichen Domänenbenutzern eine Migration zu gMSA, soweit unterstützt. Microsofts Windows-Server-Dokumentation zu Dienstkonten beschreibt automatische Passwortverwaltung und eine gemeinsame Dienstidentität über mehrere Server hinweg. Prüfen Sie vor der Migration Dienstkompatibilität, die zum Abruf von Zugangsdaten autorisierten Hosts, Ressourcenberechtigungen und SPNs. Diese Empfehlung betrifft den Umgang mit Dienstzugangsdaten, nicht jedes menschliche Konto mit einem passenden Namen.

Für Azure-Workloads bevorzugt Microsofts Leitfaden zu Clouddienstkonten nach Möglichkeit verwaltete Identitäten und bei Bedarf Dienstprinzipale gegenüber benutzerbasierten Entra-Dienstkonten. Halten Sie diese Wahl einer Cloudidentität von einer AD-gMSA-Bereitstellung getrennt.

Wenn eine Anwendung tatsächlich gemeinsame Zugangsdaten benötigt, beschreibt der Entra-Leitfaden zur gemeinsamen Kontonutzung passwortbasiertes SSO, das den Zugriff über individuelle Identitäten vermittelt. Benutzer müssen das gemeinsame Passwort nicht erhalten; Administratoren können den Zugriff entziehen, MFA verlangen und Anmeldedatensätze prüfen. Die Passwortrotation hängt von der Anwendungsunterstützung ab. Dies ist eine bestimmte Option für Anwendungszugriffe, keine allgemeingültige Lösung für gemeinsame AD-Anmeldungen.

5. FGPP, Kontosperre und MFA auf den tatsächlichen Wegen prüfen

Wählen Sie Passwort- und Sperreinstellungen entsprechend der Kontopopulation und dem Risiko und prüfen Sie anschließend die resultierende Richtlinie mit den oben genannten Inventarbefehlen. FGPP kann Richtlinien für Benutzer und globale Sicherheitsgruppen differenzieren. Setzen Sie Microsofts Beispiel LockoutThreshold=0 nicht allein deshalb ein, weil es in einer Demonstration vorkommt: Richtliniensyntax und Sicherheitsempfehlungen haben unterschiedliche Zwecke.

Die Referenz zur Kontosperrschwelle beschreibt die Abwägung zwischen Widerstand gegen Passwort-Raten und Dienstverweigerung durch absichtliche Kontosperren. Ihre Erläuterung zur Windows-Baseline nennt zehn ungültige Versuche als möglichen Ausgangspunkt, ausdrücklich ohne eine allgemeingültige Schwelle festzulegen. Prüfen Sie Schwelle, Dauer, Rücksetzfenster, Entsperrverfahren und Überwachung gemeinsam.

Entra Smart Lockout ist eine separate Kontrolle neben der AD-DS-Kontosperre. Sie unterscheidet vertraute und unbekannte Standorte und verfolgt zuletzt verwendete falsche Passwort-Hashes; diese Hash-Verfolgung steht bei Passthrough-Authentifizierung nicht zur Verfügung. Für PTA verlangt Microsoft eine niedrigere Entra-Schwelle, eine mindestens zwei- oder dreimal höhere AD-DS-Schwelle und eine längere Entra-Dauer. Prüfen Sie Ihren Authentifizierungsmodus und die tatsächlichen Einstellungen, statt ein Beispiel als allgemeingültige Regel zu übernehmen.

Erzwingen Sie MFA auf kompatiblen exponierten Wegen und prüfen Sie Legacy-Authentifizierung, wie es das Playbook zur Untersuchung von Spraying empfiehlt. Eine Entra-MFA-Richtlinie macht MFA nicht automatisch auf traditionellen AD-Authentifizierungswegen erforderlich. Wenn die Telemetrie eine Passwort- oder Kontokompromittierung belegt, folgen Sie der Incident Response, einschließlich Änderungen von Zugangsdaten und des angemessenen Widerrufs von Sitzungen beziehungsweise Tokens, statt den Fall nach einer Kontoumbenennung zu schließen.

Wie EtcSec dies erkennt

Die Prüfung des etc-collector heißt PASSWORD_COMMON_PATTERNS, Kategorie Password, Schweregrad High. Ihre Detect()-Methode beginnt bei public/internal/audit/detectors/ad/password/common-patterns.go:26; die fünfzehn exakten Ausdrücke werden in den Zeilen 28–44 deklariert:

(?i)^admin$
(?i)^administrator$
(?i)^test$
(?i)^user$
(?i)^guest$
(?i)^temp$
(?i)^default$
(?i)^support$
(?i)^service$
(?i)^backup$
(?i)^demo$
(?i)password
123$
(?i)^sa$
(?i)^dba$

Die Implementierung durchläuft die erfassten Benutzer und schließt ausschließlich Konten mit Disabled aus. Sie wandelt SAMAccountName in Kleinbuchstaben um und prüft diese Ausdrücke. Dreizehn entsprechen vollständigen Namen; password passt an beliebiger Stelle und 123$ am Ende. Daher werden admin01, test1, temp-user und svc-sql allein aufgrund dieser Namen nicht ausgewählt; resetPasswordHelp und User123 werden ausgewählt.

Sie fügt ein Konto beim ersten passenden Ausdruck hinzu und beendet die innere Schleife. Ein Konto, das zu mehr als einem Ausdruck passt, wird nur einmal gezählt. Diese Implementierung enthält keine Ausnahme aufgrund von SID/RID, OU, privilegierter Gruppe, Dienstzweck oder Zulassungsliste.

Count umfasst alle passenden aktivierten Benutzer. Details.affectedAccountNames enthält höchstens zehn Namen, auch ohne IncludeDetails. Zehn angezeigte Namen bedeuten daher nicht, dass nur zehn passende Konten existieren. AffectedEntities wird hinzugefügt, wenn Details angefordert werden und die Anzahl positiv ist; der Befund selbst wird auch bei null zurückgegeben.

Der Detektor liest weder displayName noch irgendein Passwort oder einen Passwort-Hash. Er misst keine Passwortentropie, führt keine Authentifizierung durch, bewertet weder Sperrrichtlinien noch MFA und untersucht keine Aktivitäten, um einen Spraying-Versuch oder -Erfolg zu beweisen. Sein Beschreibungstext deutet ein Risiko durch Standardpasswörter an, doch diese Hinweise sind keine Prädikate im Code.

Das Ergebnis validieren

Wiederholen Sie nach genehmigten Änderungen dieselben Inventar- und Richtlinienabfragen. Dokumentieren Sie beibehaltene Ausnahmen und Wiederherstellungsanforderungen und bestätigen Sie mit den Verantwortlichen, dass Dienste und Anwendungen weiterhin funktionieren. Prüfen Sie anhand von Microsofts Untersuchungsleitfaden die relevanten Authentifizierungsdatensätze auf verbleibende verdächtige Aktivitäten.

Schließen Sie jede Prüfung mit dem Ergebnis ab, das sie tatsächlich belegt: eine unnötige Identität stillgelegt, eine Abhängigkeit migriert, eine wirksame Richtlinie überprüft oder eine Ausnahme mit Begründung beibehalten. Benennung, Passwortrichtlinie, Zugriffsdurchsetzung und Angriffsbelege beantworten unterschiedliche Fragen. Eine abgeschlossene Namensprüfung sollte diese Antworten klarer machen, ohne zu behaupten, dass eine Regex ein Geheimnis getestet hat.