Technische technische informatie over verificatie op basis van Microsoft Entra-certificaten

Artikel
12/14/2023

In dit artikel wordt uitgelegd hoe Verificatie op basis van certificaten (CBA) van Microsoft Entra werkt en wordt dieper ingegaan op technische details over Microsoft Entra CBA-configuraties.

Hoe werkt verificatie op basis van Microsoft Entra-certificaten?

In de volgende afbeelding wordt beschreven wat er gebeurt wanneer een gebruiker zich probeert aan te melden bij een toepassing in een tenant waarvoor Microsoft Entra CBA is ingeschakeld.

Afbeelding met stappen over hoe verificatie op basis van certificaten van Microsoft Entra werkt.

Nu doorlopen we elke stap:

De gebruiker probeert toegang te krijgen tot een toepassing, zoals MyApps-portal.
Als de gebruiker nog niet is aangemeld, wordt de gebruiker omgeleid naar de aanmeldingspagina van Microsoft Entra ID-gebruiker op https://login.microsoftonline.com/.
De gebruiker voert zijn gebruikersnaam in op de aanmeldingspagina van Microsoft Entra en selecteert vervolgens Volgende. Microsoft Entra ID voert detectie van thuisrealm uit met behulp van de tenantnaam en de gebruikersnaam wordt gebruikt om de gebruiker in de tenant op te zoeken.
Microsoft Entra-id controleert of CBA is ingeschakeld voor de tenant. Als CBA is ingeschakeld, ziet de gebruiker een koppeling om een certificaat of smartcard te gebruiken op de wachtwoordpagina. Als de gebruiker de aanmeldingskoppeling niet ziet, controleert u of CBA is ingeschakeld voor de tenant. Zie Hoe kan ik Microsoft Entra CBA inschakelen voor meer informatie.

Notitie

Als CBA is ingeschakeld voor de tenant, zien alle gebruikers de koppeling om een certificaat of smartcard te gebruiken op de wachtwoordpagina. Alleen de gebruikers binnen het bereik van CBA kunnen zich echter verifiëren bij een toepassing die gebruikmaakt van Microsoft Entra ID als id-provider (IdP).

Als u andere verificatiemethoden hebt ingeschakeld, zoals Telefoon aanmeldings- of beveiligingssleutels, zien gebruikers mogelijk een ander aanmeldingsscherm.
Zodra de gebruiker verificatie op basis van certificaten selecteert, wordt de client omgeleid naar het eindpunt voor certificaatverificatie. Dit is https://certauth.login.microsoftonline.com voor de openbare Entra-id. Voor Azure Government is https://certauth.login.microsoftonline.us het eindpunt voor certificaatverificatie.

Het eindpunt voert wederzijdse TLS-verificatie uit en vraagt het clientcertificaat aan als onderdeel van de TLS-handshake. Er wordt een vermelding voor deze aanvraag weergegeven in het aanmeldingslogboek.

Notitie

De netwerkbeheerder moet toegang verlenen tot de aanmeldingspagina van de gebruiker en het eindpunt *.certauth.login.microsoftonline.com voor certificaatverificatie voor de cloudomgeving van de klant. Schakel TLS-inspectie uit op het certauth-eindpunt om ervoor te zorgen dat de aanvraag voor het clientcertificaat slaagt als onderdeel van de TLS-handshake.

Zorg ervoor dat uw TLS-inspectie-uitschakeling ook werkt voor de nieuwe URL met hints voor verleners. Codeer de URL niet met tenantId, omdat deze mogelijk wordt gewijzigd voor B2B-gebruikers. Gebruik een reguliere expressie om zowel de oude als de nieuwe URL te laten werken voor TLS-inspectie-uitschakelen. Bijvoorbeeld, afhankelijk van de proxy, gebruik *.certauth.login.microsoftonline.com of *certauth.login.microsoftonline.com. Gebruik of *certauth.login.microsoftonline.usin Azure Government*.certauth.login.microsoftonline.us.

Tenzij toegang is toegestaan, mislukt verificatie op basis van certificaten als u de aanstaande functie vertrouwde CA-hints inschakelt.
Microsoft Entra ID vraagt een clientcertificaat aan. De gebruiker kiest het clientcertificaat en selecteert OK.

Notitie

Vertrouwde CA-hints worden niet ondersteund, dus de lijst met certificaten kan niet verder worden beperkt. We kijken in de toekomst naar het toevoegen van deze functionaliteit.
De Microsoft Entra-id verifieert de certificaatintrekkingslijst om ervoor te zorgen dat het certificaat niet is ingetrokken en geldig is. Microsoft Entra ID identificeert de gebruiker met behulp van de gebruikersnaambinding die is geconfigureerd op de tenant om de waarde van het certificaatveld toe te wijzen aan de waarde van het gebruikerskenmerk.
Als een unieke gebruiker wordt gevonden met een beleid voor voorwaardelijke toegang waarvoor meervoudige verificatie is vereist en de bindingsregel voor certificaatverificatie voldoet aan MFA, meldt Microsoft Entra ID de gebruiker onmiddellijk aan. Als MFA vereist is, maar het certificaat voldoet aan slechts één factor, wordt aanmelding zonder wachtwoord of FIDO2 aangeboden als tweede factor als ze al zijn geregistreerd.
Microsoft Entra ID voltooit het aanmeldingsproces door een primair vernieuwingstoken terug te sturen om aan te geven dat de aanmelding is geslaagd.
Als de gebruiker zich met succes heeft aangemeld, heeft deze toegang tot de toepassing.

Verificatie op basis van certificaten is geschikt voor MFA

Microsoft Entra CBA is geschikt voor meervoudige verificatie (MFA). Microsoft Entra CBA kan één factor (SF) of multifactor (MF) zijn, afhankelijk van de tenantconfiguratie. Door CBA in te schakelen kan een gebruiker MFA mogelijk voltooien. Een gebruiker heeft mogelijk meer configuratie nodig om MFA te voltooien en controleer of er andere verificatiemethoden moeten worden geregistreerd wanneer de gebruiker binnen het bereik van CBA valt.

Als de gebruiker met CBA alleen een SF-certificaat (Single Factor) heeft en MFA moet voltooien:

Gebruik een wachtwoord en SF-certificaat.
Geef een tijdelijke toegangspas op.
Verificatiebeleid Beheer istrator voegt een telefoonnummer toe en staat verificatie van spraak-/tekstberichten toe voor het gebruikersaccount.

Als de gebruiker met CBA nog geen certificaat heeft uitgegeven en MFA moet voltooien:

Geef een tijdelijke toegangspas op.
Verificatiebeleid Beheer istrator voegt een telefoonnummer toe en staat verificatie van spraak-/tekstberichten toe voor het gebruikersaccount.

