MFA, Passkeys und Self-Service Password Reset in Microsoft Entra ID verwalten

Wie lassen sich MFA, Passkeys und Self-Service Password Reset so einführen, dass Benutzer sicher anmelden und der Helpdesk bei Geräteverlust kontrolliert helfen kann? Zuerst wird in der Authentication Methods Policy festgelegt, welche Methoden für welche Gruppen zulässig sind. Danach werden Registrierung, Conditional Access, Self-Service Password Reset und Wiederherstellung als gemeinsamer Prozess gestaltet. Temporary Access Pass kann eine zeitlich begrenzte, starke Erst- oder Wiederregistrierung unterstützen.

„MFA aktiviert“ ist keine vollständige Beschreibung. Für den Betrieb muss bekannt sein, welche Methode als erster Faktor, als zusätzlicher Faktor oder für SSPR verwendet werden kann. Microsoft führt diese Fähigkeiten je Methode getrennt auf. Nicht jede Methode erfüllt jeden Zweck.

Authentifizierung und Autorisierung unterscheiden

Authentifizierung beantwortet: Wer meldet sich an und wie wird die Identität nachgewiesen?

Autorisierung beantwortet: Auf welche Ressource darf die Identität zugreifen?

MFA oder ein Passkey verleiht keine Berechtigung. Conditional Access kann starke Authentifizierung verlangen, während Rollen, Gruppen oder App-Zuweisungen den eigentlichen Zugriff bestimmen.

Authentication Methods Policy als Steuerungspunkt

Für neue und bereinigte Konfigurationen sollte die Authentication Methods Policy der führende Steuerungspunkt sein. Dort muss nachvollziehbar dokumentiert sein, welche Gruppen welche Methode für Anmeldung, MFA oder Wiederherstellung verwenden dürfen. Alte MFA- oder SSPR-Einzelkonfigurationen sollten nicht parallel als Schattenlogik weiterbetrieben werden.

Die Richtlinie für Authentifizierungsmethoden legt fest, welche Gruppen Methoden verwenden dürfen. Typische Methoden sind:

• Microsoft Authenticator,
• Passkeys/FIDO2-Sicherheitsschlüssel,
• Windows Hello for Business,
• Certificate-Based Authentication,
• Temporary Access Pass,
• SMS oder Telefonanruf,
• Software-OATH und weitere unterstützte Methoden.

Microsoft empfiehlt phishingresistente Methoden wie Windows Hello for Business, Passkeys/FIDO2 oder zertifikatbasierte Authentifizierung für hohe Sicherheit. Welche Methode praktisch geeignet ist, hängt von Geräten, Plattformen, Benutzergruppen und Wiederherstellungsprozess ab.

Passkeys und FIDO2 einordnen

Passkeys beziehungsweise FIDO2 lassen sich grundsätzlich bereits in allen Microsoft-Entra-Editionen nutzen. Wird jedoch über Conditional Access eine bestimmte Authentication Strength erzwungen, kommt dafür in der Regel mindestens Entra ID P1 ins Spiel.

Passkeys verwenden kryptografische Schlüsselpaare und sind gegen klassische Phishingangriffe widerstandsfähiger als Kennwort plus bestätigter Push. Microsoft Entra unterstützt verschiedene Passkey-/FIDO2-Szenarien, darunter Sicherheitsschlüssel und unterstützte Geräte- oder Authenticator-Varianten.

Vor einem Rollout ist zu prüfen:

• unterstützte Betriebssysteme und Browser,
• gemeinsam oder persönlich genutzte Geräte,
• mobile und Desktopanmeldung,
• Anzahl zulässiger Schlüssel pro Benutzer,
• Verlust- und Ersatzverfahren,
• Registrierung ohne bereits vorhandene starke Methode,
• Conditional-Access-Authentication-Strength.

Fehlerbild: Verwaister Passkey

