Entra ID Passwortschutz: Eigene Listen und die Ablauffalle

Was ist Entra ID Passwortschutz?

Entra ID Passwortschutz (Entra ID Password Protection) prüft neue Passwörter anhand der globalen Liste gesperrter Begriffe von Microsoft und, sofern konfiguriert, einer benutzerdefinierten Liste der Organisation. Bei der betrieblichen Prüfung stellen sich drei getrennte Fragen: Sind organisationsspezifische Begriffe abgedeckt, werden lokale Passwortänderungen tatsächlich blockiert und erzwingt der Passwortablauf weiterhin regelmäßige Änderungen?

Microsoft beschreibt die globale Liste in der Cloud als automatisch aktiv und nicht deaktivierbar. Eine fehlende benutzerdefinierte Liste bedeutet daher nicht, dass der Mandant keinen Passwortschutz hat. Sie bedeutet, dass die Organisation den Basisschutz nicht um ihren eigenen Wortschatz ergänzt hat. Die Validierung erfolgt bei Passwortänderungen und Zurücksetzungen. Microsoft Learn: Konzepte des Passwortschutzes.

Betrachten Sie dies als Kontrollprüfung im Rahmen des umfassenderen Sicherheitsaudits für Microsoft Entra ID. Dort wird erklärt, wie durchsetzbare Zugriffskontrollen, privilegierte Rollen, das Vertrauen in Anwendungen und externe Identitäten geprüft werden. Eine Passwortrichtlinie allein beantwortet diese weitergehenden Fragen nicht.

Funktionsweise: Warum die globale Liste nicht genügt

Microsoft erstellt seine globale Liste anhand der Sicherheitstelemetrie von Entra. Die benutzerdefinierte Liste ergänzt lokale Begriffe wie Marken, Produkte, Standorte der Unternehmenszentrale und interne Abkürzungen. Beide Listen wirken zusammen; die benutzerdefinierte Liste ersetzt den globalen Basisschutz nicht. Microsoft Learn: Benutzerdefinierte gesperrte Passwörter.

Gehen Sie nicht davon aus, dass jedes Passwort mit einem aufgeführten Begriff abgelehnt werden muss. Der Bewertungsalgorithmus normalisiert die Eingabe, prüft Varianten und bewertet das resultierende Passwort; ein ausreichend starkes Passwort kann einen gesperrten Begriff enthalten und trotzdem akzeptiert werden. Lesen Sie den dokumentierten Bewertungsalgorithmus, bevor Sie Validierungstests entwerfen.

Diese Unterscheidung verändert die Gestaltung einer sinnvollen benutzerdefinierten Liste. Prüfen Sie den Wortschatz der Organisation, statt eine riesige Sammlung vollständiger Passwörter zu importieren. Fragen Sie, ob aktuelle Marken, Namen übernommener Unternehmen, Produktfamilien und lokal bedeutsame Abkürzungen enthalten sind. Verknüpfen Sie Testfälle mit den konfigurierten Begriffen, damit eine Ablehnung untersucht und nicht bloß vorausgesetzt werden kann.

Der Artikel über Password Spraying erklärt den Angriff: Eine kleine Anzahl von Passwortversuchen wird über viele Konten verteilt. Dieser Leitfaden prüft die Konfiguration, die vorhersehbare Passwortentscheidungen reduziert, bevor solche Versuche eintreffen. Ein Befund zur Passwortrichtlinie wird nicht als Beleg für einen tatsächlich erfolgten Spraying-Angriff behandelt.

Die Ablauffalle

Microsofts Empfehlungen für Passwortrichtlinien raten bei reinen Cloudkonten von einem regelmäßigen Passwortablauf ab und empfehlen Passwörter, die nicht ablaufen. Dieselben Empfehlungen betonen einzigartige Passwörter, die MFA-Registrierung und den Identitätsschutz. Die Abschaffung eines planmäßigen Ablaufs gehört mit diesen Kontrollen zusammen; sie ist kein Grund, einen vermuteten Sicherheitsvorfall zu ignorieren.

Der kontraintuitive Befund lautet Passwortablauf aktiviert, nicht Passwortablauf deaktiviert. Prüfen Sie, warum eine altersabhängige Änderung vorgeschrieben ist, für welche Identitäten sie gilt und ob eine verbindliche Anforderung ihre Abschaffung verhindert. Halten Sie eine solche Ausnahme vom empfohlenen Cloudstandard getrennt. Kennzeichnen Sie eine dokumentierte geschäftliche Vorgabe nicht allein deshalb als behoben, weil die Standardempfehlung davon abweicht.

Standardwerte belegen nicht den Zustand Ihres Mandanten