Als de gebruiker met CBA geen MF-certificaat kan gebruiken, zoals op een mobiel apparaat zonder smartcardondersteuning, en MFA moet voltooien:

Geef een tijdelijke toegangspas op.
De gebruiker moet een andere MFA-methode registreren (wanneer de gebruiker MF-certificaat kan gebruiken).
Gebruik het wachtwoord en het MF-certificaat (wanneer de gebruiker MF-certificaat kan gebruiken).
Verificatiebeleid Beheer istrator voegt een telefoonnummer toe en staat verificatie van spraak-/tekstberichten toe voor het gebruikersaccount.

MFA met verificatie op basis van één factor certificaat (preview)

Microsoft Entra CBA kan als tweede factor worden gebruikt om te voldoen aan MFA-vereisten met certificaten met één factor. Enkele van de ondersteunde combinaties zijn:

CBA (eerste factor) en aanmelding zonder wachtwoord (aanmelden zonder wachtwoord als tweede factor)
CBA (eerste factor) en FIDO2-beveiligingssleutels (tweede factor)
Wachtwoord (eerste factor) en CBA (tweede factor)

Gebruikers moeten een andere manier hebben om MFA op te halen en aanmelding zonder wachtwoord te registreren of FIDO2 vooraf aan te melden met Microsoft Entra CBA.

Belangrijk

Een gebruiker wordt beschouwd als MFA die kan worden gebruikt wanneer deze zijn opgenomen in de CBA-methode-instellingen. Dit betekent dat de gebruiker geen bewijs kan gebruiken als onderdeel van de verificatie om andere beschikbare methoden te registreren. Zorg ervoor dat gebruikers zonder een geldig certificaat niet zijn opgenomen in de CBA-methode-instellingen. Zie Microsoft Entra multifactor authentication voor meer informatie over hoe verificatie werkt.

Stappen voor het instellen van aanmelding zonder wachtwoord (PSI) met CBA

Aanmelding zonder wachtwoord werkt alleen als gebruikers verouderde meldingen via hun mobiele app uitschakelen.

Meld u aan bij het Microsoft Entra-beheercentrum als ten minste een verificatiebeleid Beheer istrator.
Volg de stappen bij Aanmeldingsverificatie zonder wachtwoord inschakelen.

Belangrijk

Zorg ervoor dat u in de voorgaande configuratie de optie Wachtwoordloos hebt gekozen. U moet de verificatiemodus wijzigen voor groepen die voor PSI zijn toegevoegd aan Wachtwoordloos. Als u Any kiest, werken CBA en PSI niet.
Selecteer Meervoudige verificatie>voor beveiliging>Aanvullende multi-factor authentication-instellingen in de cloud.
Schakel onder Verificatieopties meldingen uit via de mobiele app en selecteer Opslaan.

Laten we eens kijken naar een voorbeeld van een gebruiker met een enkelvoudig certificaat en is geconfigureerd voor aanmelding zonder wachtwoord.

Voer uw UPN (User Principal Name) in en selecteer Volgende.
Kies Aanmelden met een certificaat.

Als u andere verificatiemethoden hebt ingeschakeld, zoals Telefoon aanmeldings- of FIDO2-beveiligingssleutels, zien gebruikers mogelijk een ander aanmeldingsscherm.
Kies het juiste gebruikerscertificaat in de clientcertificaatkiezer en selecteer OK.
Omdat het certificaat is geconfigureerd voor de sterkte van eenmalige verificatie, heeft de gebruiker een tweede factor nodig om te voldoen aan de MFA-vereisten. De gebruiker ziet beschikbare tweede factoren, die in dit geval aanmelding zonder wachtwoord zijn. Selecteer Een aanvraag goedkeuren in mijn Microsoft Authenticator-app.
U ontvangt een melding op uw telefoon. Selecteer Aanmelden goedkeuren?.
Voer het nummer in dat u in het browser- of app-scherm ziet in Microsoft Authenticator.
Selecteer Ja en gebruiker kan zich verifiëren en aanmelden.

Informatie over het beleid inzake verificatiebinding

Het verificatiebindingsbeleid helpt bij het bepalen van de sterkte van verificatie als één factor of meervoudige verificatie. Een beheerder kan de standaardwaarde wijzigen van één factor in multifactor, of aangepaste beleidsconfiguraties instellen met behulp van de onderwerp- of beleids-OID- of Verlener- en Beleids-OID-velden in het certificaat.

Sterke certificaten

Een beheerder kan bepalen of de certificaten één factor of meervoudige sterkte zijn. Zie de documentatie die NIST Authentication Assurance Levels toewijst aan Microsoft Entra-verificatiemethoden, die voortbouwt op NIST 800-63B SP 800-63B, Richtlijnen voor digitale identiteit: verificatie en levenscyclusbeheer.

Meervoudige certificaatverificatie

Wanneer een gebruiker een meervoudig certificaat heeft, kan deze alleen meervoudige verificatie uitvoeren met certificaten. Een verificatiebeleid Beheer istrator moet er echter voor zorgen dat de certificaten worden beveiligd met een pincode of biometrische gegevens die als multifactor worden beschouwd.

Hoe Microsoft Entra ID meerdere bindingsregels voor verificatiebeleid oplost

Omdat meerdere regels voor aangepaste verificatiebindingsbeleid kunnen worden gemaakt met verschillende certificaatvelden, zoals het gebruik van issuer + policy OID, of alleen beleids-OID of alleen verlener. hieronder ziet u de stappen die worden gebruikt om het verificatiebeveiligingsniveau te bepalen wanneer aangepaste regels elkaar overlappen. Dit zijn de volgende:

Issuer + policy OID-regels hebben voorrang op beleids-OID-regels. Beleids-OID-regels hebben voorrang op regels voor certificaatverleners.
Issuer + policy OID-regels worden eerst geëvalueerd. Als u een aangepaste regel hebt met verlener CA1 en beleids-OID 1.2.3.4.5 met MFA, krijgt alleen certificaat A voldoet aan zowel de waarde van de uitgever als de beleids-OID.
Vervolgens worden aangepaste regels met behulp van beleids-OID's geëvalueerd. Als u een certificaat A met beleids-OID 1.2.3.4.5 en een afgeleide referentie B op basis van dat certificaat heeft een beleid OID 1.2.3.4.5.6 en de aangepaste regel is gedefinieerd als beleids-OID met de waarde 1.2.3.4.5 met MFA, voldoet alleen certificaat A aan MFA en referentie B voldoet alleen aan verificatie met één factor. Als de gebruiker afgeleide referenties heeft gebruikt tijdens het aanmelden en is geconfigureerd om MFA te hebben, wordt de gebruiker gevraagd om een tweede factor voor geslaagde verificatie.
Als er een conflict is tussen meerdere beleids-OID's (zoals wanneer een certificaat twee beleids-OID's heeft, waarbij één binding met één factor-verificatie en de andere bindingen met MFA) heeft, behandelt u het certificaat als een verificatie met één factor.
Vervolgens worden aangepaste regels met ca-verlener geëvalueerd.
Als een certificaat zowel beleids-OID- als verlenerregels bevat, wordt de beleids-OID altijd eerst gecontroleerd en als er geen beleidsregel wordt gevonden, worden de bindingen van de verlener gecontroleerd. Beleids-OID heeft een hogere prioriteit voor sterke verificatiebinding dan de verlener.
Als één CA is gebonden aan MFA, komen alle gebruikerscertificaten die door de CA worden uitgegeven, in aanmerking als MFA. Dezelfde logica is van toepassing op verificatie met één factor.
Als één beleids-OID is gebonden aan MFA, komen alle in aanmerking als MFA als ze een beleids-OID bevatten als een van de OID's (een gebruikerscertificaat kan meerdere beleids-OID's hebben).
Eén certificaatverlener kan slechts één geldige sterke verificatiebinding hebben (een certificaat kan dus niet binden aan zowel één factor als MFA).