Ein Passkey kann noch auf einem Gerät vorhanden sein, obwohl die Registrierung in Entra entfernt wurde. Der Benutzer sieht dann möglicherweise einen Eintrag, der nicht mehr funktioniert. Löschen Sie die veraltete Registrierung kontrolliert auf beiden Seiten und registrieren Sie neu.

Microsoft Authenticator

Authenticator kann Push-basierte MFA, kennwortlose Anmeldung oder Passkey-Funktionen unterstützen, abhängig von Konfiguration und Plattform. Number Matching und zusätzliche Kontextinformationen stärken die Push-Bestätigung, beseitigen aber nicht jedes Social-Engineering-Risiko.

Betrieblich relevant sind:

• Gerätewechsel,
• Backup- und Wiederherstellungsverhalten,
• mehrere Konten im Authenticator,
• Benutzer mit eingeschränktem Smartphonezugang,
• App-Schutz und Gerätesicherheit,
• Registrierung und Löschung alter Methoden.

Temporary Access Pass

Die TAP-Methode selbst wird ebenfalls über die Authentication Methods Policy gesteuert. Änderungen an dieser Policy benötigen eine passende Verwaltungsrolle wie Authentication Policy Administrator; das Ausstellen eines TAP für einen Benutzer gehört anschließend in einen eng gefassten Helpdesk- oder Authentifizierungsprozess mit dokumentierter Identitätsprüfung.

Temporary Access Pass, kurz TAP, ist ein zeitlich begrenzter Passcode, den berechtigte Administratoren für einen Benutzer ausstellen können. Er kann die Anmeldung und Registrierung starker Methoden unterstützen, ohne dem Benutzer ein dauerhaftes Ersatzkennwort mitzuteilen.

Ein TAP-Prozess benötigt:

• berechtigte Helpdesk- oder Authentifizierungsrolle,
• verlässliche Identitätsprüfung,
• kurze, angemessene Gültigkeit,
• Entscheidung über einmalige oder mehrfache Verwendung,
• sichere Übermittlung,
• Protokollierung,
• anschließende Kontrolle der registrierten Methode.

Ein TAP ist kein universeller Kennwortersatz. Microsoft dokumentiert Einschränkungen, etwa bei bestimmten Kennwortänderungsszenarien.

Self-Service Password Reset

SSPR ermöglicht berechtigten Benutzern, Kennwörter selbst zurückzusetzen, wenn die konfigurierten Verifikationsanforderungen erfüllt werden. In hybriden Umgebungen können zusätzliche Voraussetzungen für Password Writeback gelten.

Zu planen sind:

• Zielgruppen,
• erforderliche Anzahl von Methoden,
• erlaubte Methoden,
• Registrierung und regelmäßige Überprüfung,
• Helpdeskverfahren bei fehlenden Methoden,
• hybride Abhängigkeiten,
• Benachrichtigungen bei Zurücksetzung.

SSPR reduziert Supportaufwand nur, wenn Benutzer registriert sind und die Methoden noch besitzen. Deshalb ist der Registrierungsprozess wichtiger als die bloße Aktivierung der Funktion.

Kombinierte Registrierung

Microsoft Entra bietet eine gemeinsame Benutzeroberfläche für MFA- und SSPR-Sicherheitsinformationen. Die verfügbaren Methoden werden durch die Authentication Methods Policy und die jeweiligen Funktionen bestimmt.

Ein Rollout umfasst:

1. Pilotgruppe,
2. klare Benutzeranleitung,
3. abgesicherten Registrierungsort oder Conditional-Access-Regel,
4. Helpdeskvorbereitung,
5. Auswertung fehlgeschlagener Registrierungen,
6. schrittweise Erweiterung.

Microsoft dokumentiert besondere Anforderungen beim Hinzufügen oder Ändern von Passkeys, einschließlich aktueller starker Authentifizierung. Registrierungs-Sessions können zeitlich begrenzt sein.