Die Seite zur Entra-Passwortrichtlinie dokumentiert keinen Ablauf als derzeitigen Standard für das maximale Passwortalter, jedoch einen Standard von 90 Tagen für vor 2021 erstellte Mandanten. Sie beschreibt außerdem die individuelle Einstellung für Benutzer, deren Passwörter nie ablaufen sollen, separat. Das Alter des Mandanten und ein Benutzerflag ersetzen daher nicht das Auslesen der wirksamen Richtlinie.

Das Microsoft-365-Verfahren zum Passwortablauf gilt für reine Cloudbenutzer. Es schließt hybride Benutzer mit Kennworthashsynchronisierung, Pass-Through-Authentifizierung oder lokalem Verbund ausdrücklich aus. Ermitteln Sie bei einer hybriden Prüfung die für Passwörter zuständige Instanz, bevor Sie das Änderungsverfahren wählen.

Konfiguration vor Änderungen erfassen

1. Die Einstellungen des Passwortschutz-Portals dokumentieren

Öffnen Sie Entra ID > Authentication methods > Password protection. Dokumentieren Sie Enforce custom list, die Listeneinträge, Enable password protection on Windows Server Active Directory und den lokalen Mode. Dies sind getrennte Beobachtungen. Ein aktivierter Windows-Server-Schalter sagt nicht aus, ob die Agents eine Richtlinie erhalten haben oder ob alle vorgesehenen Domänencontroller abgedeckt sind.

Laut Microsofts Seite zum lokalen Betrieb akzeptiert Audit Passwörter, die die Prüfung nicht bestehen würden, und protokolliert das Ergebnis; Enforced lehnt unsichere Passwörter ab. Wird die Windows-Server-Option auf No gesetzt, endet die Validierung in den bereitgestellten DC-Agents. Diese Einstellungen betreffen AD DS; sie sind kein Schalter zum Abschalten der automatischen globalen Cloudliste.

2. Die Ausnahme vom Passwortablauf für Cloudbenutzer auslesen

Wenn Microsoft Graph PowerShell installiert und mit dem vorgesehenen Mandanten verbunden ist und Sie gemäß dem zitierten Verfahren mindestens als User Administrator arbeiten, verwenden Sie den folgenden Befehl. Er wurde unverändert aus Microsofts Verfahren zur Prüfung des Passwortablaufs übernommen:

Get-MgUser -All -Property UserPrincipalName, PasswordPolicies | Select-Object UserPrincipalName, @{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}

-All fordert alle Benutzer an; -Property ruft die im Ausdruck verwendeten Eigenschaften ausdrücklich ab. Lesen Sie das Ergebnis in der richtigen Richtung: PasswordNeverExpires=True bedeutet, dass das deaktivierende Flag vorhanden ist. False bedeutet, dass dieses Flag nicht gefunden wurde; allein daraus folgt kein endliches maximales Passwortalter der Domäne.

Ergänzen Sie diese Bestandsaufnahme durch Microsoft 365 admin center > Settings > Org Settings > Security and Privacy > Password expiration policy für die betreffende Cloudpopulation. Dokumentieren Sie den Domänenumfang und individuelle Ausnahmen. Das Verfahren warnt, dass bei neuen verwalteten Domänen oder aus einem Verbund konvertierten Domänen die Organisationsrichtlinie erneut angewendet werden muss, um alle Domänen zu aktualisieren. Microsoft Learn: Ablaufrichtlinie.

Hier wird keine Mandantenausgabe gezeigt: Der Befehl ist eine dokumentierte Messung und keine Behauptung, dass eine bestimmte Umgebung die Prüfung bestanden hat.

Erkennung: Lokale Durchsetzung überprüfen

Verwenden Sie den Admin-Kanal des DC-Agents unter Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin. Microsofts Monitoringreferenz unterscheidet diese Ergebnisse:

Ereignis 30019 ist eine Benachrichtigung zum Richtlinienzustand und kein Ergebnis, das bei jeder Passwortänderung oder Zurücksetzung ausgegeben wird. Es meldet, dass die empfangene Richtlinie die Verarbeitung deaktiviert hat: Nachfolgende Passwörter gelten ohne Validierung als konform, und bis zur nächsten Richtlinienänderung werden keine weiteren Ereignisse protokolliert.

Zusammengehörige Ereignispaare teilen eine CorrelationId. Prüfen Sie das Ereignis mit der Begründung zusammen mit dem Ergebnis und bewahren Sie die Identität des Controllers und den Zeitstempel auf. Zählen Sie das Paar nicht als zwei unabhängig abgelehnte Anfragen.

Für eine Zusammenfassung zu einem bestimmten Controller nennt Microsoft diesen Befehl auf einem Passwortschutz-Proxyserver:

Get-AzureADPasswordProtectionSummaryReport -DomainController bplrootdc2

Dies ist Microsofts beispielhafter Controllername und keine hier beobachtete Umgebung. Ersetzen Sie ihn durch den zu prüfenden Controller. Der Bericht liest die Admin-Protokolle der Agents über Remote PowerShell; fehlender Zugriff oder fehlende Agents begrenzen die Aussagekraft. Deuten Sie einen leeren Bericht nicht als erfolgreichen Durchsetzungstest.

