Ausführliche technische Informationen zur zertifikatbasierten Authentifizierung mit Microsoft Entra

In diesem Artikel wird erläutert, wie die zertifikatbasierte Authentifizierung (Certificate-Based Authentification, CBA) mit Microsoft Entra funktioniert. Außerdem wird auf technische Details zu Microsoft Entra-CBA-Konfigurationen eingegangen.

Wie funktioniert zertifikatbasierte Authentifizierung mit Microsoft Entra?

Die folgende Abbildung beschreibt, was geschieht, wenn ein Benutzer versucht, sich bei einer Anwendung auf einem Mandanten anzumelden, auf dem die zertifikatbasierte Authentifizierung mit Microsoft Entra aktiviert ist.

Jetzt gehen wir die einzelnen Schritte durch:

1. Der Benutzer versucht, auf eine Anwendung zuzugreifen – beispielsweise auf das MyApps-Portal.

2. Wenn der Benutzer nicht bereits angemeldet ist, wird er zur Microsoft Entra ID-Seite Benutzeranmeldung unter https://login.microsoftonline.com/ umgeleitet.

3. Auf der Microsoft Entra-Anmeldeseite gibt der Benutzer seinen Benutzernamen ein und wählen Sie anschließend Weiter. Microsoft Entra ID führt die Startbereichsermittlung mithilfe des Mandantennamens aus, und der Benutzername wird verwendet, um den Benutzer im Mandanten nachzuschlagen.

   

4. Von Microsoft Entra ID wird überprüft, ob die zertifikatbasierte Authentifizierung für den Mandanten aktiviert ist. Ist die zertifikatbasierte Authentifizierung aktiviert, wird dem Benutzer auf der Kennwortseite ein Link Zertifikat oder Smartcard verwenden angezeigt. Wird der Anmeldelink dem Benutzer nicht angezeigt, vergewissern Sie sich, dass die zertifikatbasierte Authentifizierung für den Mandanten aktiviert ist. Weitere Informationen finden Sie unter Wie aktiviere ich die Microsoft Entra-CBA?.

   Hinweis

   Wenn CBA auf dem Mandanten aktiviert ist, wird allen Benutzern auf der Kennwortseite der Link Zertifikat oder Smartcard verwenden angezeigt. Allerdings können sich nur Benutzer, die sich im Gültigkeitsbereich für CBA befinden, erfolgreich bei einer Anwendung authentifizieren, die Microsoft Entra ID als Identitätsanbieter (Identity Provider, IdP) verwendet.

   

   Wenn Sie andere Authentifizierungsmethoden wie etwa die Anmeldung per Telefon oder Sicherheitsschlüssel aktiviert haben, wird Benutzern möglicherweise ein anderer Anmeldebildschirm angezeigt.

   

5. Sobald der Benutzer die zertifikatbasierte Authentifizierung ausgewählt hat, wird der Client an den certauth-Endpunkt umgeleitet https://certauth.login.microsoftonline.com für öffentliche Entra ID. Für Azure Government ist lautet der certauth-Endpunkt https://certauth.login.microsoftonline.us.

   Der Endpunkt führt eine gegenseitige TLS-Authentifizierung durch und fordert im Rahmen des TLS-Handshakes das Clientzertifikat an. Ein Eintrag für diese Anforderung wird im Anmeldeprotokoll angezeigt.

   Hinweis

   Der Netzwerkadministrator oder die Netzwerkadministratorin sollte den Zugriff auf die Benutzeranmeldeseite und den certauth-Endpunkt *.certauth.login.microsoftonline.com für die Cloudumgebung des Kunden zulassen. Deaktivieren Sie die TLS-Überprüfung für den certauth-Endpunkt, um sicherzustellen, dass die Clientzertifikatanforderung im Rahmen des TLS-Handshakes erfolgreich ist.

   Stellen Sie sicher, dass ihre TLS-Überprüfungsaktivierung auch für die neue URL mit Ausstellerhinweisen funktioniert. Codieren Sie die URL nicht mit „tenantId“, da sie sich möglicherweise für B2B-Benutzer*innen ändert. Verwenden Sie einen regulären Ausdruck, damit sowohl die alte als auch die neue URL für die Deaktivierung der TLS-Überprüfung funktioniert. Verwenden Sie z. B. je nach Proxy *.certauth.login.microsoftonline.com oder *certauth.login.microsoftonline.com. Verwenden Sie in Azure Government *.certauth.login.microsoftonline.us oder *certauth.login.microsoftonline.us.

   Sofern der Zugriff nicht zulässig ist, schlägt die zertifikatbasierte Authentifizierung fehl, wenn Sie das anstehende Feature für vertrauenswürdige Zertifizierungsstellen aktivieren.

6. Microsoft Entra ID fordert ein Clientzertifikat an. Der Benutzer wählt das Clientzertifikat aus und wählt dann OK.

   Hinweis

   Hinweise zu vertrauenswürdigen Zertifizierungsstellen werden nicht unterstützt. Daher kann die Liste der Zertifikate nicht weiter eingegrenzt werden kann. Wir prüfen, ob wir diese Funktion in Zukunft hinzufügen können.

   

7. Microsoft Entra ID überprüft die Zertifikatsperrliste, um sicherzustellen, dass das Zertifikat gültig ist und nicht widerrufen wurde. Microsoft Entra ID identifiziert den Benutzer anhand der im Mandanten konfigurierten Benutzernamenbindung, um den Wert des Zertifikatfelds dem Wert des Benutzerattributs zuzuordnen.

8. Wenn ein eindeutiger Benutzer mit einer Richtlinie für bedingten Zugriff gefunden wird, die eine Multi-Faktor-Authentifizierung erfordert, und die Bindungsregel für die Zertifikatauthentifizierung die MFA-Kriterien erfüllt, wird der Benutzer von Microsoft Entra ID sofort angemeldet. Wenn MFA erforderlich ist, das Zertifikat aber nur einen einzelnen Faktor erfüllt, werden entweder die kennwortlose Anmeldung oder FIDO2 als zweiter Faktor angeboten, wenn sie bereits registriert sind.

9. Microsoft Entra ID gibt ein primäres Aktualisierungstoken zurück, um eine erfolgreiche Anmeldung zu signalisieren und den Anmeldeprozess abzuschließen.

10. Wenn die Anmeldung erfolgreich ist, kann der Benutzer auf die Anwendung zugreifen.

Zertifikatbasierte Authentifizierung ist MFA-fähig

Microsoft Entra-CBA kann eine Multi-Faktor-Authentifizierung (MFA) verwenden. Microsoft Entra-CBA kenn entweder Einzelfaktor (Single-Factor, SF) oder Multi-Faktor (MF) sein, abhängig von der Mandantenkonfiguration. Durch Aktivieren von CBA kann ein Benutzer die MFA möglicherweise abschließen. Ein Benutzer benötigt möglicherweise mehr Konfiguration, um die MFA zu vervollständigen, und einen Nachweis, um andere Authentifizierungsmethoden zu registrieren, wenn der Benutzer für CBA in Frage kommt.

Wenn der CBA-aktivierte Benutzer nur über ein Einzelfaktor (Single Factor, SF)-Zertifikat verfügt und MFA abschließen muss:

1. Verwenden Sie ein Kennwort und ein SF-Zertifikat.
2. Geben Sie einen befristeten Zugriffspass aus.
3. Der Authentifizierungsrichtlinienadministrator fügt eine Telefonnummer hinzu und lässt die Sprach-/SMS-Authentifizierung für das Benutzerkonto zu.