Belangrijk

Er is een bekend probleem waarbij een Entra-tenantbeheerder een CBA-verificatiebeleidsregel configureert met behulp van zowel Issuer als Policy OID van invloed is op sommige scenario's voor apparaatregistratie, waaronder:

Windows Hello voor Bedrijven-inschrijving
Registratie van Fido2-beveiligingssleutel
Windows-Telefoon-aanmelding zonder wachtwoord

Apparaatregistratie met Workplace Join- en Entra ID- en Hybrid Entra ID-scenario's voor apparaatdeelname worden niet beïnvloed. CBA-verificatiebeleidsregels die gebruikmaken van Issuer OR Policy OID, worden niet beïnvloed. Om dit te verhelpen, moeten beheerders het volgende doen:

Bewerk de verificatiebeleidsregels op basis van certificaten die momenteel gebruikmaken van de opties Issuer en Policy OID en verwijder de Verlener- of OID-vereiste en sla deze op. OF
Verwijder de verificatiebeleidsregel die momenteel zowel Verlener als Beleids-OID gebruikt en maak regels met alleen verlener of beleids-OID

We proberen het probleem op te lossen.

Informatie over het bindingsbeleid voor gebruikersnamen

Het bindingsbeleid voor gebruikersnaam helpt het certificaat van de gebruiker te valideren. Standaard wordt de principalnaam van het onderwerp alternatieve naam (SAN) in het certificaat toegewezen aan het kenmerk UserPrincipalName van het gebruikersobject om de gebruiker te bepalen.

Een hogere beveiliging realiseren met certificaatbindingen

Er zijn zeven ondersteunde methoden voor certificaatbindingen. Over het algemeen worden toewijzingstypen beschouwd als hoge affiniteit als ze zijn gebaseerd op id's die u niet opnieuw kunt gebruiken, zoals onderwerpsleutel-id's of openbare SHA1-sleutel. Deze id's geven een hogere zekerheid dat slechts één certificaat kan worden gebruikt om de betreffende gebruiker te verifiëren.

Toewijzingstypen op basis van gebruikersnamen en e-mailadressen worden beschouwd als lage affiniteit. Microsoft Entra ID implementeert drie toewijzingen die als lage affiniteit worden beschouwd op basis van herbruikbare id's. De andere bindingen worden beschouwd als bindingen met hoge affiniteit. Zie certificateUserIds voor meer informatie.

Veld voor certificaattoewijzing	Voorbeelden van waarden in certificateUserIds	Gebruikersobjectkenmerken	Type
Primaire naam	`X509:<PN>bob@woodgrove.com`	userPrincipalName onPremisesUserPrincipalName certificateUserIds	lage affiniteit
RFC822Name	`X509:<RFC822>user@woodgrove.com`	userPrincipalName onPremisesUserPrincipalName certificateUserIds	lage affiniteit
IssuerAndSubject (preview)	`X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest`	certificateUserIds	lage affiniteit
Onderwerp (preview)	`X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest`	certificateUserIds	lage affiniteit
SKI	`X509:<SKI>123456789abcdef`	certificateUserIds	hoge affiniteit
SHA1PublicKey	`X509:<SHA1-PUKEY>123456789abcdef`	certificateUserIds	hoge affiniteit
IssuerAndSerialNumber (preview)	`X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48` Als u de juiste waarde voor serienummer wilt ophalen, voert u deze opdracht uit en slaat u de waarde op die wordt weergegeven in CertificateUserIds: Syntaxis: `Certutil –dump –v [~certificate path~] >> [~dumpFile path~]` Voorbeeld: `certutil -dump -v firstusercert.cer >> firstCertDump.txt`	certificateUserIds	hoge affiniteit

Affiniteitsbinding definiëren op tenantniveau en overschrijven met aangepaste regels (preview)

Met deze functie kan een verificatiebeleid Beheer istrator configureren of een gebruiker kan worden geverifieerd met behulp van bindingstoewijzing met een lage affiniteit of met een hoge affiniteit. U kunt vereiste affiniteitsbinding instellen voor de tenant, die van toepassing is op alle gebruikers. U kunt ook de standaardwaarde voor de hele tenant overschrijven door aangepaste regels te maken op basis van verlener en beleids-OID, beleids-OID of verlener.

Hoe Microsoft Entra ID meerdere bindingsregels voor gebruikersnaambeleid oplost

Gebruik de binding met de hoogste prioriteit (laagste getal).

Zoek het gebruikersobject op met behulp van de gebruikersnaam of User Principal Name.
Haal de lijst op met alle gebruikersnaambindingen die zijn ingesteld door de tenantbeheerder in de configuratie van de CBA-verificatiemethode die is gerangschikt op het kenmerk Prioriteit. Het concept van prioriteit wordt momenteel niet weergegeven in portal-UX. Graph retourneert het prioriteitskenmerk voor elke binding en ze worden gebruikt in het evaluatieproces.
Als voor de tenant een hoge affiniteitsbinding is ingeschakeld of als de certificaatwaarde overeenkomt met een aangepaste regel waarvoor een hoge affiniteitsbinding is vereist, verwijdert u alle bindingen met lage affiniteit uit de lijst.
Evalueer elke binding in de lijst totdat een geslaagde verificatie plaatsvindt.
Als het X.509-certificaatveld van de geconfigureerde binding zich op het gepresenteerde certificaat bevindt, komt Microsoft Entra-id overeen met de waarde in het certificaatveld met de kenmerkwaarde van het gebruikersobject.
1. Als er een overeenkomst wordt gevonden, is gebruikersverificatie geslaagd.
2. Als er geen overeenkomst wordt gevonden, gaat u naar de volgende prioriteitsbinding.
Als het X.509-certificaatveld zich niet in het gepresenteerde certificaat bevindt, gaat u naar de volgende prioriteitsbinding.
Valideer alle geconfigureerde gebruikersnaambindingen totdat een van deze bindingen resulteert in een overeenkomst en gebruikersverificatie is geslaagd.
Als een overeenkomst niet wordt gevonden op een van de geconfigureerde gebruikersnaambindingen, mislukt de gebruikersverificatie.