Diese Ereignisse beschreiben die Passwortvalidierung und keine Anmeldeangriffe. Korrelieren Sie einen Vorfall separat anhand der Anmeldetelemetrie; eine Ablehnung durch die benutzerdefinierte Liste allein identifiziert nicht die Person, die einen Password-Spraying-Angriff versucht.

Behebung: Eigene Begriffe, AD-DS-Durchsetzung und Passwortablauf (Remediation)

1. Die benutzerdefinierte Liste aktivieren und validieren

Befolgen Sie das Tutorial zur benutzerdefinierten Liste mit mindestens der Rolle Authentication Policy Administrator und einer Entra-ID-P1- oder P2-Lizenz. Setzen Sie Enforce custom list auf Yes, geben Sie einen Begriff pro Zeile ein und speichern Sie. Begriffe müssen 4–16 Zeichen lang sein; die Liste unterstützt bis zu 1.000 Begriffe. Aktualisierungen können mehrere Stunden dauern.

Verwenden Sie ein Testkonto ohne Administratorrechte und beachten Sie die dokumentierten SSPR-Voraussetzungen. Testen Sie nach der Verteilung eine schwache Variante eines konfigurierten Begriffs. Dokumentieren Sie Annahme oder Ablehnung, ohne das Passwort aufzubewahren. Wird ein Test unerwartet akzeptiert, untersuchen Sie Durchsetzung, Verteilung und Bewertungsalgorithmus, bevor Sie die Liste als unwirksam einstufen.

2. Die lokale Bereitstellung vervollständigen

Befolgen Sie Microsofts Bereitstellungsleitfaden: Installieren und registrieren Sie den Proxydienst und die Gesamtstruktur, stellen Sie DC-Agents bereit und berücksichtigen Sie den zum Laden des Passwortfilters erforderlichen Neustart. Beschreibbare Domänencontroller sind die Validierungspunkte; RODCs leiten Passwortvorgänge weiter und benötigen keinen DC-Agent.

Audit ist der dokumentierte Anfangsmodus. Nutzen Sie diese Phase zum Testen von Passwortänderungsabläufen sowie der Herauf- und Herabstufung von Domänencontrollern. Wechseln Sie nach der Lösung betrieblicher Probleme zu Enforced. Bestätigen Sie, dass die Windows-Server-Option Yes lautet, und speichern Sie die Änderung gemäß dem Betriebsverfahren. Wiederholen Sie einen kontrollierten Test mit einem schwachen Passwort und prüfen Sie die korrelierten Ablehnungsereignisse.

Der Bereitstellungsleitfaden erklärt auch den Betrieb mit zwischengespeicherten Richtlinien bei nicht verfügbaren Proxys. Prüfen Sie neben dem Vorhandensein der Agents auch die Aktualität der Richtlinie: Ein laufender Dienst und ein Portal-Screenshot sind unterschiedliche Belege.

3. Regelmäßigen Cloud-Passwortablauf entfernen, wo dies anwendbar ist

Prüfen Sie für reine Cloudbenutzer die empfohlene Option für nie ablaufende Passwörter im Microsoft-365-Bereich zum Passwortablauf. Für die Ausnahme eines einzelnen Benutzers dokumentiert Microsoft diesen Befehl unter Ein Passwort so festlegen, dass es nie abläuft:

Update-MgUser -UserId <user ID> -PasswordPolicies DisablePasswordExpiration

Der Platzhalter wurde aus der Dokumentation übernommen; ersetzen Sie ihn durch die vorgesehene Benutzer-ID. Prüfen Sie vor einer gezielten Aktualisierung die bestehenden Werte der Passwortrichtlinie. Machen Sie aus dem Beispiel keine ungeprüfte mandantenweite Änderung und führen Sie anschließend die schreibgeschützte Bestandsaufnahme erneut aus.

Klären Sie bei hybriden Identitäten die AD-seitige Richtlinie und das Synchronisierungsmodell separat. Das Cloudverfahren bestätigt keine Änderung des lokalen maximalen Passwortalters. Behalten Sie Passwortänderungen bei einer Kompromittierung sowie die von Microsoft empfohlenen MFA- und Identitätsrisikokontrollen bei.

Wie EtcSec dies erkennt

Die für diesen Artikel geprüften Detektorimplementierungen von etc-collector bewerten drei Konfigurationssignale:

Nutzen Sie diese Befunde als Ausgangspunkt für die entsprechenden manuellen Prüfungen. Das Ausbleiben eines Befunds ersetzt nicht die oben beschriebenen Portalmessungen, die Graph-Bestandsaufnahme und die kontrollierte AD-DS-Validierung. Schließen Sie jede Behebung mit Belegen aus dem tatsächlich geschützten Passwortänderungspfad ab.