Entra SSPR Sicherheitslücken: nicht aktiviert, nicht für Admins erforderlich, schwache Reset-Methoden

Entra Self Service Password Reset SSPR Sicherheitslücken: Was Sie Sind

Self-Service Password Reset (SSPR) in Microsoft Entra ID soll die Konto-Wiederherstellungslücke schließen, die die Multi-Faktor-Authentifizierung an anderer Stelle im Tenant öffnet. In der Praxis tauchen in echten Tenants immer wieder dieselben drei Entra Self-Service Password Reset SSPR Sicherheitslücken auf: SSPR tenant-weit deaktiviert, Administratoren von einer Richtlinie ausgenommen, die eigentlich eine starke Verifizierung erfordert, und schwache Reset-Methoden wie Sicherheitsfragen oder SMS, die allein als ausreichender Identitätsnachweis akzeptiert werden.

SSPR ermöglicht es Benutzern, den Zugriff auf ein gesperrtes Konto wiederzuerlangen, ohne ein Helpdesk-Ticket zu eröffnen, indem sie ihre Identität über eine oder mehrere registrierte Methoden (Authenticator-App, E-Mail, Telefon oder Sicherheitsfragen) unter passwordreset.microsoftonline.com verifizieren. Die Aktivierung erfordert mindestens eine Microsoft Entra ID P1-Lizenz und die Rolle Authentication Policy Administrator, und der Geltungsbereich kann auf None, eine einzelne (optional verschachtelte) Gruppe oder All-Benutzer festgelegt werden, gemäß Microsofts Aktivierungs-Tutorial.

Die meisten Rollouts enden dort, rein als Kosteneinsparung gerahmt — weniger Helpdesk-Anrufe, schnellerer Reset für Endbenutzer, eine Zeile auf einer Lizenz-Tabelle. Genau dieser Rahmen ist es, wie die folgenden drei Lücken unbemerkt überleben:

• SSPR vollständig deaktiviert (SSPR_NOT_ENABLED) — es existiert kein Self-Service-Pfad, sodass jeder Reset über einen Menschen läuft.
• Administratoren nicht durch eine Reset-Richtlinie abgedeckt, die tatsächlich eine starke Verifizierung erfordert (SSPR_NOT_REQUIRED_ADMINS) — privilegierte Konten fallen auf denselben manuellen, social-engineering-anfälligen Pfad zurück.
• Schwache Methoden als ausreichender Identitätsnachweis akzeptiert (SSPR_METHODS_WEAK) — Sicherheitsfragen oder SMS-/Sprachanrufe erfüllen die Reset-Richtlinie allein.

Keine dieser Lücken ist eine exotische Fehlkonfiguration. Es sind default-nahe Zustände, in die ein Tenant einfach dadurch abdriftet, dass SSPR nach der Erstkonfiguration nie wieder überprüft wird — was auch erklärt, warum sie bei einer routinemäßigen Überprüfung selten entdeckt werden: Ein Penetrationstest oder MFA-Audit prüft typischerweise, ob die Anmeldung einen zweiten Faktor erfordert, nicht ob der Wiederherstellungspfad für dasselbe Konto genauso stark ist. Ein Angreifer muss MFA nicht an der Vordertür schlagen, wenn die Hintertür — die Passwort-Wiederherstellung — nur eine erratene Sicherheitsfrage oder einen überzeugenden Telefonanruf benötigt.

Die Drei SSPR Sicherheitslücken, Eine Nach der Anderen

Lücke 1 — SSPR Vollständig Deaktiviert

Wenn der SSPR-Geltungsbereich None ist, muss jeder Passwort-Reset über die IT oder den Helpdesk laufen. Dieser manuelle Pfad ist genau der Vektor, der in CISAs Scattered-Spider-Advisory (AA23-320A) beschrieben wird: Bedrohungsakteure rufen Helpdesk-Mitarbeiter an oder schreiben ihnen SMS, geben sich als Mitarbeiter aus und fordern einen Passwort-Reset oder einen MFA-Geräte-Wechsel als initialen Zugriffsvektor an. Ein Tenant mit deaktiviertem SSPR hat den Reset-Pfad nicht entfernt — er hat 100 % der Resets genau in den Kanal gezwungen, auf den diese Technik abzielt, und dem Helpdesk keine Self-Service-Baseline gegeben, mit der eine ungewöhnliche Anfrage verglichen werden könnte.