Sichere Erstregistrierung neuer Benutzer

Ein neues Konto besitzt noch keine starke Methode. Mögliche Vorgehensweise:

1. HR- oder Onboardingprozess bestätigt die Identität.
2. Administrator erstellt einen kurz gültigen TAP.
3. TAP wird über einen getrennten, autorisierten Kanal übermittelt.
4. Benutzer meldet sich an und registriert Passkey, Authenticator oder andere vorgesehene Methode.
5. Benutzer bestätigt erfolgreiche Anmeldung.
6. Helpdesk prüft, dass keine unerwarteten Methoden registriert wurden.
7. TAP läuft ab oder wird entfernt.

Ein Initialkennwort per unverschlüsselter E-Mail ist kein gleichwertiger Prozess.

Benutzer ohne Smartphone

Nicht jeder Benutzer kann oder darf ein persönliches Smartphone verwenden. Alternativen können sein:

• FIDO2-Sicherheitsschlüssel,
• Windows Hello for Business auf verwaltetem Gerät,
• zertifikatbasierte Authentifizierung,
• andere unterstützte Hardware- oder Unternehmenslösungen.

Die Auswahl muss zu Arbeitsplatz, Geräten, Barrierefreiheit und Support passen. Eine reine SMS-Ausnahme sollte nicht automatisch die Dauerlösung werden.

Geräteverlust oder Smartphone-Wechsel

Standardprozess

1. Benutzer meldet Verlust über autorisierten Kanal.
2. Helpdesk prüft Identität nach festgelegtem Verfahren.
3. bestehende Sitzungen werden bei Risiko widerrufen.
4. verlorene Authentifizierungsmethode wird entfernt.
5. temporärer Zugang wird kontrolliert bereitgestellt.
6. neue starke Methode wird registriert.
7. Anmeldung wird getestet.
8. Vorgang und verwendete Adminidentität werden dokumentiert.

Identitätsprüfung

Der Helpdesk darf sich nicht allein auf Informationen verlassen, die ein Angreifer leicht kennt. Geeignete Verfahren können interne Rückrufe, bestätigte Managerkontakte, persönliche Prüfung oder bestehende Unternehmensprozesse kombinieren. Die konkrete Methode muss zur Risikoklasse passen und datenschutzkonform sein.

Rollen für den Helpdesk

Nicht jeder Helpdesk-Mitarbeiter benötigt Privileged Authentication Administrator. Microsoft unterscheidet Rollen für normale und privilegierte Benutzer. Das Rollenmodell für Microsoft-Entra-Administratorrollen sollte prüfen:

• welche Benutzergruppen unterstützt werden,
• ob administrative Konten ausgeschlossen sind,
• ob Administrative Units den Scope begrenzen können,
• ob PIM-Aktivierung erforderlich ist,
• welche Aktionen im Audit erscheinen.

Conditional Access und Authentication Strength

Authentication Strengths sind ein Conditional-Access-Mechanismus und damit kein eigenständiger Ersatz für die Methodensteuerung. Wer phishingresistente Anmeldungen erzwingen will, muss also sowohl die zulässigen Methoden als auch die dafür nötige CA-Lizenzierung zusammen betrachten.

Conditional Access kann MFA oder eine definierte Authentication Strength verlangen. Dadurch lässt sich für privilegierte Zugriffe eine phishingresistente Methode fordern, während andere Szenarien anders behandelt werden.

Vor Aktivierung:

• prüfen, ob alle Zielnutzer eine kompatible Methode besitzen,
• Registrierung und Wiederherstellung testen,
• Emergency-Access-Konten ausrichten,
• Report-only und Pilot verwenden,
• alte Clients und Protokolle untersuchen.

Typische Fehlerbilder

Benutzer erhält keine angebotene Methode

Mögliche Ursachen:

• nicht in Zielgruppe der Authentication Methods Policy,
• Methode ist für den Zweck nicht unterstützt,
• Conditional Access blockiert Registrierung,
• Plattform oder Browser unterstützt den Vorgang nicht,
• Benutzer besitzt bereits maximale oder konfliktbehaftete Registrierung.

SSPR funktioniert trotz registrierter MFA nicht

MFA- und SSPR-Eignung einer Methode sind nicht identisch. Prüfen Sie die aktuelle Methodentabelle, SSPR-Zielgruppe, Anzahl erforderlicher Methoden und hybride Writeback-Abhängigkeiten.

Neues Smartphone, kein Zugriff auf altes Gerät

Nutzen Sie den dokumentierten Recovery-Prozess. Entfernen Sie alte Methoden erst nach Identitätsprüfung. Stellen Sie TAP oder alternative starke Registrierung bereit. Deaktivieren Sie nicht pauschal MFA für die gesamte Benutzergruppe.

MFA-Push wird mehrfach angefordert

Prüfen Sie Anmeldeprotokoll, Conditional-Access-Richtlinien, Session Controls, Clienttoken und verdächtige Anmeldeversuche. Bei möglichem Angriff Sitzungen widerrufen und Credentials beziehungsweise Methoden neu bewerten.

Passkey funktioniert in einer App, aber nicht in einer anderen

Unterstützung kann von Plattform, Browser, nativer App und Authentifizierungsfluss abhängen. Testen Sie die reale Anwendungsmatrix statt nur das My-Account-Portal.

Rückfallwege

• zweiter registrierter starker Faktor,
• FIDO2-Ersatzschlüssel,
• zeitlich begrenzter TAP nach Identitätsprüfung,
• Helpdesk-Reset der Methode mit passender Rolle,
• Emergency-Access-Verfahren für Administratoren,
• begrenzte Pilot-Ausnahme bei einem nachgewiesenen Clientproblem.

Jeder Rückfall muss zeitlich begrenzt und nach erfolgreicher Wiederherstellung geschlossen werden.

Testkatalog

1. neue Benutzerregistrierung mit TAP,
2. Anmeldung mit Passkey,
3. Anmeldung mit Authenticator,
4. SSPR mit den vorgesehenen Methoden,
5. Smartphonewechsel,
6. verlorener Sicherheitsschlüssel,
7. Benutzer ohne Smartphone,
8. privilegierter Administrator mit stärkerer Anforderung,
9. Registrierung aus nicht vertrauenswürdigem Netzwerk,
10. Helpdesk-Reset mit eingeschränkter Rolle,
11. gesperrtes oder deaktiviertes Konto,
12. Sitzung widerrufen und erneute Anmeldung.

Betriebskennzahlen

• Anteil registrierter Zielbenutzer,
• Anteil phishingresistenter Methoden,
• Anzahl Recovery-Fälle,
• TAP-Ausstellungen und Gültigkeitsdauer,
• fehlgeschlagene Registrierungen,
• alte oder doppelte Methoden,
• Benutzer ohne Rückfallmethode,
• Helpdesk-Eingriffe bei privilegierten Konten.

Wenn starke Anmeldemethoden produktiv erzwungen werden sollen, baut der nächste Schritt meist auf Conditional Access in Microsoft Entra ID auf. Für Administratoren bleibt zusätzlich der Beitrag Notfallzugang für Microsoft 365 relevant.

So bleibt starke Authentifizierung auch im Supportfall beherrschbar

Starke Authentifizierung funktioniert im Alltag nur mit einem ebenso starken Registrierungs- und Wiederherstellungsprozess. Methodengruppen, Passkeys, TAP, SSPR, Helpdesk-Rollen und Conditional Access müssen zusammen geplant werden. Damit bleibt die Organisation auch bei neuem Gerät, verlorenem Schlüssel oder fehlender Erstregistrierung handlungsfähig, ohne Sicherheitsanforderungen pauschal abzuschalten.