Wenn dem CBA-aktivierten Benutzer noch kein Zertifikat ausgestellt wurde und er MFA vervollständigen muss:

1. Geben Sie einen befristeten Zugriffspass aus.
2. Der Authentifizierungsrichtlinienadministrator fügt eine Telefonnummer hinzu und lässt die Sprach-/SMS-Authentifizierung für das Benutzerkonto zu.

Wenn der CBA-aktivierte Benutzer kein MF-Zertifikat verwenden kann, z. B. auf mobilen Geräten ohne Smartcard-Unterstützung, und er MFA vervollständigen muss:

1. Geben Sie einen befristeten Zugriffspass aus.
2. Der Benutzer muss eine andere MFA-Methode registrieren (wenn er ein MF-Zertifikat verwenden kann).
3. Verwenden Sie Kennwort und MF-Zertifikat (wenn der Benutzer ein MF-Zertifikat verwenden kann).
4. Der Authentifizierungsrichtlinienadministrator fügt eine Telefonnummer hinzu und lässt die Sprach-/SMS-Authentifizierung für das Benutzerkonto zu.

MFA mit zertifikatbasierter Single-Faktor-Authentifizierung (Vorschau)

Die Microsoft Entra-CBA kann als ein zweiter Faktor verwendet werden, um bei Ein-Faktor-Zertifikaten MFA-Anforderungen zu erfüllen. Einige der unterstützten Kombinationen sind:

1. CBA (erster Faktor) und kennwortlose Telefonanmeldung (kennwortlose Telefonanmeldung als zweiter Faktor)
2. CBA (erster Faktor) und FIDO2-Sicherheitsschlüssel (zweiter Faktor)
3. Kennwort (erster Faktor) und CBA (zweiter Faktor)

Benutzer benötigen zuvor eine andere Möglichkeit für die Multi-Faktor-Authentifizierung (MFA) und zum Registrieren der kennwortlosen Anmeldung oder von FIDO2, um sich mit der zertifikatbasierten Authentifizierung von Microsoft Entra anzumelden.

Wichtig

Ein Benutzer gilt als MFA-fähig, wenn er in den Einstellungen der CBA-Methode enthalten ist. Dies bedeutet, dass der Benutzer den Nachweis nicht im Rahmen seiner Authentifizierung verwenden kann, um andere verfügbare Methoden zu registrieren. Stellen Sie sicher, dass Benutzer ohne gültiges Zertifikat nicht in den Einstellungen der CBA-Methode enthalten sind. Weitere Informationen zur Funktionsweise der Authentifizierung finden Sie unter Multi-Faktor-Authentifizierung in Microsoft Entra.

Schritte zum Einrichten der kennwortlosen Anmeldung per Telefon (PSI) mit CBA

Damit die kennwortlose Anmeldung funktioniert, sollten Benutzer Legacy-Benachrichtigungen über eine mobile App deaktivieren.

1. Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Authentifizierungsrichtlinienadministrator an.

2. Führen Sie die Schritte unter Aktivieren der Authentifizierung durch kennwortlose Anmeldung per Telefon aus.

   Wichtig

   Stellen Sie in der vorherigen Konfiguration sicher, dass Sie die Option Kennwortlos ausgewählt haben. Sie müssen den Authentifizierungsmodus für alle Gruppen ändern, die für PSI Kennwortloshinzugefügt wurden. Wenn Sie Beliebig auswählen, funktionieren CBA und PSI nicht.

3. Klicken Sie auf Schutz>Multi-Faktor-Authentifizierung>Zusätzliche Einstellungen für die cloudbasierte Multi-Faktor-Authentifizierung.

   

4. Deaktivieren Sie unter Überprüfungsoptionen die Option Benachrichtigung über mobile App, und wählen Sie Speichern aus.

   

MFA-Authentifizierungsflow mit Einzelfaktor-Zertifikaten und kennwortloser Anmeldung

Schauen wir uns ein Beispiel für einen Benutzer an, der über Einzelfaktor-Zertifikate verfügt und eine kennwortlose Anmeldung konfiguriert hat.

1. Geben Sie Ihren Benutzerprinzipalnamen (User Principal Name, UPN) ein, und wählen SIe Weiter.

   

2. Klicken Sie auf Mit Zertifikat anmelden.

   

   Wenn Sie andere Authentifizierungsmethoden wie etwa die Anmeldung per Telefon oder FIDO2-Sicherheitsschlüssel aktiviert haben, wird Benutzern möglicherweise ein anderer Anmeldebildschirm angezeigt.

   

3. Wählen Sie in der Clientzertifikatauswahl das richtige Benutzerzertifikat aus, und wählen Sie OK.

   

4. Da das Zertifikat für eine Einzelfaktor-Authentifizierungsstärke konfiguriert ist, benötigt der Benutzer einen zweiten Faktor, um die MFA-Anforderungen zu erfüllen. Der Benutzer sieht die verfügbaren zweiten Faktoren, in diesem Fall die kennwortlose Anmeldung. Wählen Sie Eine Anforderung in meiner Microsoft Authenticator-App bestätigen aus.

   

5. Sie erhalten eine Benachrichtigung auf Ihrem Smartphone. Wählen Sie Anmelden genehmigen? aus.

6. Geben Sie die Nummer, die im Browser oder App-Bildschirm angezeigt wird, in Microsoft Authenticator ein.

   

7. Wählen Sie Ja aus, und der Benutzer kann sich authentifizieren und anmelden.

Grundlegendes zur Authentifizierungsbindungsrichtlinie

Die Authentifizierungsbindungsrichtlinie hilft dabei, die Stärke der Authentifizierung entweder auf einen einzelnen Faktor (einstufig) oder auf mehrere Faktoren (mehrstufig) festzulegen. Ein Administrator kann den Standardwert von einem einzelnen Faktor in mehrere Faktoren ändern oder benutzerdefinierte Richtlinienregeln einrichten (entweder durch Verwendung der Felder Antragsteller des Ausstellers oder Richtlinien-OID oder Aussteller im Zertifikat).

Zertifikatstärken

Ein Administrator kann bestimmen, ob die Stärke der Zertifikate einstufig oder mehrstufig ist. Weitere Informationen finden Sie in der Dokumentation, die die NIST-Authentifizierungssicherheitsstufen den Microsoft Entra-Authentifizierungsmethoden zuordnet, was auf NIST 800-63B SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Mgmt aufbaut.

Mehrstufige Zertifikatauthentifizierung

Benutzer, die über mehrstufige Zertifikate verfügen, können allein mit Zertifikaten die Multi-Faktor-Authentifizierung durchführen. Ein Authentifizierungsrichtlinienadministrator sollte jedoch sicherstellen, dass die Zertifikate mit einer PIN oder biometisch geschützt sind, um als mehrstufiges Modul betrachtet zu werden.

So löst Microsoft Entra ID mehrere Regeln für Authentifizierungsrichtlinienbindungen auf

Da mehrere benutzerdefinierte Richtlinienregeln für die Authentifizierungsbindung mit unterschiedlichen Zertifikatfeldern erstellt werden können, z. B. mit Aussteller + Richtlinien-OID oder nur mit Richtlinien-OID oder nur Aussteller. Unten sind die Schritte aufgeführt, die verwendet werden, um die Authentifizierungsschutzstufe zu bestimmen, wenn sich benutzerdefinierte Regeln überlappen. Dies sind:

1. Aussteller und Richtlinien-OID-Regeln haben Vorrang vor Richtlinien-OID-Regeln. Richtlinien-OID-Regeln haben Vorrang vor Zertifikatausstellerregeln.
2. Aussteller + Richtlinien-OID-Regeln werden zuerst ausgewertet. Wenn Sie über eine benutzerdefinierte Regel mit Aussteller CA1 und Richtlinie OID 1.2.3.4.5 mit MFA verfügen, erhält nur Zertifikat A sowohl den Ausstellerwert als auch die Richtlinien-OID und erhält MFA.
3. Als Nächstes werden benutzerdefinierte Regeln mit Richtlinien-OIDs ausgewertet. Wenn Sie über ein Zertifikat A mit der Richtlinien-OID 1.2.3.4.5 verfügen und abgeleitete Anmeldeinformationen B, die auf diesem Zertifikat basieren, über die Richtlinien-OID 1.2.3.4.5.6 verfügen und die benutzerdefinierte Regel als Richtlinien-OID mit dem Wert 1.2.3.4.5 mit MFA definiert ist, erfüllt nur das Zertifikat A die MFA-Kriterien, und die Anmeldeinformationen B erfüllen nur die Kriterien der Einzelfaktor-Authentifizierung. Wenn der Benutzer bei der Anmeldung abgeleitete Anmeldeinformationen verwendet hat und für MFA konfiguriert wurde, wird von dem Benutzer ein zweiter Faktor für die erfolgreiche Authentifizierung angefordert.
4. Im Falle eines Konflikts zwischen mehreren Richtlinien-OIDs (etwa, wenn ein Zertifikat über zwei Richtlinien-OIDs verfügt, von denen eine an die einstufige Authentifizierung und die andere an MFA gebunden ist) muss das Zertifikat als einstufige Authentifizierung behandelt werden.
5. Als Nächstes werden benutzerdefinierte Regeln mithilfe der Ausstellerzertifizierungsstelle ausgewertet.
6. Wenn ein Zertifikat sowohl über eine Richtlinien-OID als auch über eine Ausstellerregelzuordnung verfügt, wird immer zuerst die Richtlinien-OID überprüft. Wird keine Richtlinienregel gefunden, werden die Bindungen des Ausstellers überprüft. Die Richtlinien-OID hat hinsichtlich der starken Authentifizierungsbindung eine höhere Priorität als der Aussteller.
7. Wenn eine Zertifizierungsstelle über eine MFA-Bindung verfügt, sind alle von der Zertifizierungsstelle ausgestellten Benutzerzertifikate als MFA qualifiziert. Die gleiche Logik gilt für die einstufige Authentifizierung.
8. Wenn eine einzelne Richtlinien-OID über eine MFA-Bindung verfügt, sind alle Benutzerzertifikate, die diese Richtlinien-OID als eine der OIDs enthalten, als MFA qualifiziert. (Ein Benutzerzertifikat kann mehrere Richtlinien-OIDs enthalten.)
9. Ein Zertifikatausgeber kann immer nur über eine einzelne gültige starke Authentifizierungsbindung verfügen. Es kann also nicht gleichzeitig an die einstufige Authentifizierung und an MFA gebunden sein.

Wichtig

Es gibt ein bekanntes Problem, bei dem ein Entra-Mandantenadministrator eine CBA-Authentifizierungsrichtlinienregel mithilfe von Ausstellern und Richtlinien-OID konfiguriert, einschließlich:

• Windows Hello For Business-Registrierung
• Fido2 Security Key-Registrierung
• Windows Kennwortlose Anmeldung per Telefon

Die Geräteregistrierung mit Workplace Join-, Entra-ID- und Hybrid-Entra-ID-Gerätebeitrittsszenarien ist nicht betroffen. CBA-Authentifizierungsrichtlinienregeln, die entweder Emittenten ODER Richtlinien-OID verwenden, sind nicht betroffen. Zur Entschärfung sollten Administratoren folgendes ausführen:

• Bearbeiten Sie die zertifikatbasierten Authentifizierungsrichtlinienregeln, die derzeit sowohl Aussteller- als auch Richtlinien-OID-Optionen verwenden, und entfernen Sie entweder die Aussteller- oder OID-Anforderung und -Speicherung. OR
• Entfernen Sie die Authentifizierungsrichtlinienregel, die derzeit sowohl Aussteller als auch Richtlinien-OID verwendet, und erstellen Sie Regeln nur mit Ausstellern oder Richtlinien-OID

Wir sind daran, dieses Problem zu beheben.

Grundlegendes zur Bindungsrichtlinie für Benutzernamen

Die Bindungsrichtlinie für Benutzernamen hilft beim Überprüfen des Benutzerzertifikats. Standardmäßig wird der SAN-Prinzipalname (Subject Alternate Name, alternativer Antragstellername) im Zertifikat dem Attribut „UserPrincipalName“ des Benutzerobjekts zugeordnet, um den Benutzer zu bestimmen.

Erreichen einer höheren Sicherheit mit Zertifikatbindungen

Es gibt sieben unterstützte Methoden für Zertifikatbindungen. Im Allgemeinen gelten Zuordnungstypen als Bindungen mit hoher Affinität, wenn sie auf Bezeichnern basieren, die nicht wiederverwendet werden können, z. B. Schlüsselkennungen des Antragstellers oder öffentlicher SSH1-Schlüssel. Diese Bezeichner vermitteln eine höhere Sicherheit dafür, dass nur ein einziges Zertifikat verwendet werden kann, um den jeweiligen Benutzer zu authentifizieren.

Zuordnungstypen basierend auf Benutzernamen und E-Mail-Adressen werden als Bindungen mit niedriger Affinität betrachtet. Microsoft Entra ID implementiert drei Zuordnungen, die basierend auf wiederverwendbaren Bezeichnern als Bindungen mit niedriger Affinität gelten. Die anderen werden als Bindungen mit hoher Affinität betrachtet. Weitere Informationen finden Sie unter certificateUserIds.

Zertifikatszuordnungsfeld	Beispiele für Werte in certificateUserIds	Benutzerobjektattribute	type
PrincipalName	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	niedrige Affinität
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	niedrige Affinität
IssuerAndSubject (Vorschau)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	niedrige Affinität
Antragsteller (Vorschau)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	niedrige Affinität
SKI	X509:<SKI>123456789abcdef	certificateUserIds	hohe Affinität
SHA1PublicKey	X509:<SHA1-PUKEY>123456789abcdef	certificateUserIds	hohe Affinität
IssuerAndSerialNumber (Vorschau)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48 Um den richtigen Wert für die Seriennummer zu erhalten, führen Sie diesen Befehl aus, und speichern Sie den in CertificateUserIds angezeigten Wert: Syntax: Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Beispiel: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	hohe Affinität

Definieren der Affinitätsbindung auf Mandantenebene und Außerkraftsetzen mit benutzerdefinierten Regeln (Vorschau)

Mit diesem Feature kann ein Authentifizierungsrichtlinienadministrator konfigurieren, ob ein Benutzer mithilfe der Bindungszuordnung mit niedriger Affinität oder mit hoher Affinität authentifiziert werden kann. Sie können die erforderliche Affinitätsbindungfür den Mandanten festlegen, die für alle Benutzer gilt. Sie können den mandantenweiten Standardwert auch außer Kraft setzen, indem Sie benutzerdefinierte Regeln basierend auf Aussteller und/oder Richtlinien-OIDerstellen.

So löst Microsoft Entra ID mehrere Regeln für Benutzernamenrichtlinienbindungen auf

Verwenden Sie die Bindung mit der höchsten Priorität (niedrigste Zahl).