Lücke 2 — Admins Müssen SSPR Nicht Verwenden

Standardmäßig behandelt Microsoft Entra Administratorkonten anders: Sie sind durch eine integrierte, nicht änderbare Zwei-Gate-Richtlinie abgedeckt, die zwei Authentifizierungsdaten erfordert, getrennt von der (oft Ein-Gate-)Richtlinie, die für reguläre Benutzer gilt, gemäß Microsofts SSPR-Richtliniendokumentation. Tenants, die die Admin-Passwort-Reset-Richtlinie deaktivieren — ohne Admins explizit von der benutzerorientierten Richtlinie auszuschließen — lassen privilegierte Konten auf demselben Weg zurücksetzen wie in Lücke 1: manuell, über den Helpdesk. Dies ist das Konto mit dem höchsten Schutzwert vor diesem Pfad, denn ein erfolgreich social-engineerter Reset bei einem Global Administrator ist eine vollständige Tenant-Kompromittierung, nicht nur ein einzelnes Postfach.

Lücke 3 — Schwache Reset-Methoden Akzeptiert

Sicherheitsfragen können von jedem beantwortet werden, der eine leichte Recherche über ein Ziel durchgeführt hat, und Microsoft zieht sie genau aus diesem Grund bis März 2027 vollständig aus SSPR zurück — Microsofts eigene Dokumentation markiert sie als „weniger sicher als andere Methoden" und empfiehlt, sie mit einer zweiten Methode zu kombinieren, falls sie überhaupt verwendet werden. Mobiltelefon-Methoden (SMS/Sprachanruf) bringen ihr eigenes bekanntes Interception- und SIM-Swap-Risiko mit sich — NISTs Digital-Identity-Richtlinien stufen über das Telefonnetz zugestellte Codes genau aus diesem Grund als eingeschränkten Authentifikator ein und weisen Prüfer an, vor der Nutzung auf SIM-Wechsel und Rufnummernportierung zu prüfen, gemäß NIST SP 800-63B. Eine Reset-Richtlinie, die eine dieser beiden Methoden als einzelnes erfüllendes Gate akzeptiert, ist funktional genauso schwach wie gar keine Richtlinie — das Konto ist nur eine erratene Antwort oder einen abgefangenen Text von der Übernahme entfernt.

Erkennung

Wenn Sie eine umfassendere Entra ID-Sicherheitsüberprüfung durchführen, gehört die SSPR-Haltung in denselben Durchgang wie Conditional Access und PIM — sie wird mit denselben Graph-Berechtigungen und derselben Admin-Center-Sitzung geprüft.

Registrierungsabdeckung Direkt Abfragen

Connect-MgGraph -Scopes "Reports.Read.All", "Policy.Read.All"

# Admin SSPR-Haltung
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy" |
  Select-Object -ExpandProperty allowedToUseSSPR

# Benutzer, die für SSPR aktiviert, aber nicht tatsächlich registriert sind
Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
  -Filter "isSsprEnabled eq true and isSsprRegistered eq false" |
  Select-Object UserPrincipalName, IsAdmin, IsSsprRegistered, MethodsRegistered

Jeder, den diese zweite Abfrage zurückgibt, kann auf dem Papier für SSPR aktiviert sein, ohne tatsächlich eine konforme Methode registriert zu haben — was bedeutet, dass sein echter Reset-Pfad heute immer noch der Helpdesk ist. Gleichen Sie die Spalte IsAdmin zuerst mit Ihrer Liste privilegierter Rollen ab; ein Directory- oder Global-Administrator-Konto in dieser Ausgabe ist Lücke 2 und Lücke 3, die auf derselben Identität übereinandergestapelt sind — die Kombination, die vor allem anderen auf dieser Liste priorisiert werden sollte.

Behebung

Lücke 1 Schließen — SSPR Tenant-Weit Aktivieren

Setzen Sie im Entra Admin Center unter Protection → Password reset → Properties den Geltungsbereich auf All statt None oder eine einzelne Pilotgruppe. Dies erfordert die Rolle Authentication Policy Administrator und eine Entra ID P1+-Lizenz, gemäß Microsofts Tutorial.