Microsoft Entra-configuratie beveiligen met meerdere gebruikersnaambindingen

Elk van de Microsoft Entra-gebruikersobjectkenmerken (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) die beschikbaar zijn om certificaten te binden aan Microsoft Entra-gebruikersaccounts, heeft een unieke beperking om ervoor te zorgen dat een certificaat alleen overeenkomt met één Microsoft Entra-gebruikersaccount. Microsoft Entra CBA ondersteunt echter meerdere bindingsmethoden in het gebruikersnaambindingsbeleid waarmee een beheerder één certificaat kan gebruiken voor meerdere configuraties van Entra-gebruikersaccounts.

Belangrijk

Als u meerdere bindingen configureert, is Microsoft Entra CBA-verificatie alleen zo veilig als uw laagste affiniteitsbinding, omdat CBA elke binding valideert om de gebruiker te verifiëren. Om te voorkomen dat één certificaat overeenkomt met meerdere Microsoft Entra-accounts, kan een verificatiebeleid Beheer istrator:

Configureer één bindingsmethode in het bindingsbeleid voor gebruikersnaam.
Als voor een tenant meerdere bindingsmethoden zijn geconfigureerd en één certificaat niet aan meerdere accounts mag worden toegewezen, moet het verificatiebeleid Beheer istrator ervoor zorgen dat alle toegestane methoden die zijn geconfigureerd in de beleidstoewijzing, aan hetzelfde Microsoft Entra-account zijn geconfigureerd. Alle gebruikersaccounts moeten waarden hebben die overeenkomen met alle bindingen.
Als voor een tenant meerdere bindingsmethoden zijn geconfigureerd, moet het verificatiebeleid Beheer istrator ervoor zorgen dat ze niet meer dan één binding met lage affiniteit hebben.

Stel dat u twee gebruikersnaambindingen hebt op PrincipalName die is toegewezen aan UPN en SubjectKeyIdentifier (SKI) aan certificateUserIds. Als u wilt dat een certificaat slechts voor één account wordt gebruikt, moet een verificatiebeleid Beheer istrator ervoor zorgen dat het account de UPN bevat die aanwezig is in het certificaat en de SKI-toewijzing implementeert in het kenmerk certificateUserId van hetzelfde account.

Ondersteuning voor meerdere certificaten met één Entra-gebruikersaccount (M:1)

Er zijn scenario's waarin een organisatie meerdere certificaten voor één identiteit uitgeeft. Meestal kan dit een afgeleide referentie zijn voor een mobiel apparaat of kan dit ook zijn voor een secundair smartcard- of x509-referentiehouder, zoals een Yubikey.

Cloudaccounts voor cloudaccounts Voor cloudaccounts kunt u meerdere certificaten (maximaal 5) toewijzen voor gebruik door het veld certificateUserIds (autorisatiegegevens in de gebruikersportal) te vullen met unieke waarden die elk certificaat identificeren. Als de organisatie hoge affiniteitsbindingen gebruikt, bijvoorbeeld Issuer + SerialNumber, kunnen waarden binnen CertificateUserIds er als volgt uitzien:

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

In dit voorbeeld vertegenwoordigt de eerste waarde X509Certificate1 en de tweede waarde X509Certificate2. De gebruiker kan een van beide certificaten presenteren bij het aanmelden en zolang de CBA-gebruikersnaambinding is ingesteld om te verwijzen naar het veld certificateUserIds om te zoeken naar het specifieke bindingstype (bijvoorbeeld Issuer+SerialNumber in dit voorbeeld), zal de gebruiker zich aanmelden.

Hybride gesynchroniseerde accounts Voor gesynchroniseerde accounts kunt u meerdere certificaten toewijzen voor gebruik door het veld altSecurityIdentities in AD in te vullen met de waarden die elk certificaat identificeren. Als de organisatie gebruikmaakt van bindingen met een hoge affiniteit (dat wil zeggen sterke verificatie), bijvoorbeeld Issuer + SerialNumber, kan dit er als volgt uitzien:

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

In dit voorbeeld vertegenwoordigt de eerste waarde X509Certificate1 en de tweede waarde X509Certificate2. Deze waarden moeten vervolgens worden gesynchroniseerd met het veld certificateUserIds in Azure AD.

Ondersteuning voor één certificaat met meerdere Entra-gebruikersaccounts (1:M)

Er zijn scenario's waarin een organisatie vereist dat de gebruiker hetzelfde certificaat gebruikt om zich te verifiëren bij meerdere identiteiten. Meestal is dit voor beheerdersaccounts. Het kan ook zijn voor ontwikkelaarsaccounts of tijdelijke dienstrekeningen. In traditionele AD wordt het veld altSecurityIdEntities gebruikt om de certificaatwaarden in te vullen en wordt tijdens de aanmelding een hint gebruikt om AD naar het gewenste account te leiden om te controleren op de aanmelding. Met Microsoft Entra CBA is dit anders en er is geen hint. In plaats daarvan identificeert Home Realm Discovery het gewenste account om de certificaatwaarden te controleren. Het andere belangrijke verschil is dat Microsoft Entra CBA uniekheid afdwingt in het veld certificateUserIds. Dit betekent dat twee accounts niet beide dezelfde certificaatwaarden kunnen vullen.

Belangrijk

Het is niet een zeer veilige configuratie om dezelfde referentie te gebruiken voor verificatie in verschillende Entra ID-accounts en het wordt aanbevolen om niet één certificaat toe te staan voor meerdere Entra-gebruikersaccounts.

Cloudaccounts voor alleen cloudaccounts Voor cloudaccounts moet u meerdere gebruikersnaambindingen maken en unieke waarden toewijzen aan elk gebruikersaccount dat het certificaat gaat gebruiken. Elk account wordt geverifieerd bij het gebruik van een andere gebruikersnaambinding. Dit geldt binnen de grenzen van één map/tenant (tenantbeheerder kan het certificaat ook toewijzen voor gebruik in een andere map/tenant, zolang de waarden ook uniek blijven per account).

Vul het veld certificateUserIds (autorisatiegegevens in de gebruikersportal) in met een unieke waarde waarmee het gewenste certificaat wordt geïdentificeerd. Als de organisatie gebruikmaakt van bindingen met hoge affiniteit (dat wil zeggen sterke verificatie) zeggen Issuer + SerialNumber en SKI, kan dit er als volgt uitzien:

Gebruikersnaambindingen:

Issuer + serienummer -> CertificateUserIds
SKI -> CertificateUserIds

Waarden voor CertificateUserIds van gebruikersaccount:
X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Wanneer een van beide gebruikers nu hetzelfde certificaat bij het aanmelden presenteert, wordt de gebruiker aangemeld omdat het account overeenkomt met een unieke waarde op dat certificaat. Het ene account wordt geverifieerd bij het gebruik van Issuer+SerialNumber en het andere met behulp van SKI-binding.

Notitie

Het aantal accounts dat op deze manier kan worden gebruikt, wordt beperkt door het aantal gebruikersnaambindingen dat is geconfigureerd voor de tenant. Als de organisatie alleen hoge affiniteitsbindingen gebruikt, wordt het aantal ondersteunde accounts beperkt tot 3. Als de organisatie ook lage affiniteitsbindingen gebruikt, neemt dit aantal toe tot 7 accounts (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Hybride gesynchroniseerde accounts Voor gesynchroniseerde accounts verschilt de benadering. Hoewel de tenantbeheerder unieke waarden kan toewijzen aan elk gebruikersaccount dat het certificaat gaat gebruiken, wordt dit moeilijk door de gebruikelijke procedure voor het invullen van alle waarden voor elk account in entra-id. In plaats daarvan moet Azure AD Verbinding maken de gewenste waarden per account filteren op unieke waarden die zijn ingevuld in het account in Entra-id. De uniekheidsregel is van toepassing binnen de grenzen van één map/tenant (tenantbeheerder kan het certificaat ook toewijzen voor gebruik in een andere directory/tenant, zolang de waarden ook uniek blijven per account). Bovendien kan de organisatie meerdere AD-forests hebben die gebruikers bijdragen aan één Entra ID-tenant. In dit geval past Azure AD Verbinding maken het filter toe op elk van deze AD-forests met hetzelfde doel om alleen een gewenste unieke waarde in te vullen voor het cloudaccount.

Vul het veld altSecurityIdentities in AD in met de waarden waarmee het gewenste certificaat wordt geïdentificeerd en om de gewenste certificaatwaarde voor dat gebruikersaccounttype op te nemen (bijvoorbeeld detailee, beheerder, ontwikkelaar, enzovoort). Selecteer een sleutelkenmerk in AD waarmee de synchronisatie wordt opgegeven welk gebruikersaccounttype de gebruiker evalueert (bijvoorbeeld msDS-cloudExtensionAttribute1). Vul dit kenmerk in met de gewenste waarde van het gebruikerstype, zoals detailee, beheerder of ontwikkelaar. Als dit het primaire account van de gebruiker is, kan de waarde leeg/null blijven.

De accounts kunnen er als volgt uitzien:

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

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

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

Deze waarden moeten vervolgens worden gesynchroniseerd met het veld certificateUserIds in Entra ID.

Stappen voor het synchroniseren met certificateUserIds

Azure AD Connect configureren om het veld alternativeSecurityIds toe te voegen aan de Metaverse
Configureer voor elk AD-forest een nieuwe aangepaste regel voor inkomend verkeer met een hoge prioriteit (laag getal onder 100). Voeg een expressietransformatie toe met het veld altSecurityId-entiteiten als de bron. De doelexpressie gebruikt het sleutelkenmerk dat u hebt geselecteerd en ingevuld, evenals de toewijzing aan de gebruikerstypen die u hebt gedefinieerd.
Voorbeeld:

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) 
)

In het bovenstaande voorbeeld worden altSecurityId-entiteiten en het sleutelkenmerk msDS-cloudExtensionAttribute1is eerst gecontroleerd om te zien of ze zijn ingevuld. Zo niet, dan wordt altSecurityId-entiteiten gecontroleerd om te zien of deze is ingevuld. Als het leeg is, stellen we deze in op NULL. Anders valt het account in het standaardscenario en in dit voorbeeld filteren we alleen op de toewijzing Issuer+SerialNumber. Als het sleutelkenmerk is ingevuld, wordt de waarde gecontroleerd om te zien of deze gelijk is aan een van onze gedefinieerde gebruikerstypen. In dit voorbeeld als die waarde gedetailleerd is, filteren we op de SHA1PublicKey-waarde uit altSecurityId-entiteiten. Als de waarde ontwikkelaar is, filteren we op de waarde SubjectKeyIssuer van altSecurityId-entiteiten. Er kunnen meerdere certificaatwaarden van een specifiek type zijn. Bijvoorbeeld meerdere PrincipalName-waarden of meerdere SKI- of SHA1-PUKEY-waarden. Met het filter worden alle waarden opgehaald en gesynchroniseerd met Entra-id, niet alleen de eerste die wordt gevonden.

Een tweede voorbeeld waarin wordt getoond hoe u een lege waarde pusht als het besturingselementkenmerk leeg is, wordt hieronder weergegeven.

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) 
)

Als de waarde in altSecurityId-entiteiten niet overeenkomt met een van de zoekwaarden in het besturingselementkenmerk, wordt er een AuthoritativeNull doorgegeven. Dit zorgt ervoor dat eerdere of volgende regels die alternatieveSecurityId vullen worden genegeerd en het resultaat leeg is in Entra-id.

Configureer een nieuwe aangepaste uitgaande regel met een lage prioriteit (hoog getal boven 160 – onder aan de lijst).
Voeg een directe transformatie toe met het veld alternativeSecurityIds als de bron en het veld certificateUserIds als doel.
Voer een synchronisatiecyclus uit om de populatie van de gegevens in Entra-id te voltooien.

Zorg ervoor dat CBA in elke tenant is geconfigureerd met de gebruikersnaambindingen die verwijzen naar het veld certificateUserIds voor de veldtypen die u uit het certificaat hebt toegewezen. Nu kan een van deze gebruikers het certificaat presenteren bij het aanmelden en nadat de unieke waarde van het certificaat is gevalideerd op basis van het veld certificateUserIds, wordt die gebruiker aangemeld.

Informatie over het proces voor certificaatintrekking

Met het proces voor certificaatintrekking kan de beheerder een eerder uitgegeven certificaat intrekken voor toekomstige verificatie. De certificaatintrekking trekt de uitgegeven tokens van de gebruiker niet in. Volg de stappen om tokens handmatig in te trekken bij Intrekken configureren.

Microsoft Entra ID downloadt en slaat de certificaatintrekkingslijst (CRL) van de klant op in de cache van hun certificeringsinstantie om te controleren of certificaten worden ingetrokken tijdens de verificatie van de gebruiker.

Een beheerder kan het CRL-distributiepunt configureren tijdens het installatieproces van de vertrouwde verleners in de Microsoft Entra-tenant. Elke vertrouwde verlener moet een CRL hebben waarnaar kan worden verwezen met behulp van een internetgerichte URL.