1. Schlagen Sie das Benutzerobjekt mithilfe des Benutzernamens oder des Benutzerprinzipalnamens nach.
2. Rufen Sie die Liste aller Benutzernamenbindungen vom Mandantenadministrator in der Konfiguration der CBA-Authentifizierungsmethode ab, sortiert nach dem Attribut „priority„. Heute wird das Konzept der Priorität nicht in der Portal-UX verfügbar gemacht. Graph gibt Ihnen das Prioritätsattribut für jede Bindung zurück, und sie werden im Auswertungsprozess verwendet.
3. Wenn für den Mandanten eine Bindung mit hoher Affinität aktiviert ist oder der Zertifikatwert einer benutzerdefinierten Regel entspricht, die eine Bindung mit hoher Affinität erfordert, entfernen Sie alle Bindungen mit niedriger Affinität aus der Liste.
4. Bewerten Sie jede Bindung in der Liste, bis eine erfolgreiche Authentifizierung erfolgt.
5. Wenn das X.509-Zertifikatsfeld der konfigurierten Bindung im vorgelegten Zertifikat enthalten ist, gleicht Microsoft Entra ID den Wert im Zertifikatsfeld mit dem Wert des Benutzerobjektattributs ab.
   1. Wenn eine Übereinstimmung gefunden wird, ist die Benutzerauthentifizierung erfolgreich.
   2. Wird keine Übereinstimmung gefunden, fahren Sie mit der Bindung mit der nächsten Priorität fort.
6. Ist das X.509-Zertifikatfeld im vorgelegten Zertifikat nicht enthalten, fahren Sie mit der Bindung mit der nächsten Priorität fort.
7. Überprüfen Sie alle konfigurierten Benutzernamenbindungen, bis eine von ihnen zu einer Übereinstimmung führt und die Benutzerauthentifizierung erfolgreich ist.
8. Wenn bei keiner der konfigurierten Benutzernamenbindungen eine Übereinstimmung gefunden wird, schlägt die Benutzerauthentifizierung fehl.

Sichern der Microsoft Entra-Konfiguration mit mehreren Benutzernamenbindungen

Für jedes der Microsoft Entra-Benutzerobjektattribute (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds), die verfügbar sind, um Zertifikate an Microsoft Entra-Benutzerkonten zu binden, gelten eindeutige Einschränkungen, um sicherzustellen, dass ein Zertifikat nur für ein einziges Microsoft Entra-Benutzerkonto gilt. Microsoft Entra CBA unterstützt jedoch mehrere Bindungsmethoden in der Richtlinie Benutzernamenbindung, mit der ein Administrator ein Zertifikat für mehrere Konfigurationen von Entra-Benutzerkonten aufnehmen kann.

Wichtig

Bei Konfiguration mehrerer Bindungen ist die Microsoft Entra-CBA-Authentifizierung nur so sicher wie Ihre niedrigste Bindung mit niedriger Affinität, da CBA jede Bindung überprüft, um den Benutzer zu authentifizieren. Um ein Szenario zu verhindern, in dem ein einzelnes Zertifikat mehreren Microsoft Entra-Konten entspricht, kann ein Authentifizierungsrichtlinienadministrator:

• Eine einzige Bindungsmethode in der Richtlinie für Benutzernamenbindungen konfigurieren.
• Wenn ein Mandant mehrere Bindungsmethoden konfiguriert hat und nicht zulassen möchte, dass ein Zertifikat mehreren Konten zugeordnet wird, muss der Administrator der Authentifizierungsrichtlinie sicherstellen, dass alle in der Richtlinie konfigurierten zulässigen Methoden demselben Microsoft Entra-Konto zugeordnet werden. Alle Benutzerkonten sollten Werte aufweisen, die allen Bindungen entsprechen.
• Wenn ein Mandant mehrere Bindungsmethoden konfiguriert hat, sollte der Authentifizierungsrichtlinienadministrator sicherstellen, dass er nicht mehr als eine Bindung mit niedriger Affinität aufweist.

Nehmen wir zum Beispiel an, Sie haben zwei Bindungen von Benutzernamen an PrincipalName, die UPN und SubjectKeyIdentifier (SKI) an certificateUserIds zugeordnet sind. Wenn Sie möchten, dass ein Zertifikat nur für ein einzelnes Konto verwendet wird, muss ein Administrator der Authentifizierungsrichtlinie sicherstellen, dass dieses Konto den UPN hat, der im Zertifikat enthalten ist, und die SKI-Zuordnung im Attribut certificateUserId desselben Kontos implementieren.

Unterstützung für mehrere Zertifikate mit einem Entra-Benutzerkonto (M:1)

Es gibt Szenarien, in denen eine Organisation mehrere Zertifikate für eine einzelne Identität ausgibt. Dies kann am häufigsten eine abgeleitete Anmeldeinformation für ein mobiles Gerät sein oder auch für ein sekundäres Smart Karte- oder x509-Anmeldeinformationshalter geeignetes Gerät wie ein Yubikey sein.

Nur Cloudkonten Für reine Cloudkonten können Sie mehrere Zertifikate (bis zu 5) für die Verwendung zuordnen, indem Sie das Feld „certificateUserIds“ (Autorisierungsinformationen im Benutzerportal) mit eindeutigen Werten auffüllen, die jedes Zertifikat identifizieren. Wenn die Organisation Bindungen mit hoher Affinität wie Aussteller + Seriennummer verwendet, können Werte in „CertificateUserIds“ wie folgt aussehen:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

In diesem Beispiel stellt der erste Wert X509Certificate1 dar, und der zweite Wert stellt X509Certificate2 dar. Der Benutzer kann bei der Anmeldung ein Zertifikat präsentieren und solange die CBA-Benutzernamenbindung auf das Feld „certificateUserIds„ verweist, um nach dem bestimmten Bindungstyp (d. h. Aussteller + Seriennummer in diesem Beispiel) zu suchen, wird der Benutzer erfolgreich angemeldet.

Hybride synchronisierte Konten Für synchronisierte Konten können Sie mehrere Zertifikate zur Verwendung zuordnen, indem Sie das Feld „altSecurityIdentities“ in AD mit den Werten füllen, die jedes Zertifikat identifizieren. Wenn die Organisation Bindungen mit hoher Affinität (d. h. starke Authentifizierung) wie Aussteller + Seriennummer verwendet, könnte dies wie folgt aussehen:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

In diesem Beispiel stellt der erste Wert X509Certificate1 dar, und der zweite Wert stellt X509Certificate2 dar. Diese Werte müssen dann mit dem Feld „certificateUserIds„ in Azure AD synchronisiert werden.

Unterstützung für ein Zertifikat mit mehreren Entra-Benutzerkonten (1:M)

Es gibt Szenarien, in denen ein Benutzer dasselbe Zertifikat für die Authentifizierung bei mehreren Identitäten verwenden muss. Dies gilt am häufigsten für administrative Konten. Sie kann auch für Entwicklerkonten oder temporäre Pflichtkonten gelten. In herkömmlichem AD wird das Feld „altSecurityIdentities„ verwendet, um die Zertifikatwerte aufzufüllen, und während der Anmeldung wird ein Hinweis verwendet, um AD an das gewünschte Konto zu leiten, um nach der Anmeldung zu suchen. Mit Microsoft Entra CBA ist dies anders und es gibt keinen Hinweis. Stattdessen identifiziert Home Realm Discovery das gewünschte Konto, um die Zertifikatwerte zu überprüfen. Der andere Hauptunterschied besteht darin, dass Microsoft Entra CBA die Eindeutigkeit im Feld „certificateUserIds„ erzwingt. Dies bedeutet, dass zwei Konten nicht die gleichen Zertifikatwerte auffüllen können.

Wichtig