Lücke 2 Schließen — Admin-Konten Unter Eine Echte Reset-Richtlinie Bringen

Bestätigen Sie, dass allowedToUseSSPR in authorizationPolicy eine bewusste Entscheidung widerspiegelt und dass privilegierte Rollen durch Entras integrierte Zwei-Gate-Admin-Richtlinie abgedeckt sind, statt stillschweigend ausgeschlossen zu werden, gemäß Microsofts SSPR-Richtliniendokumentation. Kombinieren Sie dies für Ihre sensibelsten Rollen (Global Administrator und gleichwertige) mit phishing-resistenten Methoden und eng überwachten Break-Glass-Notfallzugangskonten, die von Conditional Access ausgeschlossen sind, sodass die Wiederherstellung niemals allein von SSPR oder einem Helpdesk-Anruf abhängt. Gleichen Sie bestehende Zuweisungen mit Ihrer Überprüfung des privilegierten Zugriffs ab — ein Konto, das von vornherein kein dauerhafter Admin sein sollte, braucht diese Lösung überhaupt nicht.

Lücke 3 Schließen — Zwei Methoden Erfordern und Die Schwachen Streichen

Stellen Sie die Reset-Richtlinie so ein, dass mindestens zwei Gates erforderlich sind, und entfernen Sie Sicherheitsfragen als eigenständige Option — Microsoft zieht sie ohnehin bis März 2027 aus SSPR zurück, gemäß der Dokumentation. Bevorzugen Sie die Authenticator-App oder Passkey-Registrierung gegenüber SMS/Sprachanruf.

Dann Den Kreis Bei Registrierung Und Überwachung Schließen

Aktivieren Sie die Registrierungskampagne für Authentifizierungsmethoden, damit Benutzer konforme Methoden registriert haben, bevor sie jemals ein Passwort zurücksetzen müssen — dies schließt AUTH_METHODS_NO_REGISTRATION zusammen mit den anderen drei Lücken. Falls Ihr Tenant auch die SSPR-Durchsetzung nur registrierter Methoden ab November 2026 bearbeitet, treibt derselbe Registrierungsbericht beide Korrekturen an — diese Änderung akzeptiert keine unregistrierte Verzeichnis-Telefonnummer/E-Mail mehr als Fallback, was nur relevant ist, wenn die Registrierungsabdeckung überhaupt erst nachverfolgt wird.

Überwachen Sie schließlich die zwei wichtigsten Audit-Aktivitäten — Self-service password reset policy changes und Reset password (by admin) —, damit eine zukünftige Schwächung von Umfang, Methodenanzahl oder zulässigen Methoden sofort auffällt, statt diese Lücken stillschweigend wieder zu öffnen. Ein Anstieg der von Admins durchgeführten Resets für dieselbe Handvoll Benutzer ist meist das erste sichtbare Zeichen dafür, dass SSPR für sie stillschweigend aufgehört hat zu funktionieren — lange bevor jemand ein Ticket dazu einreicht.

Wie EtcSec Dies Erkennt

EtcSecs Entra ID-Audit prüft SSPR_NOT_ENABLED (SSPR auf None beschränkt), SSPR_NOT_REQUIRED_ADMINS (Administratoren nicht durch eine konforme Reset-Richtlinie abgedeckt) und SSPR_METHODS_WEAK (Sicherheitsfragen oder Mobiltelefon allein erfüllen die Richtlinie), zusammen mit AUTH_METHODS_SMS_ENABLED und AUTH_METHODS_NO_REGISTRATION für die umgebende Authentifizierungsmethoden-Haltung. Zusammen ergeben diese fünf Prüfungen eine einzige Sicht darauf, ob der Konto-Wiederherstellungspfad tatsächlich so stark ist wie der Anmeldepfad, den er absichern soll — denn ein Tenant, der jede Anmeldung mit Conditional Access und MFA gehärtet, aber die Passwort-Wiederherstellung auf einer Standard-SSPR-Konfiguration belassen hat, hat gerade eine starke Vordertür neben einem unverschlossenen Seiteneingang gebaut.