Belangrijk

De maximale grootte van een CRL voor Microsoft Entra-id voor het downloaden van een interactieve aanmelding en cache is 20 MB in openbare Entra-id en 45 MB in Azure US Government-clouds, en de tijd die nodig is om de CRL te downloaden mag niet langer zijn dan 10 seconden. Als Microsoft Entra-id een CRL niet kan downloaden, mislukken verificaties op basis van certificaten die zijn uitgegeven door de bijbehorende CA. Als best practice om CRL-bestanden binnen de groottelimieten te houden, moet u de levensduur van certificaten binnen redelijke grenzen houden en verlopen certificaten opschonen. Zie voor meer informatie Is er een limiet voor CRL-grootte?

Wanneer een gebruiker een interactieve aanmelding met een certificaat uitvoert en de CRL de interactieve limiet voor een cloud overschrijdt, mislukt de eerste aanmelding met de volgende fout:

"De certificaatintrekkingslijst (CRL) die is gedownload van {uri} heeft de maximaal toegestane grootte ({size} bytes) voor CRL's in Microsoft Entra ID overschreden. Probeer het over enkele minuten opnieuw. Als het probleem zich blijft voordoen, neemt u contact op met uw tenantbeheerders.

Na de fout probeert Microsoft Entra ID de CRL te downloaden die onderhevig is aan de limieten aan de servicezijde (45 MB in openbare Entra-id en 150 MB in Azure US Government-clouds).

Belangrijk

Als de beheerder de configuratie van de CRL overslaat, voert Microsoft Entra-id geen CRL-controles uit tijdens de verificatie op basis van certificaten van de gebruiker. Dit kan handig zijn voor de eerste probleemoplossing, maar moet niet worden overwogen voor productiegebruik.

Vanaf nu bieden vanwege prestatie- en betrouwbaarheidsredenen geen ondersteuning voor Online Certificate Status Protocol (OCSP). In plaats van de CRL te downloaden bij elke verbinding door de clientbrowser voor OCSP, downloadt Microsoft Entra ID eenmaal bij de eerste aanmelding en slaat deze in de cache op, waardoor de prestaties en betrouwbaarheid van CRL-verificatie worden verbeterd. We indexeren de cache ook, zodat de zoekopdracht steeds veel sneller verloopt. Klanten moeten CRL's publiceren voor certificaatintrekking.

De volgende stappen zijn een typische stroom van de CRL-controle:

Microsoft Entra ID probeert de CRL te downloaden bij het eerste aanmeldingsgebeurtenis van een gebruiker met een certificaat van de bijbehorende vertrouwde verlener of certificeringsinstantie.
Microsoft Entra ID caches en hergebruikt de CRL voor elk volgend gebruik. De datum van de volgende update wordt toegepast en, indien beschikbaar, de publicatiedatum van volgende CRL (gebruikt door Windows Server CA's) in het CRL-document.
De verificatie op basis van een gebruikerscertificaat mislukt als:
- Er is een CRL geconfigureerd voor de vertrouwde verlener en de Microsoft Entra-id kan de CRL niet downloaden vanwege beschikbaarheids-, grootte- of latentiebeperkingen.
- Het certificaat van de gebruiker wordt weergegeven als ingetrokken op de CRL.
- Microsoft Entra ID probeert een nieuwe CRL te downloaden vanaf het distributiepunt als het CRL-document in de cache is verlopen.

Notitie

Microsoft Entra ID controleert de CRL van de verlenende CA en andere CA's in de PKI-vertrouwensketen tot aan de basis-CA. We hebben een limiet van maximaal 10 CA's van het leaf-clientcertificaat voor CRL-validatie in de PKI-keten. De beperking is ervoor te zorgen dat een slechte actor de service niet uitvalt door een PKI-keten te uploaden met een groot aantal CA's met een grotere CRL-grootte. Als de PKI-keten van de tenant meer dan 5 CA's heeft en in geval van een CA-inbreuk, moet de beheerder de gecompromitteerde vertrouwde verlener verwijderen uit de configuratie van de Microsoft Entra-tenant.

Belangrijk

Vanwege de aard van CRL-caching- en publicatiecycli wordt het ten zeerste aanbevolen in het geval van een certificaatintrekking ook alle sessies van de betrokken gebruiker in Microsoft Entra ID in te trekken.

Vanaf nu is er geen manier om het downloaden van de CRL handmatig af te dwingen of opnieuw teriggeren.

Hoe kan ik het intrekken configureren?

Als u een clientcertificaat wilt intrekken, haalt Microsoft Entra-id de certificaatintrekkingslijst (CRL) op uit de URL's die zijn geüpload als onderdeel van informatie over de certificeringsinstantie en slaat deze in de cache op. De laatste publicatietijdstempel (eigenschap Effectieve datum) in de CRL wordt gebruikt om ervoor te zorgen dat de CRL nog geldig is. Er wordt regelmatig naar de CRL verwezen om de toegang tot certificaten in te trekken die deel uitmaken van de lijst.

Als een meer onmiddellijke intrekking is vereist (bijvoorbeeld als een gebruiker een apparaat verliest), kan het autorisatietoken van de gebruiker ongeldig worden gemaakt. Als u het autorisatietoken ongeldig wilt maken, stelt u het veld StsRefreshTokenValidFrom in voor deze specifieke gebruiker met behulp van Windows PowerShell. U moet het veld StsRefreshTokenValidFrom bijwerken voor elke gebruiker waarvoor u de toegang wilt intrekken.

Om ervoor te zorgen dat de intrekking behouden blijft, moet u de ingangsdatum van de CRL instellen op een datum na de waarde die is ingesteld door StsRefreshTokenValidFrom en ervoor zorgen dat het betreffende certificaat zich in de CRL bevindt.

Notitie

Azure AD- en MSOnline PowerShell-modules zijn vanaf 30 maart 2024 afgeschaft. Lees de afschaffingsupdate voor meer informatie. Na deze datum is ondersteuning voor deze modules beperkt tot migratieondersteuning voor Microsoft Graph PowerShell SDK en beveiligingsoplossingen. De afgeschafte modules blijven functioneren tot en met 30 maart 2025.

Het is raadzaam om te migreren naar Microsoft Graph PowerShell om te communiceren met Microsoft Entra ID (voorheen Azure AD). Raadpleeg de veelgestelde vragen over migratie voor veelgestelde vragen over migratie. Opmerking: versies 1.0.x van MSOnline kunnen na 30 juni 2024 onderbrekingen ondervinden.

In de volgende stappen wordt het proces voor het bijwerken en ongeldig maken van het autorisatietoken beschreven door het veld StsRefreshTokenValidFrom in te stellen.

Verbinding maken naar PowerShell:
```
Connect-MgGraph
```

Haal de huidige waarde StsRefreshTokensValidFrom voor een gebruiker op:

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

Configureer een nieuwe stsRefreshTokensValidFrom-waarde voor de gebruiker die gelijk is aan de huidige tijdstempel:
```
        Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
```

De datum die u hebt ingesteld, moet in de toekomst zijn. Als de datum zich niet in de toekomst bevindt, is de eigenschap StsRefreshTokensValidFrom niet ingesteld. Als de datum zich in de toekomst bevindt, wordt StsRefreshTokensValidFrom ingesteld op de huidige tijd (niet de datum die wordt aangegeven door de opdracht Set-MsolUser).

Hoe CBA werkt met een beleid voor verificatie van voorwaardelijke toegang

Klanten kunnen een beleid voor verificatiesterkte voor voorwaardelijke toegang maken om op te geven dat CBA wordt gebruikt voor toegang tot een resource.

U kunt de ingebouwde MFA-verificatiesterkte gebruiken die bestand is tegen phishing. Dit beleid staat alleen verificatiemethoden toe die phishingbestendig zijn, zoals CBA, FIDO2-beveiligingssleutels en Windows Hello voor Bedrijven.

U kunt ook een aangepaste verificatiesterkte maken, zodat alleen CBA toegang heeft tot gevoelige resources. U kunt CBA toestaan als één factor, multifactor of beide. Zie de sterkte van voorwaardelijke toegangsverificatie voor meer informatie.

CBA-verificatiesterkte met geavanceerde opties

In het beleid voor CBA-verificatiemethoden kan een beheerder de sterkte van het certificaat bepalen met behulp van verificatiebindingsbeleid voor de CBA-methode. U kunt nu geavanceerde opties configureren wanneer u een aangepaste verificatiesterkte maakt om te vereisen dat een specifiek certificaat moet worden gebruikt, op basis van verleners en beleids-OID's, wanneer gebruikers CBA uitvoeren voor toegang tot bepaalde gevoelige resources. Deze functie biedt een nauwkeurigere configuratie om de certificaten en gebruikers te bepalen die toegang hebben tot resources. Zie Geavanceerde opties voor verificatiesterkte voor voorwaardelijke toegang voor meer informatie.

Aanmeldingslogboeken bieden informatie over aanmeldingen en hoe uw bronnen door uw gebruikers worden gebruikt. Zie Aanmeldingslogboeken in Microsoft Entra ID voor meer informatie over aanmeldingslogboeken.

Laten we twee scenario's doorlopen, waarbij het certificaat in het eerste voldoet aan verificatie met enkelvoudige factor en een tweede scenario waarin het certificaat voldoet aan MFA.

Voor de testscenario's kiest u een gebruiker met een beleid voor voorwaardelijke toegang waarvoor MFA is vereist. Configureer het beleid voor gebruikersbinding door SAN Principal Name toe te wijzen aan UserPrincipalName.

Het gebruikerscertificaat moet als volgt worden geconfigureerd:

Schermopname van het gebruikerscertificaat.

Hoewel aanmeldingslogboeken alle informatie bevatten voor het opsporen van fouten in de aanmeldingsproblemen van een gebruiker, zijn er momenten waarop specifieke waarden vereist zijn en omdat aanmeldingslogboeken geen dynamische variabelen ondersteunen, ontbreken de aanmeldingslogboeken dan over ontbrekende gegevens. Bijvoorbeeld: De foutreden in het aanmeldingslogboek zou iets als 'De certificaatintrekkingslijst (CRL) mislukte handtekeningvalidatie weergeven. De verwachte onderwerpsleutel-id {expectedSKI} komt niet overeen met de CRL-instantiesleutel {crlAK}. Vraag de tenantbeheerder om de CRL-configuratie te controleren. Waar {expectedSKI} en {crlAKI} niet zijn gevuld met de juiste waarden.

Wanneer gebruikers zich aanmelden met CBA mislukt, kopieert u de logboekgegevens van de koppeling Meer details op de foutpagina. Zie de CBA-foutpagina voor meer informatie

Verificatie met één factor

Voor het eerste testscenario configureert u het verificatiebeleid waarbij de onderwerpregel Issuer voldoet aan verificatie met één factor.

Meld u als testgebruiker aan bij het Microsoft Entra-beheercentrum met behulp van CBA. Het verificatiebeleid wordt ingesteld waar de onderwerpregel van de verlener voldoet aan verificatie met één factor.
Zoek en selecteer aanmeldingslogboeken.

Laten we eens kijken naar een aantal vermeldingen die u kunt vinden in de aanmeldingslogboeken.

De eerste vermelding vraagt het X.509-certificaat van de gebruiker aan. De status Onderbroken betekent dat Microsoft Entra-id heeft gevalideerd dat CBA is ingeschakeld in de tenant en dat er een certificaat wordt aangevraagd voor verificatie.

In de activiteitsgegevens ziet u dat dit slechts een deel uitmaakt van de verwachte aanmeldingsstroom waarin de gebruiker een certificaat selecteert.

In Aanvullende details worden de certificaatgegevens weergegeven.

Deze extra vermeldingen laten zien dat de verificatie is voltooid, dat een primair vernieuwingstoken wordt teruggestuurd naar de browser en dat de gebruiker toegang krijgt tot de resource.

Meervoudige verificatie testen

Voor het volgende testscenario configureert u het verificatiebeleid waarbij de policyOID-regel voldoet aan meervoudige verificatie.

Meld u aan bij het Microsoft Entra-beheercentrum met CBA. Omdat het beleid is ingesteld om te voldoen aan meervoudige verificatie, is de aanmelding van de gebruiker zonder een tweede factor geslaagd.

Zoek en selecteer aanmeldingen.

U ziet verschillende vermeldingen in de aanmeldingslogboeken, waaronder een vermelding met de status Onderbroken .

In de activiteitsgegevens ziet u dat dit slechts een deel uitmaakt van de verwachte aanmeldingsstroom waarin de gebruiker een certificaat selecteert.

Schermopname van gegevens over aanmelding met tweede factor in de aanmeldingslogboeken.

De vermelding met de status Onderbroken bevat meer diagnostische informatie op het tabblad Aanvullende details.

Schermopname van de details van de onderbroken poging in de aanmeldingslogboeken.

De volgende tabel bevat een beschrijving van elk veld.

Veld	Beschrijving
Onderwerpnaam van gebruikerscertificaat	Verwijst naar het veld onderwerpnaam in het certificaat.
Binding van gebruikerscertificaat	Certificaat: Principal Name; Gebruikerskenmerk: userPrincipalName; Rang: 1 Hier ziet u welk SAN PrincipalName-certificaatveld is toegewezen aan het gebruikerskenmerk userPrincipalName met prioriteit 1.
Verificatieniveau gebruikerscertificaat	multiFactorAuthentication
Type verificatieniveau gebruikerscertificaat	PolicyId Hier ziet u dat beleids-OID is gebruikt om de verificatiesterkte te bepalen.
Identificatie voor verificatieniveau op gebruikerscertificaat	1.2.3.4 Hier wordt de waarde van de id van de beleids-OID van het certificaat weergegeven.

Informatie over de verificatiefoutpagina op basis van certificaten

Verificatie op basis van certificaten kan mislukken om redenen zoals dat het certificaat ongeldig is, of de gebruiker het verkeerde certificaat of een verlopen certificaat heeft geselecteerd, of vanwege een certificaatintrekkingslijst (CRL). Wanneer certificaatvalidatie mislukt, ziet de gebruiker deze fout:

Schermopname van een certificaatvalidatiefout.

Als CBA mislukt in een browser, zelfs als de fout is omdat u de certificaatkiezer annuleert, moet u de browsersessie sluiten en een nieuwe sessie openen om CBA opnieuw te proberen. Er is een nieuwe sessie vereist omdat browsers het certificaat in de cache opslaan. Wanneer CBA opnieuw wordt geprobeerd, verzendt de browser het certificaat in de cache tijdens de TLS-uitdaging, waardoor aanmeldingsfouten en de validatiefout optreden.

Selecteer Meer informatie om logboekgegevens op te halen die kunnen worden verzonden naar een beheerder, die op zijn beurt meer informatie kan krijgen uit de aanmeldingslogboeken.

Schermopname van foutdetails.

Selecteer Andere manieren om u aan te melden om andere methoden te proberen die beschikbaar zijn voor de gebruiker om zich aan te melden.

Notitie

Als u CBA opnieuw probeert uit te voeren in een browser, blijft deze mislukken vanwege het probleem met de cache van de browser. Gebruikers moeten een nieuwe browsersessie openen en zich opnieuw aanmelden.

Schermopname van een nieuwe aanmeldingspoging.

Verificatie op basis van certificaten in MRU-methoden (MostRecentlyUsed)

Zodra een gebruiker is geverifieerd met CBA, wordt de verificatiemethode MostRecentlyUsed (MRU) van de gebruiker ingesteld op CBA. Wanneer de gebruiker de volgende keer de UPN invoert en Volgende selecteert, wordt de gebruiker rechtstreeks naar de CBA-methode gebracht en hoeft u het certificaat of de smartcard niet te selecteren.

Als u de MRU-methode opnieuw wilt instellen, moet de gebruiker de certificaatkiezer annuleren, andere manieren selecteren om u aan te melden en een andere methode selecteren die beschikbaar is voor de gebruiker en is geverifieerd.

Ondersteuning voor externe identiteiten

Een externe identiteit kan geen meervoudige verificatie uitvoeren voor de resourcetenant met Microsoft Entra CBA. Laat de gebruiker in plaats daarvan MFA uitvoeren met CBA in de basistenant en instellingen voor meerdere tenants instellen voor de resourcetenant om MFA van de thuistenant te vertrouwen.

Zie B2B-samenwerking tussen tenants configureren voor meerdere tenants voor meer informatie over het inschakelen van meervoudige verificatie van Vertrouwen vanuit Microsoft Entra-tenants.

Technische technische informatie over verificatie op basis van Microsoft Entra-certificaten

Hoe werkt verificatie op basis van Microsoft Entra-certificaten?

Verificatie op basis van certificaten is geschikt voor MFA

MFA met verificatie op basis van één factor certificaat (preview)

Informatie over het beleid inzake verificatiebinding

Sterke certificaten

Meervoudige certificaatverificatie

Hoe Microsoft Entra ID meerdere bindingsregels voor verificatiebeleid oplost

Informatie over het bindingsbeleid voor gebruikersnamen

Een hogere beveiliging realiseren met certificaatbindingen

Affiniteitsbinding definiëren op tenantniveau en overschrijven met aangepaste regels (preview)

Hoe Microsoft Entra ID meerdere bindingsregels voor gebruikersnaambeleid oplost

Microsoft Entra-configuratie beveiligen met meerdere gebruikersnaambindingen

Ondersteuning voor meerdere certificaten met één Entra-gebruikersaccount (M:1)

Ondersteuning voor één certificaat met meerdere Entra-gebruikersaccounts (1:M)

Informatie over het proces voor certificaatintrekking

Hoe kan ik het intrekken configureren?

Hoe CBA werkt met een beleid voor verificatie van voorwaardelijke toegang

CBA-verificatiesterkte met geavanceerde opties

Verificatie met één factor

Meervoudige verificatie testen

Informatie over de verificatiefoutpagina op basis van certificaten

Verificatie op basis van certificaten in MRU-methoden (MostRecentlyUsed)

Ondersteuning voor externe identiteiten

Volgende stappen

Aanvullende resources

Technische technische informatie over verificatie op basis van Microsoft Entra-certificaten

Hoe werkt verificatie op basis van Microsoft Entra-certificaten?

Verificatie op basis van certificaten is geschikt voor MFA

MFA met verificatie op basis van één factor certificaat (preview)

MFA-verificatiestroom met behulp van eenmalige certificaten en aanmelden zonder wachtwoord

Informatie over het beleid inzake verificatiebinding

Sterke certificaten

Meervoudige certificaatverificatie

Hoe Microsoft Entra ID meerdere bindingsregels voor verificatiebeleid oplost

Informatie over het bindingsbeleid voor gebruikersnamen

Een hogere beveiliging realiseren met certificaatbindingen

Affiniteitsbinding definiëren op tenantniveau en overschrijven met aangepaste regels (preview)

Hoe Microsoft Entra ID meerdere bindingsregels voor gebruikersnaambeleid oplost

Microsoft Entra-configuratie beveiligen met meerdere gebruikersnaambindingen

Ondersteuning voor meerdere certificaten met één Entra-gebruikersaccount (M:1)

Ondersteuning voor één certificaat met meerdere Entra-gebruikersaccounts (1:M)

Informatie over het proces voor certificaatintrekking

Hoe kan ik het intrekken configureren?

Hoe CBA werkt met een beleid voor verificatie van voorwaardelijke toegang

CBA-verificatiesterkte met geavanceerde opties

Aanmeldingslogboeken begrijpen

Aanmeldingsproblemen met dynamische variabelen in aanmeldingslogboeken oplossen

Verificatie met één factor

Meervoudige verificatie testen

Informatie over de verificatiefoutpagina op basis van certificaten

Verificatie op basis van certificaten in MRU-methoden (MostRecentlyUsed)

Ondersteuning voor externe identiteiten

Volgende stappen

Aanvullende resources