Es ist keine sehr sichere Konfiguration, dieselben Anmeldeinformationen für die Authentifizierung bei verschiedenen Entra-ID-Konten zu verwenden. Es wird empfohlen, kein Zertifikat für mehrere Entra-Benutzerkonten zuzulassen.

Nur Cloudkonten Für reine Cloudkonten müssen Sie mehrere Benutzernamenbindungen erstellen und eindeutige Werte jedem Benutzerkonto zuordnen, das das Zertifikat verwendet. Jedes Konto wird bei der Verwendung einer unterschiedlichen Benutzernamenbindung authentifiziert. Dies gilt innerhalb der Grenze eines einzelnen Verzeichnisses/Mandanten (d. h. der Mandantenadministrator kann das Zertifikat auch für die Verwendung in einem anderen Verzeichnis/Mandanten zuordnen, solange auch die Werte pro Konto eindeutig bleiben).

Füllen Sie das Feld „certificateUserIds„ (Autorisierungsinformationen im Benutzerportal) mit einem eindeutigen Wert, der das gewünschte Zertifikat identifiziert. Wenn die Organisation Bindungen mit hoher Affinität wie Aussteller + Seriennummer und SKI verwendet (d. h. starke Authentifizierung), könnte dies wie folgt aussehen:

Benutzernamenbindungen:

• Aussteller + Seriennummer -> CertificateUserIds
• SKI -> CertificateUserIds

„CertificateUserIds“-Werte des Benutzerkontos:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Wenn nun ein Benutzer dasselbe Zertifikat bei der Anmeldung anzeigt, meldet sich der Benutzer erfolgreich an, da sein Konto einem eindeutigen Wert für dieses Zertifikat entspricht. Ein Konto wird mit Aussteller+Seriennummer und das andere mit SKI-Bindung authentifiziert.

Hinweis

Die Anzahl der Konten, die auf diese Weise verwendet werden können, ist auf die Anzahl der Benutzernamensbindungen beschränkt, die für den Mandanten konfiguriert sind. Wenn die Organisation nur Bindungen mit hoher Affinität verwendet, ist die Anzahl der unterstützten Konten auf 3 beschränkt. Wenn die Organisation auch Bindungen mit niedriger Affinität verwendet, erhöht sich diese Zahl auf 7 Konten (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Hybride synchronisierte Konten Bei synchronisierten Konten ist der Ansatz ein anderer. Während der Mandantenadministrator eindeutige Werte jedem Benutzerkonto zuordnen kann, das das Zertifikat verwendet, würde die gängige Methode, alle Werte für jedes Konto in der Entra-ID aufzufüllen, dies erschweren. Stattdessen sollte Azure AD Connect die gewünschten Werte pro Konto auf eindeutige Werte filtern, die in das Konto in der Entra-ID aufgefüllt wurden. Die Eindeutigkeitsregel gilt innerhalb der Grenze eines einzelnen Verzeichnisses/Mandanten (d. h. Der Mandantenadministrator kann das Zertifikat auch für die Verwendung in einem anderen Verzeichnis/Mandanten zuordnen, solange auch die Werte pro Konto eindeutig bleiben). Darüber hinaus verfügt die Organisation möglicherweise über mehrere AD-Gesamtstrukturen, die Benutzer zu einem einzigen Entra-ID-Mandanten beitragen. In diesem Fall wendet Azure AD Connect den Filter auf jede dieser AD-Gesamtstrukturen mit demselben Ziel an, nur einen gewünschten eindeutigen Wert für das Cloudkonto aufzufüllen.

Füllen Sie das Feld „altSecurityIdentities„ in AD mit den Werten, die das gewünschte Zertifikat identifizieren, und fügen Sie den gewünschten Zertifikatwert für diesen Benutzerkontotyp ein (z. B. Detail, Administrator, Entwickler usw.). Wählen Sie ein Schlüsselattribut in AD aus, das der Synchronisierung angibt, welchen Benutzerkontotyp der Benutzer auswertet (z. B. msDS-cloudExtensionAttribute1). Füllen Sie dieses Attribut mit dem gewünschten Benutzertypwert auf, z. B. Details, Administrator oder Entwickler. Wenn es sich um das primäre Konto des Benutzers handelt, kann der Wert leer/null gelassen werden.

Die Konten könnten so ähnlich wie hier aussehen:

Gesamtstruktur 1 - Account1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Gesamtstruktur 1 - Account2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Gesamtstruktur 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Diese Werte müssen dann mit dem Feld „certificateUserIds“ in der Entra-ID synchronisiert werden.

Schritte zum Synchronisieren mit certificateUserIds

1. Konfigurieren von Azure AD Connect zum Hinzufügen des „alternativenSecurityIds“-Felds zum Metaverse
2. Konfigurieren Sie für jede AD-Gesamtstruktur eine neue benutzerdefinierte eingehende Regel mit hoher Priorität (niedrige Zahl unter 100). Fügen Sie eine Ausdruckstransformation mit dem Feld „altSecurityIdentities„ als Quelle hinzu. Der Zielausdruck verwendet das schlüsselbezogene Attribut, das Sie ausgewählt und aufgefüllt haben, sowie die Zuordnung zu den von Ihnen definierten Benutzertypen.
3. Beispiel:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

Im obigen Beispiel werden „altSecurityIdentities“ und das Schlüsselattribut „msDS-cloudExtensionAttribute1is“ zuerst überprüft, um festzustellen, ob sie aufgefüllt werden. Wenn nicht, wird „altSecurityIdentities“ überprüft, um festzustellen, ob es aufgefüllt ist. Wenn sie leer ist, legen wir sie auf NULL fest. Andernfalls fällt das Konto in den Standardfall und in diesem Beispiel wird nur auf die Zuordnung „Aussteller + Seriennummer„ gefiltert. Wenn das Schlüsselattribute aufgefüllt wird, wird der Wert überprüft, um festzustellen, ob er einem unserer definierten Benutzertypen entspricht. In diesem Beispiel, wenn dieser Wert detailiert ist, filtern wir nach dem „SHA1PublicKey“-Wert aus „altSecurityIdentities“. Wenn der Wert Entwickler ist, filtern wir aus „altSecurityIdentities“ auf den „SubjectKeyIssuer“-Wert. Möglicherweise gibt es mehrere Zertifikatwerte eines bestimmten Typs. Beispielsweise mehrere PrincipalName-Werte oder mehrere SKI- oder SHA1-PUKEY-Werte. Der Filter ruft alle Werte ab und synchronisiert sie in Entra ID – nicht nur den ersten, den er findet.

1. Ein zweites Beispiel, das zeigt, wie ein leerer Wert verschoben wird, wenn das Steuerelement-Attribut leer ist, findet sich unten.

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Wenn der Wert in „altSecurityIdentities„ keinem der Suchwerte im Steuerelement-Attribut entspricht, wird ein „AuthoritativeNull„ übergeben. Dadurch wird sichergestellt, dass frühere oder nachfolgende Regeln, die „alternativeSecurityId„ auffüllen, ignoriert werden und das Ergebnis in der Entra-ID leer ist.

1. Konfigurieren Sie eine neue benutzerdefinierte ausgehende Regel mit einer niedrigen Rangfolge (hohe Zahl über 160 – Ende der Liste).
2. Fügen Sie eine direkte Transformation mit dem Feld „alternativeSecurityIds„ als Quelle und dem Feld „certificateUserIds„ als Ziel hinzu.
3. Führen Sie einen Synchronisierungszyklus aus, um die Population der Daten in der Entra-ID abzuschließen.

Stellen Sie sicher, dass die CBA in jedem Mandanten mit den Benutzernamenbindungen konfiguriert ist, die auf das Feld „certificateUserIds„ für die Feldtypen verweisen, die Sie aus dem Zertifikat zugeordnet haben. Jetzt kann jeder dieser Benutzer das Zertifikat bei der Anmeldung präsentieren, und nachdem der eindeutige Wert aus dem Zertifikat anhand des Felds „certificateUserIds„ überprüft wurde, wird dieser Benutzer erfolgreich angemeldet.

Grundlegendes zum Zertifikatsperrprozess

Der Zertifikatsperrprozess ermöglicht es dem Administrator, ein zuvor ausgestelltes Zertifikat zu widerrufen, sodass es nicht mehr für die Authentifizierung verwendet werden kann. Bereits ausgestellte Token des Benutzers werden durch die Zertifikatsperrung nicht widerrufen. Eine Anleitung zum manuellen Widerrufen von Token finden Sie unter Schritt 3: Konfigurieren der Sperrung.

Im Zuge der Benutzerauthentifizierung wird die Zertifikatsperrliste (Certificate Revocation List, CRL) der Kunden durch Microsoft Entra von der entsprechenden Zertifizierungsstelle heruntergeladen und zwischengespeichert, um zu überprüfen, ob Zertifikate widerrufen wurden.

Ein Administrator kann den Verteilungspunkt für Zertifikatsperrlisten bei der Einrichtung der vertrauenswürdigen Aussteller im Microsoft Entra-Mandanten konfigurieren. Jeder vertrauenswürdige Aussteller muss über eine Zertifikatsperrliste verfügen, die über eine Internet-URL zugänglich ist.

Wichtig

Eine Zertifikatsperrliste darf maximal 20 MB (öffentliche Entra ID) bzw. maximal 45 MB (Azure US Government-Clouds) groß sein, damit sie erfolgreich von Microsoft Entra heruntergeladen und zwischengespeichert werden kann, und der Download der Zertifikatsperrliste darf maximal zehn Sekunden dauern. Wenn Microsoft Entra ID keine Zertifikatssperrliste herunterladen kann, sind zertifikatbasierte Authentifizierungen mit Zertifikaten, die von der entsprechenden Zertifizierungsstelle ausgestellt wurden, nicht erfolgreich. Als bewährte Methode empfiehlt es sich, die Größenbeschränkungen für Zertifikatsperrlistendateien einzuhalten, die Lebensdauer von Zertifikaten in vernünftigen Grenzen zu halten und abgelaufene Zertifikate zu bereinigen. Weitere Informationen finden Sie unter Gibt es eine Beschränkung für die CRL-Größe?.

Wenn ein Benutzer eine interaktive Anmeldung mit einem Zertifikat ausführt und die Zertifikatssperrliste den interaktiven Grenzwert für eine Cloud überschreitet, schlägt die erste Anmeldung mit dem folgenden Fehler fehl:

„Die von {URI} heruntergeladene Zertifikatsperrliste hat die maximale zulässige Größe ({size} Bytes) für Zertifikatsperrlisten in Microsoft Entra ID überschritten. Wiederholen Sie den Vorgang in einigen Minuten. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihre Mandantenadministratoren.“

Nach dem Fehler versucht Microsoft Entra ID, die Zertifikatssperrliste unter Berücksichtigung dienstseitiger Grenzwerte herunterzuladen (45 MB in öffentlicher Entra ID und 150 MB in Azure US Government-Clouds).

Wichtig

Wenn der Administrator die Konfiguration der CRL überspringt, führt Microsoft Entra ID während der zertifikatbasierten Authentifizierung des Benutzers keine Prüfungen gegen die Zertifikatssperrliste durch. Dies kann für eine erste Problembehandlung hilfreich sein. In der Produktion wird jedoch davon abgeraten.

OCSP (Online Certificate Status Protocol) wird aus Leistungs- und Zuverlässigkeitsgründen derzeit nicht unterstützt. Anstatt die Zertifikatsperrliste bei jeder Verbindung durch den Clientbrowser für OCSP herunterzuladen, lädt Microsoft Entra ID die Zertifikatsperrliste einmal bei der ersten Anmeldung herunter und speichert sie zwischen, was die Leistung und Zuverlässigkeit der Zertifikatssperrlistenüberprüfung verbessert. Darüber hinaus wird auch der Cache indiziert, was die Suche jedes Mal erheblich beschleunigt. Kunden müssen Zertifikatsperrlisten für die Zertifikatsperrung veröffentlichen.

Die folgenden Schritte sind ein typischer Ablauf der Zertifikatsperrlistenüberprüfung:

1. Microsoft Entra ID versucht, die Zertifikatssperrliste beim ersten Anmeldeereignis eines Benutzers mit einem Zertifikat des entsprechenden vertrauenswürdigen Herausgebers oder der Zertifizierungsstelle herunterzuladen.
2. Microsoft Entra speichert die Zertifikatssperrliste zwischen und verwendet sie anschließend für alle weiteren Aufgaben wieder. Dabei werden das nächste Aktualisierungsdatum und, sofern verfügbar, das nächste Veröffentlichungsdatum der Zertifikatssperrliste (von Windows Server-Zertifizierungsstellen verwendet) im Zertifikatssperrlistendokument berücksichtigt.
3. Die zertifikatbasierte Benutzerauthentifizierung schlägt in folgenden Fällen fehl:

   • Für den vertrauenswürdigen Aussteller wurde eine Zertifikatsperrliste konfiguriert, und Microsoft Entra kann die Zertifikatsperrliste aufgrund von Verfügbarkeits-, Größen- oder Wartezeiteinschränkungen nicht herunterladen.

   • Das Zertifikat des Benutzers ist in der Zertifikatsperrliste als widerrufen angegeben.

     

   • Microsoft Entra ID versucht, eine neue Zertifikatssperrliste vom Verteilungspunkt herunterzuladen, wenn das zwischengespeicherte Zertifikatssperrlistendokument abgelaufen ist.

Hinweis

Microsoft Entra überprüft die Zertifikatssperrliste der ausstellenden Zertifizierungsstelle und anderer Zertifizierungsstellen in der PKI-Vertrauenskette bis hinauf zur Stammzertifizierungsstelle. Für die Überprüfung der Zertifikatsperrliste in der PKI-Kette gilt eine Obergrenze von maximal 10 Zertifizierungsstellen ab dem Leaf Client-Zertifikat. Mit dieser Einschränkung soll sichergestellt werden, dass ein böswilliger Akteur den Dienst nicht zum Erliegen bringt, indem er eine PKI-Kette mit einer großen Anzahl von Zertifizierungsstellen und einer größeren Zertifikatssperrlistengröße hochlädt. Wenn die PKI-Kette des Mandanten mehr als fünf Zertifizierungsstellen aufweist und im Falle der Kompromittierung einer Zertifizierungsstelle sollte der Administrator den kompromittierten vertrauenswürdigen Aussteller aus der Microsoft Entra-Mandantenkonfiguration entfernen.

Wichtig

Aufgrund der Art der CRL-Zwischenspeicherung und der Veröffentlichungszyklen empfiehlt es sich im Falle einer Zertifikatsperrung dringend, auch alle Sitzungen des betroffenen Benutzers in Microsoft Entra ID zu widerrufen.

Derzeit gibt es keine Möglichkeit, den Download der Zertifikatsperrliste manuell zu erzwingen oder erneut auszulösen.

Konfigurieren der Sperrung

Zum Sperren eines Clientzertifikats ruft Microsoft Entra ID die Zertifikatsperrliste von den URLs ab, die als Teil der Informationen zur Zertifizierungsstelle hochgeladen wurden, und platziert diese Liste im Zwischenspeicher. Anhand des Zeitstempels der letzten Veröffentlichung (EigenschaftEffective Date ) in der Zertifikatsperrliste wird sichergestellt, dass die Liste noch gültig ist. Der Verweis auf die Zertifikatsperrliste erfolgt regelmäßig, um den Zugriff auf Zertifikate zu sperren, die in dieser Liste enthalten sind.

Wenn eine schnellere Sperrung erforderlich ist (beispielsweise beim Verlust eines Geräts), kann der Autorisierungstoken des Benutzers für ungültig erklärt werden. Um das Autorisierungstoken für ungültig zu erklären, legen Sie das Feld StsRefreshTokenValidFrom für diesen Benutzer über Windows PowerShell fest. Das Feld StsRefreshTokenValidFrom muss für jeden Benutzer aktualisiert werden, für den der Zugriff gesperrt werden soll.

Um sicherzustellen, dass die Sperrung aufrechterhalten wird, muss die Eigenschaft Effective Date der Zertifikatsperrliste auf ein Datum festgelegt werden, das nach dem Wert von StsRefreshTokenValidFrom liegt. Stellen Sie außerdem sicher, dass das betroffene Zertifikat in der Zertifikatsperrliste enthalten ist.

Hinweis

Azure AD- und MSOnline PowerShell-Module sind ab dem 30. März 2024 veraltet. Weitere Informationen finden Sie im Update zur Unterstützungseinstellung. Nach diesem Datum wird die Unterstützung für diese Module auf die Migrationsunterstützung für das Microsoft Graph PowerShell-SDK und Sicherheitskorrekturen beschränkt. Die veralteten Module funktionieren weiterhin bis zum 30. März 2025.

Es wird empfohlen, für die Interaktion mit Microsoft Entra ID (früher Azure AD) zu Microsoft Graph PowerShell zu migrieren. Informationen zu allgemeinen Migrationsfragen finden Sie in den häufig gestellten Fragen zur Migration. Hinweis: Bei der Version 1.0.x von MSOnline können nach dem 30. Juni 2024 Unterbrechungen auftreten.

Die unten aufgeführten Schritte zeigen, wie Sie das Autorisierungstoken aktualisieren und für ungültig erklären, indem Sie das Feld StsRefreshTokenValidFrom festlegen.

1. Herstellen einer Verbindung mit PowerShell:

   Connect-MgGraph
   

2. Rufen Sie den aktuellen StsRefreshTokensValidFrom-Wert für einen Benutzer ab:

           $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
           $user.StsRefreshTokensValidFrom
   

3. Legen Sie einen neuen StsRefreshTokensValidFrom-Wert für den Benutzer fest, der mit dem aktuellen Zeitstempel übereinstimmt:

           Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
   

Das festgelegte Datum muss in der Zukunft liegen. Wenn das Datum nicht in der Zukunft liegt, wird die StsRefreshTokensValidFrom -Eigenschaft nicht festgelegt. Wenn das Datum in der Zukunft liegt, wird StsRefreshTokensValidFrom auf die aktuelle Uhrzeit festgelegt (nicht das Datum, das mit dem Befehl „Set-MsolUser“ angegeben ist).

Funktionsweise der CBA (CAN) mit einer Richtlinie für die Authentifizierungsstärke für bedingten Zugriff

Kunden können eine Richtlinie für Authentifizierungsstärke für bedingten Zugriff erstellen, um anzugeben, dass die CBA (CAN) für den Zugriff auf eine Ressource verwendet wird.

Sie können die integrierte Phishing-sichere MFA-Authentifizierungsstärke verwenden. Diese Richtlinie lässt nur Phishing-sichere Authentifizierungsmethoden zu, z. B. CBA (CAN), FIDO2-Sicherheitsschlüssel und Windows Hello for Business.

Sie können auch eine benutzerdefinierte Authentifizierungsstärke erstellen, damit nur CBA (CAN) auf vertrauliche Ressourcen zugreifen kann. Sie können die CBA (CAN) als einstufiger, mehrstufiger oder beides zulassen. Weitere Informationen finden Sie unter Authentifizierungsstärke für bedingten Zugriff.

CBA-Authentifizierungsstärke mit erweiterten Optionen

In der Richtlinie für CBA-Authentifizierungsmethoden kann ein Administrator die Stärke des Zertifikats mithilfe der Authentifizierungsbindungsrichtlinie für die CBA-Methode ermitteln. Jetzt können Sie erweiterte Optionen konfigurieren, wenn Sie eine benutzerdefinierte Authentifizierungsstärke erstellen, um ein bestimmtes Zertifikat zu verwenden, basierend auf Aussteller- und Richtlinien-OIDs, wenn Benutzer CBA für den Zugriff auf bestimmte vertrauliche Ressourcen ausführen. Dieses Feature bietet eine genauere Konfiguration, um die Zertifikate und Benutzer zu bestimmen, die auf Ressourcen zugreifen können. Weitere Informationen finden Sie unter Weitere Optionen für Authentifizierungsstärke für bedingten Zugriff.

Grundlegendes zu Anmeldeprotokollen

Anmeldeprotokolle enthalten Informationen zu Anmeldungen und zur Verwendung Ihrer Ressourcen durch die Benutzer. Weitere Informationen zu Anmeldeprotokollen finden Sie unter Anmeldeprotokolle in Microsoft Entra ID.

Im Anschluss werden zwei Szenarien beschrieben: eins, in dem das Zertifikat die Kriterien der einstufigen Authentifizierung erfüllt, und eins, in dem das Zertifikat die MFA-Kriterien erfüllt.

Wählen Sie für die Testszenarien einen Benutzer mit einer Richtlinie für bedingten Zugriff aus, die MFA erfordert. Konfigurieren Sie die Benutzerbindungsrichtlinie durch Zuordnen des SAN-Prinzipalnamens zu „UserPrincipalName“.

Das Benutzerzertifikat muss wie im folgenden Screenshot konfiguriert sein:

Problembehandeln von Anmeldeproblemen mit dynamischen Variablen in Anmeldeprotokollen

Anmeldeprotokolle liefern zwar alle Informationen zum Debuggen der Anmeldeprobleme eines Benutzers, es kann aber vorkommen, dass bestimmte Werte erforderlich sind und Informationen in den Anmeldeprotokollen fehlen, weil Anmeldeprotokolle keine dynamischen Variablen unterstützen. Beispiel: Als Fehlerursache würde im Anmeldeprotokoll etwaw wie „Die Zertifikatssperrliste (CRL) konnte die Signatur nicht überprüfen. Erwartete Schlüssel-ID des Antragstellers {expectedSKI} stimmt nicht mit dem CRL-Autoritätsschlüssel {crlAK} überein. Bitten Sie Ihren Mandantenadministrator, die CRL-Konfiguration zu überprüfen.“ Dabei werden {expectedSKI} und {crlAKI} nicht mit korrekten Werten aufgefüllt.

Kopieren Sie im Fall von Benutzeranmeldungen mit CBA-Fehlern die Protokolldetails über den Link „Weitere Details“ auf der Fehlerseite. Ausführlichere Informationen finden Sie auf der Seite Verstehen von CBA-Fehlern

Testen der einstufigen Authentifizierung

Konfigurieren Sie für das erste Testszenario die Authentifizierungsrichtlinie so, dass die Regel für den Antragsteller des Ausstellers (issuerSubject) die Kriterien der einstufigen Authentifizierung erfüllt.

1. Melden Sie sich beim Microsoft Entra Admin Center mithilfe der zertifikatsbasierten Authentifizierung als Testbenutzer an. Die Authentifizierungsrichtlinie wird festgelegt, wobei die Issuer-Subject-Regel die einstufige Authentifizierung erfüllt.

2. Suchen Sie nach Anmeldeprotokollen, und wählen Sie diese Option aus.

   Im Anschluss gehen wir näher auf einige der Einträge ein, die unter Anmeldeprotokolle zu finden sein können:

   Im ersten Eintrag wird das X.509-Zertifikat vom Benutzer angefordert. Der Status Unterbrochen bedeutet, dass Microsoft Entra ID den Aktivierungsstatus der zertifikatbasierten Authentifizierung im Mandanten verifiziert hat und ein Zertifikat für die Authentifizierung angefordert wird.

   

   Die Aktivitätsdetails zeigen, dass dies nur Teil des erwarteten Anmeldeflusses ist, in dem der Benutzer ein Zertifikat auswählt.

   

   Unter Zusätzliche Informationen werden die Zertifikatinformationen angezeigt.

   

   Diese zusätzlichen Einträge zeigen, dass die Authentifizierung abgeschlossen ist, ein primäres Aktualisierungstoken an den Browser zurückgegeben wird und der Benutzer Zugriff auf die Ressource erhält.

   

Testen der Multi-Faktor-Authentifizierung

Konfigurieren Sie für das nächste Testszenario die Authentifizierungsrichtlinie so, dass die policyOID-Regel die Kriterien der Multi-Faktor-Authentifizierung erfüllt.

1. Melden Sie sich beim Microsoft Entra Admin Center mithilfe zertifikatsbasierter Authentifizierung an. Da die Richtlinie so festgelegt wurde, dass sie die Kriterien der Multi-Faktor-Authentifizierung erfüllt, ist die Benutzeranmeldung ohne eine zweite Stufe erfolgreich.

2. Suchen Sie nach Anmeldedaten, und wählen Sie diese Option aus.

   In den Anmeldeprotokollen werden mehrere Einträge angezeigt, einschließlich eines Eintrags mit dem Status Unterbrochen.

   

   Die Aktivitätsdetails zeigen, dass dies nur Teil des erwarteten Anmeldeflusses ist, in dem der Benutzer ein Zertifikat auswählt.

   

   Der Eintrag mit dem Status Unterbrochen enthält weitere Diagnoseinformationen auf der Registerkarte Zusätzliche Informationen.

   

   Die folgende Tabelle enthält eine Beschreibung der einzelnen Felder:

   Feld	BESCHREIBUNG
   Antragsstellername des Benutzerzertifikats	Bezieht sich auf das Feld „Antragstellername“ im Zertifikat.
   Benutzerzertifikatsbindung	Zertifikat: Prinzipalname; Benutzerattribut: userPrincipalName; Rang: 1 Dieses Feld gibt Aufschluss darüber, welches SAN-Zertifikatfeld vom Typ „PrincipalName“ dem Benutzerattribut „userPrincipalName“ zugeordnet wurde und Priorität 1 hatte.
   Authentifizierungsebene des Benutzerzertifikats	multiFactorAuthentication
   Typ der Authentifizierungsebene des Benutzerzertifikats	PolicyId Dieses Feld zeigt, dass die Richtlinien-OID verwendet wurde, um die Authentifizierungsstärke zu bestimmen.
   Bezeichner der Authentifizierungsebene des Benutzerzertifikats	1.2.3.4 Dieses Feld enthält den Wert der Bezeichnerrichtlinien-OID aus dem Zertifikat.

Grundlegendes zur Seite über Fehler bei der zertifikatbasierten Authentifizierung

Die zertifikatbasierte Authentifizierung kann aus Gründen wie z. B. einem ungültigen Zertifikat, der Auswahl des falschen bzw. eines abgelaufenen Zertifikats durch den Benutzer oder aufgrund eines Problems mit der Zertifikatsperrliste, fehlschlagen. Wenn die Zertifikatüberprüfung fehlschlägt, wird dem Benutzer diesen Fehler angezeigt:

Wenn es bei der zertifikatbasierten Authentifizierung in einem Browser zu einem Fehler kommt, müssen Sie die Browsersitzung schließen und eine neue Sitzung öffnen, um die zertifikatbasierte Authentifizierung zu wiederholen, selbst wenn der Fehler darauf zurückzuführen ist, dass Sie die Zertifikatsauswahl abbrechen. Eine neue Sitzung ist erforderlich, da Browser das Zertifikat zwischenspeichern. Wenn die CBA wiederholt wird, sendet der Browser das zwischengespeicherte Zertifikat während der TLS-Challenge, wodurch ein Anmeldefehler und der Überprüfungsfehler verursacht werden.

Wählen Sie Weitere Details, um Protokollierungsinformationen abzurufen, die an einen Administrator gesendet werden können, der wiederum weitere Informationen aus den Anmeldeprotokollen abrufen kann.

Wählen Sie Weitere Anmeldemethoden, um andere Methoden auszuprobieren, die dem Benutzer zur Anmeldung zur Verfügung stehen.

Hinweis

Wenn Sie die zertifikatbasierte Authentifizierung in einem Browser wiederholen, schlägt sie aufgrund des Problems mit der Zwischenspeicherung des Browsers immer wieder fehl. Benutzer müssen eine neue Browsersitzung öffnen und sich erneut anmelden.

Zertifikatbasierte Authentifizierung in MRU-Methoden (MostRecentlyUsed)

Sobald sich ein Benutzer erfolgreich mit CBA authentifiziert hat, wird die MRU (MostRecentlyUsed)-Authentifizierungsmethode des Benutzers auf „CBA“ festgelegt. Wenn der Benutzer das nächste Mal seinen UPN eingibt und Weiter auswählt, wird er direkt zur CBA-Methode weitergeleitet und muss nicht die Option Zertifikat oder Smartcard verwenden auswählen.

Um die MRU-Methode zurückzusetzen, muss der Benutzer die Zertifikatauswahl abbrechen, Weitere Anmeldemethoden auswählen, eine andere verfügbare Methode auswählen und sich erfolgreich authentifizieren.

Unterstützung für externe Identitäten

Eine externe Identität kann keine Multi-Faktor-Authentifizierung beim Ressourcenmandanten mit der zertifikatbasierten Authentifizierung mit Microsoft Entra ausführen. Lassen Sie den Benutzer stattdessen MFA mithilfe der zertifikatbasierten Authentifizierung auf dem Heimmandanten ausführen, und richten Sie mandantenübergreifende Einstellungen für den Ressourcenmandanten ein, um der MFA vom Heimmandanten zu vertrauen.

Weitere Informationen zum Aktivieren von Multi-Faktor-Authentifizierung von Microsoft Entra-Mandanten vertrauen finden Sie unter Konfigurieren des mandantenübergreifenden Zugriffs für die B2B-Zusammenarbeit.

Nächste Schritte

• Übersicht über Microsoft Entra-CBA
• Informationen zum Konfigurieren von Microsoft Entra-CBA
• Microsoft Entra-CBA auf iOS-Geräten
• Microsoft Entra-CBA auf Android-Geräten
• Windows-Smartcardanmeldung mithilfe der zertifikatbasierten Microsoft Entra-Authentifizierung
• Zertifikatbenutzer-IDs
• Migrieren von Verbundbenutzer*innen
• Häufig gestellte Fragen
• Problembehandlung bei der zertifikatsbasierten Authentifizierung mit Microsoft Entra