Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel worden technische concepten beschreven om uit te leggen hoe Verificatie op basis van certificaten (CBA) van Microsoft Entra werkt. Krijg de technische achtergrond om beter te weten hoe u Microsoft Entra CBA in uw tenant instelt en beheert.
Hoe werkt verificatie op basis van Microsoft Entra-certificaten?
In de volgende afbeelding ziet u wat er gebeurt wanneer een gebruiker zich probeert aan te melden bij een toepassing in een tenant waarvoor Microsoft Entra CBA is geconfigureerd.
De volgende stappen geven een overzicht van het Microsoft Entra CBA-proces:
Een gebruiker probeert toegang te krijgen tot een toepassing, zoals de MyApps-portal.
Als de gebruiker nog niet is aangemeld, wordt deze omgeleid naar de aanmeldingspagina van de Microsoft Entra ID-gebruiker op
https://login.microsoftonline.com/.Ze voeren hun gebruikersnaam in op de aanmeldingspagina van Microsoft Entra en selecteren vervolgens Volgende. Microsoft Entra ID voltooit detectie van thuisrealm met behulp van de naam van de tenant. Hierbij wordt de gebruikersnaam gebruikt om de gebruiker in de tenant op te zoeken.
Microsoft Entra-id controleert of CBA is ingesteld voor de tenant. Als CBA is ingesteld, 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 ingesteld voor de tenant.
Zie Hoe schakelen we Microsoft Entra CBA in voor meer informatie.
Notitie
Als CBA is ingesteld voor de tenant, zien alle gebruikers de koppeling Een certificaat of smartcard gebruiken op de aanmeldingspagina voor wachtwoorden. Alleen gebruikers die binnen het bereik van CBA vallen, kunnen zich echter verifiëren voor een toepassing die gebruikmaakt van Microsoft Entra-id als id-provider.
Als u andere verificatiemethoden beschikbaar maakt, zoals telefoon-aanmelding of beveiligingssleutels, zien uw gebruikers mogelijk een ander aanmeldingsdialoogvenster.
Nadat de gebruiker CBA heeft geselecteerd, wordt de client omgeleid naar het eindpunt voor certificaatverificatie. Voor openbare Microsoft Entra-id is
https://certauth.login.microsoftonline.comhet eindpunt voor certificaatverificatie. Voor Azure Government ishttps://certauth.login.microsoftonline.ushet eindpunt voor certificaatverificatie.Het eindpunt voert wederzijdse tls-verificatie (Transport Layer Security) uit en vraagt het clientcertificaat aan als onderdeel van de TLS-handshake. Er wordt een vermelding voor deze aanvraag weergegeven in het aanmeldingslogboek.
Notitie
Een beheerder moet toegang tot de aanmeldingspagina van de gebruiker en het
*.certauth.login.microsoftonline.comeindpunt voor certificaatverificatie voor uw cloudomgeving toestaan. Schakel TLS-inspectie uit op het eindpunt voor certificaatverificatie om ervoor te zorgen dat de aanvraag voor het clientcertificaat slaagt als onderdeel van de TLS-handshake.Zorg ervoor dat het uitschakelen van TLS-inspectie ook werkt voor hints voor verleners met de nieuwe URL. Codeer de URL niet met de tenant-id. De tenant-id kan veranderen voor B2B-gebruikers (business-to-business). Gebruik een reguliere expressie om zowel de vorige URL als de nieuwe URL te laten werken wanneer u TLS-inspectie uitschakelt. Bijvoorbeeld, afhankelijk van de proxy, gebruik
*.certauth.login.microsoftonline.comof*certauth.login.microsoftonline.com. Gebruik of*.certauth.login.microsoftonline.usin Azure Government*certauth.login.microsoftonline.us.Tenzij toegang is toegestaan, mislukt CBA als u hints voor verleners inschakelt.
Microsoft Entra ID vraagt een clientcertificaat aan. De gebruiker selecteert het clientcertificaat en selecteert vervolgens OK.
Microsoft Entra ID verifieert de certificaatintrekkingslijst (CRL) om ervoor te zorgen dat het certificaat niet is ingetrokken en dat het 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 via een Beleid voor voorwaardelijke toegang van Microsoft Entra waarvoor meervoudige verificatie (MFA) is vereist en de bindingsregel voor certificaatverificatie voldoet aan MFA, meldt Microsoft Entra ID zich onmiddellijk aan bij de gebruiker. Als MFA is vereist, maar het certificaat voldoet aan slechts één factor, worden aanmelding zonder wachtwoord en FIDO2 aangeboden als tweede factoren als de gebruiker al is 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 aanmelding van de gebruiker is geslaagd, heeft de gebruiker toegang tot de toepassing.
Hints voor verleners (preview)
Hints voor verleners verzenden een vertrouwde CA-indicator als onderdeel van de TLS-handshake. De lijst met vertrouwde CA's is ingesteld op het onderwerp van de CA's die de tenant uploadt naar het Vertrouwensarchief van Microsoft Entra. Een browserclient of systeemeigen toepassingsclient kan de hints gebruiken die de server terugstuurt om de certificaten te filteren die worden weergegeven in de certificaatkiezer. De client toont alleen de verificatiecertificaten die zijn uitgegeven door de CA's in het vertrouwensarchief.
Hints voor verlener inschakelen
Als u hints voor verleners wilt inschakelen, schakelt u het selectievakje Hints voor verleners in. Een verificatiebeleidsbeheerder moet ik Bevestigen selecteren nadat ik heb gecontroleerd of de proxy waarvoor TLS-inspectie is ingesteld, correct is bijgewerkt en sla de wijzigingen vervolgens op.
Notitie
Als uw organisatie firewalls of proxy's heeft die gebruikmaken van TLS-inspectie, bevestigt u dat u TLS-inspectie hebt uitgeschakeld van het CA-eindpunt dat geschikt is voor het aanpassen van elke naam onder [*.]certauth.login.microsoftonline.com, aangepast volgens de specifieke proxy die wordt gebruikt.
Notitie
Nadat u hints voor verleners hebt ingeschakeld, heeft de CA-URL de indeling <tenantId>.certauth.login.microsoftonline.com.
Updatedoorgifte van ca-vertrouwensarchief
Nadat u hints voor verleners hebt ingeschakeld en CA's hebt toegevoegd, bijgewerkt of verwijderd uit het vertrouwensarchief, kan een vertraging van maximaal 10 minuten optreden terwijl hints voor verleners weer worden doorgegeven aan de client. Een verificatiebeleidsbeheerder moet zich aanmelden met een certificaat nadat hints voor verleners beschikbaar zijn gesteld om doorgifte te initiëren.
Gebruikers kunnen niet verifiëren met behulp van certificaten die zijn uitgegeven door nieuwe CA's totdat hints worden doorgegeven. Gebruikers zien het volgende foutbericht wanneer updates voor het vertrouwensarchief van CA worden doorgegeven:
MFA met CBA met één factor
Microsoft Entra CBA komt in aanmerking voor zowel first-factor authentication als second-factor authentication.
Hier volgen enkele ondersteunde combinaties:
- CBA (eerste factor) en wachtwoordsleutels (tweede factor)
- CBA (eerste factor) en aanmelding zonder wachtwoord (tweede factor)
- CBA (eerste factor) en FIDO2-beveiligingssleutels (tweede factor)
- Wachtwoord (eerste factor) en CBA (tweede factor) (preview)
Notitie
Momenteel heeft het gebruik van CBA als tweede factor voor iOS bekende problemen en wordt geblokkeerd op iOS. We proberen de problemen op te lossen.
Gebruikers moeten een manier hebben om MFA op te halen en aanmelding zonder wachtwoord of FIDO2 te registreren voordat ze zich aanmelden met behulp van Microsoft Entra CBA.
Belangrijk
Een gebruiker wordt beschouwd als MFA die kan worden gebruikt als de gebruikersnaam wordt weergegeven in de CBA-methode-instellingen. In dit scenario kan de gebruiker zijn identiteit niet 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.
Opties voor het verkrijgen van MFA-functionaliteit met ingeschakelde CBA
Microsoft Entra CBA kan één factor of meerdere factoren zijn, afhankelijk van de tenantconfiguratie. Als u CBA inschakelt, kan een gebruiker MFA mogelijk voltooien. Een gebruiker met een enkel-factor certificaat of wachtwoord moet een andere factor gebruiken om MFA te voltooien.
We staan registratie van andere methoden niet toe zonder eerst aan MFA te voldoen. Als de gebruiker geen andere MFA-methode heeft geregistreerd en binnen het bereik van CBA valt, kan de gebruiker geen identiteitsbewijs gebruiken om andere verificatiemethoden te registreren en MFA op te halen.
Als de gebruiker die geschikt is voor CBA slechts één-factor-certificaat heeft en MFA moet voltooien, kiest u een van deze opties om de gebruiker te verifiëren:
- De gebruiker kan een wachtwoord invoeren en een certificaat met één factor gebruiken.
- Een verificatiebeleidsbeheerder kan een tijdelijke toegangspas uitgeven.
- Een verificatiebeleidsbeheerder kan een telefoonnummer toevoegen en spraak- of sms-berichtverificatie voor het gebruikersaccount toestaan.
Als de gebruiker die geschikt is voor CBA geen certificaat heeft uitgegeven en MFA moet voltooien, kiest u een van de volgende opties om de gebruiker te verifiëren:
- Een verificatiebeleidsbeheerder kan een tijdelijke toegangspas uitgeven.
- Een verificatiebeleidsbeheerder kan een telefoonnummer toevoegen en spraak- of sms-berichtverificatie voor het gebruikersaccount toestaan.
Als de gebruiker die geschikt is voor CBA geen meervoudig certificaat kan gebruiken, bijvoorbeeld als ze een mobiel apparaat zonder smartcardondersteuning gebruiken, maar ze MFA moeten voltooien, kiest u een van de volgende opties om de gebruiker te verifiëren:
- Een verificatiebeleidsbeheerder kan een tijdelijke toegangspas uitgeven.
- De gebruiker kan een andere MFA-methode registreren (wanneer de gebruiker een meervoudig certificaat op een apparaat kan gebruiken).
- Een verificatiebeleidsbeheerder kan een telefoonnummer toevoegen en spraak- of sms-berichtverificatie voor het gebruikersaccount toestaan.
Aanmelden zonder wachtwoord instellen met CBA
Als aanmelden zonder wachtwoord werkt, schakelt u eerst verouderde meldingen uit via een mobiele app voor de gebruiker.
Meld u aan bij het Microsoft Entra-beheercentrum als ten minste een verificatiebeleidsbeheerder.
Voer de stappen uit die worden beschreven in aanmeldingsverificatie zonder wachtwoord inschakelen.
Belangrijk
Zorg ervoor dat u de optie Wachtwoordloos selecteert. Voor groepen die u toevoegt aan aanmelding zonder wachtwoord, moet u de waarde voor de verificatiemodus wijzigen in Wachtwoordloos. Als u Any selecteert, werken CBA en aanmelden zonder wachtwoord niet.
Selecteer Entra ID>Meervoudige verificatie>Aanvullende instellingen voor meervoudige verificatie in de cloud.
Schakel onder Verificatieopties het selectievakje Melding via mobiele app uit en selecteer Opslaan.
MFA-verificatiestroom met behulp van eenmalige certificaten en aanmelding zonder wachtwoord
Bekijk een voorbeeld van een gebruiker die een enkelvoudig certificaat heeft en is geconfigureerd voor aanmelding zonder wachtwoord. Als gebruiker voert u de volgende stappen uit:
Voer uw UPN (User Principal Name) in en selecteer Vervolgens.
Selecteer Een certificaat of smartcard gebruiken.
Als u andere verificatiemethoden beschikbaar maakt, zoals telefoon-aanmelding of beveiligingssleutels, zien uw gebruikers mogelijk een ander aanmeldingsdialoogvenster.
Selecteer in de clientcertificaatkiezer het juiste gebruikerscertificaat en selecteer VERVOLGENS OK.
Omdat het certificaat is geconfigureerd als de sterkte van verificatie met één factor, hebt u een tweede factor nodig om te voldoen aan de MFA-vereisten. Beschikbare tweede factoren worden weergegeven in het aanmeldingsdialoogvenster. In dit geval is het aanmelden zonder wachtwoord. Selecteer Een aanvraag goedkeuren in mijn Microsoft Authenticator-app.
U ontvangt een melding op uw telefoon. Selecteer Aanmelden goedkeuren?.
Voer in Microsoft Authenticator het nummer in dat u in de browser of app ziet.
Selecteer Ja en u kunt zich verifiëren en aanmelden.
Beleid voor verificatiebinding
Het verificatiebindingsbeleid helpt bij het instellen van de sterkte van verificatie als één factor of meervoudige verificatie. Een verificatiebeleidsbeheerder kan de standaardmethode wijzigen van één factor in multifactor. Een beheerder kan ook aangepaste beleidsconfiguraties instellen met behulp van IssuerAndSubject, PolicyOIDof IssuerPolicyOID in het certificaat.
Certificaatsterkte
Beheerders van verificatiebeleid kunnen bepalen of de sterkte van het certificaat één factor of meerdere factoren is. Zie voor meer informatie de documentatie die NIST Authentication Assurance Levels in kaart brengt met Microsoft Entra-authenticatiemethoden, die voortbouwt op NIST 800-63B SP 800-63B, Richtlijnen voor digitale identiteit: authenticatie en levenscyclusbeheer.
Meervoudige certificaatverificatie
Wanneer een gebruiker een meervoudig certificaat heeft, kan deze alleen MFA uitvoeren met behulp van certificaten. Een verificatiebeleidsbeheerder moet er echter voor zorgen dat de certificaten worden beveiligd door een pincode of biometrische gegevens die als multifactor worden beschouwd.
Bindingsregels voor meerdere verificatiebeleidsregels
U kunt meerdere regels voor aangepaste verificatiebindingsbeleid maken met behulp van verschillende certificaatkenmerken. Een voorbeeld is het gebruik van de verlener en de beleids-OID, of alleen de beleids-OID of alleen de verlener.
De volgende reeks bepaalt het verificatiebeveiligingsniveau wanneer aangepaste regels elkaar overlappen:
- Verlener- en beleids-OID-regels hebben voorrang op beleids-OID-regels. Beleids-OID-regels hebben voorrang op regels voor certificaatverleners.
- Verlener- en beleids-OID-regels worden eerst geëvalueerd. Als u een aangepaste regel hebt met verlener CA1 en beleids-OID
1.2.3.4.5met MFA, krijgt alleen certificaat A die voldoet aan zowel de waarde van de verlener als de beleids-OID MFA. - Aangepaste regels die gebruikmaken van beleids-OID's worden geëvalueerd. Als u een certificaat A met beleids-OID van en een afgeleide referentie B hebt op basis van
1.2.3.4.5dat certificaat met een beleids-OID van1.2.3.4.5.6en de aangepaste regel wordt gedefinieerd als een beleids-OID die de waarde1.2.3.4.5met MFA heeft, voldoet alleen certificaat A aan MFA. Referentie B voldoet alleen aan eenmalige verificatie. Als de gebruiker tijdens het aanmelden een afgeleide referentie heeft gebruikt en is geconfigureerd voor MFA, 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 een binding met één factor-verificatie en de andere bindingen met MFA) heeft, behandelt u het certificaat als verificatie met één factor.
- Aangepaste regels die gebruikmaken van ca's voor verleners worden geëvalueerd. Als een certificaat overeenkomende beleids-OID- en verlenerregels heeft, wordt de beleids-OID altijd eerst gecontroleerd. Als er geen beleidsregel wordt gevonden, worden de bindingen van de verlener gecontroleerd. De beleids-OID heeft een hogere prioriteit voor binding met sterke verificatie 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 gebruikerscertificaten met deze beleids-OID als een van de OID's in aanmerking als MFA. (Een gebruikerscertificaat kan meerdere beleids-OID's hebben.)
- Eén certificaatverlener kan slechts één geldige binding voor sterke verificatie hebben (een certificaat kan dus niet worden gebonden aan zowel enkele verificatie als aan MFA).
Belangrijk
Op dit moment, in een bekend probleem dat wordt opgelost, als een verificatiebeleidsbeheerder een CBA-beleidsregel maakt met behulp van zowel de verlener als de beleids-OID, worden sommige scenario's voor apparaatregistratie beïnvloed.
De betrokken scenario's zijn onder andere:
- Windows Hello voor Bedrijven-inschrijving
- REGISTRATIE van FIDO2-beveiligingssleutels
- Aanmelden bij Windows-telefoon zonder wachtwoord
Apparaatregistratie met workplace join-, Microsoft Entra-id- en hybride scenario's van Microsoft Entra wordt niet beïnvloed. CBA-beleidsregels die gebruikmaken van de verlener of de beleids-OID, worden niet beïnvloed.
Om het probleem te verhelpen, moet een verificatiebeleidsbeheerder een van de volgende opties voltooien:
- Bewerk de CBA-beleidsregel die momenteel zowel de verlener als de beleids-OID gebruikt om de verlener of de vereiste van de beleids-id te verwijderen.
- Verwijder de verificatiebeleidsregel die momenteel zowel de verlener als de beleids-OID gebruikt en maak vervolgens een regel die alleen gebruikmaakt van de verlener of de beleids-OID.
Bindingsbeleid voor gebruikersnaam
Het bindingsbeleid voor gebruikersnaam helpt het certificaat van de gebruiker te valideren. Standaard wordt de alternatieve naam van het onderwerp (SAN) Principal Name in het certificaat toegewezen aan het userPrincipalName kenmerk van het gebruikersobject om de gebruiker te identificeren.
Hogere beveiliging bereiken met behulp van certificaatbindingen
Microsoft Entra ondersteunt zeven methoden voor het gebruik van certificaatbindingen. Over het algemeen worden toewijzingstypen beschouwd als hoge affiniteit als ze zijn gebaseerd op id's die u niet opnieuw kunt gebruiken, zoals SubjectKeyIdentifier (SKI) of SHA1PublicKey. Deze id's geven een hogere zekerheid dat slechts één certificaat kan worden gebruikt om een 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 | Typologie |
|---|---|---|---|
PrincipalName |
X509:<PN>bob@woodgrove.com |
userPrincipalName onPremisesUserPrincipalName certificateUserIds |
Lage affiniteit |
RFC822Name |
X509:<RFC822>user@woodgrove.com |
userPrincipalName onPremisesUserPrincipalName certificateUserIds |
Lage affiniteit |
IssuerAndSubject |
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest |
certificateUserIds |
Lage affiniteit |
Subject |
X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest |
certificateUserIds |
Lage affiniteit |
SKI |
X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= |
certificateUserIds |
Hoge affiniteit |
SHA1PublicKey |
X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR De SHA1PublicKey waarde (SHA1-hash van de volledige certificaatinhoud, inclusief de openbare sleutel) bevindt zich in de vingerafdrukeigenschap van het certificaat. |
certificateUserIds |
Hoge affiniteit |
IssuerAndSerialNumber |
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT Als u de juiste waarde voor het 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 |
Belangrijk
U kunt de CertificateBasedAuthentication PowerShell-module gebruiken om de juiste certificateUserIds waarde voor een gebruiker in een certificaat te vinden.
Affiniteitsbinding definiëren en negeren
Een verificatiebeleidsbeheerder kan configureren of gebruikers kunnen verifiëren met behulp van bindingstoewijzing met een lage affiniteit of een hoge affiniteit.
Stel vereiste affiniteitsbinding in voor de tenant, die van toepassing is op alle gebruikers. Als u de standaardwaarde voor de hele tenant wilt overschrijven, maakt u aangepaste regels op basis van de verlener en de beleids-OID, of alleen de beleids-OID of alleen de verlener.
Meerdere bindingsregels voor gebruikersnaambeleid
Als u meerdere regels voor het verbinden van gebruikersnaambeleid wilt oplossen, gebruikt Microsoft Entra ID de binding met de hoogste prioriteit (laagste getal):
- Hiermee wordt het gebruikersobject opgezoekt met behulp van de gebruikersnaam of UPN.
- Hiermee haalt u de lijst op met alle gebruikersnaambindingen die zijn ingesteld door de verificatiebeleidsbeheerder in de CBA-methodeconfiguratie die door het
prioritykenmerk is gerangschikt. Op dit moment wordt prioriteit niet weergegeven in het beheercentrum. Microsoft Graph retourneert hetprioritykenmerk voor elke binding. Vervolgens worden prioriteiten gebruikt in het evaluatieproces. - Als voor de tenant een binding met hoge affiniteit is geconfigureerd of als de certificaatwaarde overeenkomt met een aangepaste regel waarvoor een binding met hoge affiniteit is vereist, verwijdert u alle bindingen met lage affiniteit uit de lijst.
- Evalueert 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.
- Als er een overeenkomst wordt gevonden, is gebruikersverificatie geslaagd.
- Als er geen overeenkomst wordt gevonden, gaat u naar de volgende prioriteitsbinding.
- Als het X.509-certificaatveld zich niet op het gepresenteerde certificaat bevindt, gaat u naar de volgende prioriteitsbinding.
- Valideert 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 behulp van meerdere gebruikersnaambindingen
Elk van de gebruikersobjectkenmerken van Microsoft Entra die beschikbaar zijn voor het binden van certificaten aan Microsoft Entra-gebruikersaccounts (userPrincipalNameonPremiseUserPrincipalName, en certificateUserIds) 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 beleid voor gebruikersnaambinding. Een verificatiebeleidsbeheerder kan geschikt zijn voor één certificaat dat wordt gebruikt in meerdere configuraties van Microsoft Entra-gebruikersaccounts.
Belangrijk
Als u meerdere bindingen configureert, is Microsoft Entra CBA-verificatie alleen zo veilig als uw binding met laagste affiniteit, 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 verificatiebeleidsbeheerder het volgende doen:
- 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 een verificatiebeleidsbeheerder ervoor zorgen dat alle toegestane methoden die in de beleidstoewijzing zijn geconfigureerd, aan hetzelfde Microsoft Entra-account zijn geconfigureerd. Alle gebruikersaccounts moeten waarden hebben die overeenkomen met alle bindingen.
- Als een tenant meerdere bindingsmethoden heeft geconfigureerd, moet een verificatiebeleidsbeheerder ervoor zorgen dat ze niet meer dan één binding met lage affiniteit hebben.
U hebt bijvoorbeeld twee gebruikersnaambindingen die PrincipalName zijn toegewezen aan UPN, en SubjectKeyIdentifier (SKI) is toegewezen aan certificateUserIds. Als u een certificaat wilt gebruiken voor slechts één account, moet een verificatiebeleidsbeheerder ervoor zorgen dat het account de UPN heeft die aanwezig is in het certificaat. Vervolgens implementeert de beheerder de SKI toewijzing in het certificateUserIds kenmerk van hetzelfde account.
Ondersteuning voor meerdere certificaten met één Microsoft Entra-gebruikersaccount (M:1)
In sommige scenario's geeft een organisatie meerdere certificaten voor één identiteit uit. Het kan een afgeleide referentie voor een mobiel apparaat zijn, maar het kan ook zijn voor een secundaire smartcard of X.509-referentiehouder, zoals een YubiKey.
Cloudaccounts (M:1)
Voor cloudaccounts kunt u maximaal vijf certificaten toewijzen die moeten worden gebruikt door het certificateUserIds veld te vullen met unieke waarden om elk certificaat te identificeren. Als u de certificaten wilt toewijzen, gaat u in het beheercentrum naar het tabblad Autorisatiegegevens .
Als de organisatie gebruikmaakt van bindingen met hoge affiniteit, IssuerAndSerialNumberkunnen waarden in certificateUserIds het volgende voorbeeld er als volgt uitzien:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV
In dit voorbeeld vertegenwoordigt de eerste waarde X509Certificate1. De tweede waarde vertegenwoordigt X509Certificate2. De gebruiker kan een van beide certificaten presenteren bij het aanmelden. Als de CBA-gebruikersnaambinding is ingesteld om naar het certificateUserIds veld te verwijzen om te zoeken naar het specifieke bindingstype (in dit voorbeeld IssuerAndSerialNumber), meldt de gebruiker zich aan.
Hybride gesynchroniseerde accounts (M:1)
Voor gesynchroniseerde accounts kunt u meerdere certificaten toewijzen. Vul in on-premises Active Directory het altSecurityIdentities veld in met de waarden die elk certificaat identificeren. Als uw organisatie gebruikmaakt van bindingen met hoge affiniteit (dat wil gezegd sterke verificatie), IssuerAndSerialNumberkunnen de waarden er als volgt uitzien:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV
In dit voorbeeld vertegenwoordigt de eerste waarde X509Certificate1. De tweede waarde vertegenwoordigt X509Certificate2. De waarden moeten vervolgens worden gesynchroniseerd met het certificateUserIds veld in Microsoft Entra ID.
Ondersteuning voor één certificaat met meerdere Microsoft Entra-gebruikersaccounts (1:M)
In sommige scenario's vereist een organisatie dat een gebruiker hetzelfde certificaat gebruikt om zich te verifiëren bij meerdere identiteiten. Het kan zijn voor een administratief account of voor een ontwikkelaars- of tijdelijk dienstaccount.
In on-premises Active Directory worden de certificaatwaarden ingevuld in het altSecurityIdentities veld. Er wordt een hint gebruikt tijdens het aanmelden om Active Directory naar het beoogde account te leiden om te controleren op aanmelding.
Microsoft Entra CBA heeft een ander proces en er is geen hint opgenomen. In plaats daarvan identificeert detectie van thuisrealm het beoogde account en controleert u de certificaatwaarden. Microsoft Entra CBA dwingt ook uniekheid in het certificateUserIds veld af. Twee accounts kunnen niet dezelfde certificaatwaarden invullen.
Belangrijk
Het gebruik van dezelfde referenties voor verificatie bij verschillende Microsoft Entra-accounts is geen veilige configuratie. Het is raadzaam om niet toe te staan dat één certificaat wordt gebruikt voor meerdere Microsoft Entra-gebruikersaccounts.
Alleen cloudaccounts (1:M)
Voor cloudaccounts maakt u meerdere gebruikersnaambindingen en wijst u unieke waarden toe aan elk gebruikersaccount dat gebruikmaakt van het certificaat. Toegang tot elk account wordt geverifieerd met behulp van een andere gebruikersnaambinding. Dit verificatieniveau is van toepassing op de grens van één map of tenant. Een verificatiebeleidsbeheerder kan het certificaat toewijzen aan gebruik in een andere map of tenant als de waarden uniek blijven per account.
Vul het certificateUserIds veld in met een unieke waarde die het certificaat identificeert. Als u het veld wilt vullen, gaat u in het beheercentrum naar het tabblad Autorisatiegegevens .
Als de organisatie gebruikmaakt van bindingen met hoge affiniteit (dat wil gezegd sterke verificatie) zoals IssuerAndSerialNumber en SKI, kunnen de waarden eruitzien zoals in het volgende voorbeeld:
Gebruikersnaambindingen:
IssuerAndSerialNumber>certificateUserIdsSKI>certificateUserIds
Waarden voor gebruikersaccounts certificateUserIds :
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
Wanneer een van beide gebruikers nu hetzelfde certificaat bij het aanmelden presenteert, meldt de gebruiker zich aan omdat het account overeenkomt met een unieke waarde op dat certificaat. Het ene account wordt geverifieerd met behulp van IssuerAndSerialNumber 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 bindingen met hoge affiniteit gebruikt, is het maximum aantal ondersteunde accounts drie. Als de organisatie ook bindingen met lage affiniteit gebruikt, neemt het aantal toe tot zeven accounts: één, éénPrincipalName, éénRFC822NameSKI, éénSHA1PublicKey, één, één IssuerAndSubjecten éénIssuerAndSerialNumber.Subject
Hybride gesynchroniseerde accounts (1:M)
Voor gesynchroniseerde accounts is een andere benadering vereist. Hoewel een verificatiebeleidsbeheerder unieke waarden kan toewijzen aan elk gebruikersaccount dat gebruikmaakt van het certificaat, is het gebruikelijk dat alle waarden worden gevuld met elk account in Microsoft Entra ID, maakt deze benadering moeilijk. In plaats daarvan moet Microsoft Entra Connect de waarden per account filteren op unieke waarden die zijn ingevuld in het account in Microsoft Entra-id. De uniekheidsregel is van toepassing op de grens van één map of tenant. Een verificatiebeleidsbeheerder kan het certificaat toewijzen aan gebruik in een andere map of tenant als de waarden uniek blijven per account.
De organisatie kan ook meerdere Active Directory-forests hebben die gebruikers bijdragen aan één Microsoft Entra-tenant. In dit geval past Microsoft Entra Connect het filter toe op elk van de Active Directory-forests met hetzelfde doel: vul alleen een specifieke, unieke waarde in voor het cloudaccount.
Vul het altSecurityIdentities veld in Active Directory in met de waarden waarmee het certificaat wordt geïdentificeerd. Geef de specifieke certificaatwaarde op voor dat gebruikersaccounttype (zoals detailed, adminof developer). Selecteer een sleutelkenmerk in Active Directory. Het kenmerk geeft aan welk gebruikersaccounttype de gebruiker evalueert (zoals msDS-cloudExtensionAttribute1). Vul dit kenmerk in met de waarde van het gebruikerstype dat u wilt gebruiken, zoals detailed, adminof developer. Als het account het primaire account van de gebruiker is, kan de waarde leeg of NULL zijn.
Controleer of de accounts er ongeveer als volgt uitzien:
Forest 1: Account1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com
Forest 1: Account2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com
Forest 2: ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com
Vervolgens moet u deze waarden synchroniseren met het certificateUserIds veld in Microsoft Entra ID.
Synchroniseren met certificateUserIds:
- Configureer Microsoft Entra Connect om het
alternativeSecurityIdsveld toe te voegen aan de metaverse. - Configureer voor elk on-premises Active Directory-forest een nieuwe aangepaste regel voor inkomend verkeer met een hoge prioriteit (een laag getal, lager dan 100). Voeg een
Expressiontransformatie toe met hetaltSecurityIdentitiesveld als bron. De doelexpressie maakt gebruik van het sleutelkenmerk dat u hebt geselecteerd en ingevuld en maakt gebruik van 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 dit voorbeeld altSecurityIdentities wordt het sleutelkenmerk msDS-cloudExtensionAttribute1 eerst gecontroleerd om te zien of ze zijn ingevuld. Als ze niet zijn ingevuld, altSecurityIdentities wordt gecontroleerd of deze zijn ingevuld. Als deze leeg is, stelt u deze in op NULL. Anders is het account een standaardscenario.
In dit voorbeeld filtert u ook alleen op de IssuerAndSerialNumber toewijzing. Als het sleutelkenmerk is ingevuld, wordt de waarde gecontroleerd om te zien of deze gelijk is aan een van uw gedefinieerde gebruikerstypen. In het voorbeeld, als die waarde is detailed, filtert u op de SHA1PublicKey waarde uit altSecurityIdentities. Als de waarde is developer, filtert u op de SubjectKeyIssuer waarde van altSecurityIdentities.
U kunt meerdere certificaatwaarden van een specifiek type tegenkomen. U ziet bijvoorbeeld meerdere PrincipalName waarden of meerdere SKI waarden of SHA1-PUKEY waarden. Met het filter worden alle waarden opgehaald en gesynchroniseerd in Microsoft Entra-id, niet alleen de eerste die wordt gevonden.
Hier volgt een tweede voorbeeld waarin wordt getoond hoe u een lege waarde pusht als het besturingselementkenmerk leeg is:
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 altSecurityIdentities niet overeenkomt met een van de zoekwaarden in het besturingselementkenmerk, wordt een AuthoritativeNull waarde doorgegeven. Deze waarde zorgt ervoor dat eerdere of volgende regels die worden ingevuld alternativeSecurityId , worden genegeerd. Het resultaat is leeg in Microsoft Entra-id.
Een lege waarde synchroniseren:
- Configureer een nieuwe aangepaste uitgaande regel met een lage prioriteit (een hoog getal, boven 160, maar onderaan de lijst).
- Voeg een directe transformatie toe met het
alternativeSecurityIdsveld als de bron en hetcertificateUserIdsveld als doel. - Voer een synchronisatiecyclus uit om de gegevenspopulatie in Microsoft Entra-id te voltooien.
Zorg ervoor dat CBA in elke tenant is geconfigureerd met de gebruikersnaambindingen die verwijzen naar het certificateUserIds veld voor de veldtypen die u hebt toegewezen vanuit het certificaat. Nu kunnen al deze gebruikers het certificaat presenteren bij de aanmelding. Nadat de unieke waarde van het certificaat is gevalideerd op basis van het certificateUserIds veld, wordt de gebruiker aangemeld.
Bereik van certificeringsinstantie (CA) (preview)
Met ca-bereik in Microsoft Entra kunnen tenantbeheerders het gebruik van specifieke CA's beperken tot gedefinieerde gebruikersgroepen. Deze functie verbetert de beveiliging en beheerbaarheid van CBA door ervoor te zorgen dat alleen geautoriseerde gebruikers zich kunnen verifiëren met behulp van certificaten die zijn uitgegeven door specifieke CA's.
Ca-bereik is handig in multi-PKI- of B2B-scenario's waarbij meerdere CA's worden gebruikt in verschillende gebruikerspopulaties. Het helpt onbedoelde toegang te voorkomen en ondersteunt naleving van organisatiebeleid.
Belangrijkste voordelen
- Hiermee beperkt u het gebruik van certificaten tot specifieke gebruikersgroepen
- Ondersteunt complexe PKI-omgevingen via meerdere CA's
- Biedt verbeterde bescherming tegen misbruik van certificaten of inbreuk
- Geeft inzicht in ca-gebruik via aanmeldingslogboeken en bewakingshulpprogramma's
Een beheerder kan ca-bereik gebruiken om regels te definiëren die een CA (geïdentificeerd door de SKI) aan een specifieke Microsoft Entra-groep koppelen. Wanneer een gebruiker probeert te verifiëren met behulp van een certificaat, controleert het systeem of de verlenende CA voor het certificaat is afgestemd op een groep die de gebruiker bevat. Microsoft Entra gaat verder met de CA-keten. Alle bereikregels worden toegepast totdat de gebruiker zich in een van de groepen in alle bereikregels bevindt. Als de gebruiker zich niet in de bereikgroep bevindt, mislukt de verificatie, zelfs als het certificaat anders geldig is.
De ca-bereikfunctie instellen
Meld u aan bij het Microsoft Entra-beheercentrum als ten minste een verificatiebeleidsbeheerder.
Ga naarVerificatiemethoden opbasis van certificaten > naar Entra>.
Ga onder Configureren naar het bereikbeleid van certificaatverleners.
Selecteer Regel toevoegen.
Selecteer CA's filteren op PKI.
Klassieke CA's bevatten alle CA's uit het klassieke CA-archief. Als u een specifieke PKI selecteert, worden alle CA's uit de geselecteerde PKI weergegeven.
Selecteer een PKI.
In de lijst met certificaatverleners worden alle CA's uit de geselecteerde PKI weergegeven. Selecteer een CA om een bereikregel te maken.
Selecteer Groep toevoegen.
Selecteer een groep.
Selecteer Toevoegen om de regel op te slaan.
Schakel het selectievakje I Acknowledge in en selecteer Opslaan.
Als u een ca-bereikbeleid wilt bewerken of verwijderen, selecteert u '...' in de regelrij. Als u de regel wilt bewerken, selecteert u Bewerken. Als u de regel wilt verwijderen, selecteert u Verwijderen.
Bekende beperkingen
- Er kan slechts één groep per CA worden toegewezen.
- Er worden maximaal 30 bereikregels ondersteund.
- Het bereik wordt afgedwongen op tussenliggend CA-niveau.
- Onjuiste configuratie kan leiden tot gebruikersvergrendelingen als er geen geldige bereikregels bestaan.
Aanmeldingslogboekvermeldingen
In het aanmeldingslogboek wordt een geslaagde aanmelding weergegeven. Op het tabblad Aanvullende details wordt de SKI van de CA uit de bereikbeleidsregel weergegeven.
Wanneer een CBA mislukt vanwege een ca-bereikregel, wordt op het tabblad Basisgegevens in het aanmeldingslogboek de foutcode 500189 weergegeven.
Eindgebruikers zien het volgende foutbericht:
Hoe CBA werkt met een beleid voor verificatie van voorwaardelijke toegang
U kunt de ingebouwde MFA-verificatiesterkte van Microsoft Entra Phishing gebruiken om een verificatiebeleid voor voorwaardelijke toegang te maken dat aangeeft dat CBA moet worden gebruikt voor toegang tot een resource. Het 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 verificatie met één factor, MFA of beide. Zie de sterkte van voorwaardelijke toegangsverificatie voor meer informatie.
CBA-sterkte met geavanceerde opties
In het CBA-methodebeleid kan een verificatiebeleidsbeheerder de sterkte van het certificaat bepalen met behulp van een verificatiebindingsbeleid voor de CBA-methode. U kunt nu 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. Wanneer u een aangepaste verificatiesterkte maakt, gaat u naar Geavanceerde opties. De 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
Aanmeldingslogboeken bevatten informatie over aanmeldingen en hoe uw resources worden gebruikt in de organisatie. Zie Aanmeldingslogboeken in Microsoft Entra ID voor meer informatie.
Overweeg vervolgens twee scenario's. In één scenario voldoet het certificaat aan eenmalige verificatie. In het tweede scenario voldoet het certificaat aan MFA.
Selecteer voor de testscenario's een gebruiker die een beleid voor voorwaardelijke toegang heeft waarvoor MFA is vereist.
Configureer het beleid voor gebruikersbinding door alternatieve onderwerpnaam en principal-naam toe te wijsen aan het userPrincipalName gebruikersobject.
Het gebruikerscertificaat moet worden geconfigureerd zoals in het voorbeeld in deze schermopname:
Aanmeldingsproblemen met dynamische variabelen in aanmeldingslogboeken oplossen
Hoewel aanmeldingslogboeken doorgaans alle informatie bevatten die u nodig hebt om fouten op te sporen in een aanmeldingsprobleem, zijn soms specifieke waarden vereist. Aanmeldingslogboeken bieden geen ondersteuning voor dynamische variabelen, dus in sommige gevallen bevatten de aanmeldingslogboeken niet de informatie die u nodig hebt voor foutopsporing.
De foutreden in de aanmeldingslogboeken kan bijvoorbeeld in dit scenario"The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." worden weergegeven <expectedSKI> en <crlAKI> worden niet gevuld met de juiste waarden.
Wanneer het aanmelden van gebruikers met CBA mislukt, kunt u de logboekgegevens kopiëren via 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 IssuerAndSubject regel 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
IssuerAndSubjectregel voldoet aan verificatie met één factor.Zoek en selecteer vervolgens aanmeldingslogboeken.
In de volgende afbeelding ziet u een aantal vermeldingen die u kunt vinden in de aanmeldingslogboeken.
De eerste vermelding vraagt het X.509-certificaat van de gebruiker aan. De onderbroken status betekent dat microsoft Entra-id heeft gevalideerd dat CBA is ingesteld voor de tenant. Er wordt een certificaat aangevraagd voor verificatie.
Activiteitsgegevens laten zien dat de aanvraag deel uitmaakt van de verwachte aanmeldingsstroom waarin de gebruiker een certificaat selecteert.
Aanvullende informatie geeft de certificaatgegevens weer.
De andere vermeldingen geven aan dat de verificatie is voltooid, dat er een primair vernieuwingstoken naar de browser wordt verzonden en dat de gebruiker toegang krijgt tot de resource.
MFA testen
Voor het volgende testscenario configureert u het verificatiebeleid waarbij de policyOID regel voldoet aan MFA.
Meld u aan bij het Microsoft Entra-beheercentrum met behulp van CBA. Omdat het beleid is ingesteld om aan MFA te voldoen, is de aanmelding van de gebruiker zonder een tweede factor geslaagd.
Zoek en selecteer vervolgens Aanmeldingen.
Er worden verschillende vermeldingen in de aanmeldingslogboeken weergegeven, waaronder een vermelding met de status Onderbroken .
Activiteitsgegevens laten zien dat de aanvraag deel uitmaakt van de verwachte aanmeldingsstroom waarin de gebruiker een certificaat selecteert.
De vermelding met de onderbroken status geeft meer diagnostische informatie weer op het tabblad Aanvullende details .
De volgende tabel bevat een beschrijving van elk veld.
Veld Beschrijving Onderwerpnaam van gebruikerscertificaat Verwijst naar het veld onderwerpnaam in het certificaat. Binding van gebruikerscertificaten Certificaat: PrincipalName; gebruikerskenmerk:userPrincipalName; Rangschikking: 1
In dit veld ziet u welk SAN-certificaatveldPrincipalNameis toegewezen aan hetuserPrincipalNamegebruikerskenmerk en prioriteit 1 was.Verificatieniveau van gebruikerscertificaat multiFactorAuthenticationType verificatieniveau van gebruikerscertificaat PolicyId
In dit veld ziet u dat de beleids-OID is gebruikt om de verificatiesterkte te bepalen.Id op verificatieniveau van gebruikerscertificaat 1.2.3.4
Hier wordt de waarde van de id van de beleids-OID van het certificaat weergegeven.
CBA-foutpagina
CBA kan om meerdere redenen mislukken. Voorbeelden zijn een ongeldig certificaat, de gebruiker heeft het verkeerde certificaat of een verlopen certificaat geselecteerd, of er treedt een CRL-probleem op. Wanneer certificaatvalidatie mislukt, ziet de gebruiker dit foutbericht:
Als CBA mislukt in een browser, zelfs als de fout is omdat u de certificaatkiezer annuleert, sluit u de browsersessie. Open een nieuwe sessie om CBA opnieuw te proberen. Er is een nieuwe sessie vereist omdat browsers certificaten cachen. Wanneer CBA opnieuw wordt geprobeerd, verzendt de browser een certificaat in de cache tijdens de TLS-uitdaging, waardoor aanmeldingsfouten en de validatiefout optreden.
Als u logboekgegevens wilt ophalen om naar een verificatiebeleidsbeheerder te verzenden voor meer informatie in de aanmeldingslogboeken, selecteert u Meer informatie.
Selecteer Andere manieren om u aan te melden en probeer andere beschikbare verificatiemethoden om u aan te melden.
De certificaatkeuze opnieuw instellen in Microsoft Edge
De Microsoft Edge-browser heeft een functie toegevoegd waarmee de certificaatselectie opnieuw wordt ingesteld zonder de browser opnieuw op te starten.
De gebruiker voert de volgende stappen uit:
Wanneer CBA mislukt, wordt de foutpagina weergegeven.
Selecteer links van de adres-URL het vergrendelingspictogram en selecteer vervolgens Uw certificaatkeuzes.
Selecteer Certificaatopties opnieuw instellen.
Selecteer Opties voor opnieuw instellen.
Selecteer Andere manieren om u aan te melden.
Selecteer Een certificaat of smartcard gebruiken en doorgaan met CBA-verificatie.
CBA in MostRecentlyUsed-methoden
Nadat een gebruiker is geverifieerd met CBA, wordt de verificatiemethode (MRU) van de gebruiker MostRecentlyUsed ingesteld op CBA. De volgende keer dat de gebruiker de UPN invoert en Volgende selecteert, zien ze de CBA-methode en hoeven ze het certificaat of de smartcard niet te selecteren.
Als u de MRU-methode opnieuw wilt instellen, annuleert u de certificaatkiezer en selecteert u andere manieren om u aan te melden. Selecteer een andere beschikbare methode en voltooi vervolgens de verificatie.
De MRU-verificatiemethode wordt ingesteld op gebruikersniveau. Als een gebruiker zich heeft aangemeld op een ander apparaat met behulp van een andere verificatiemethode, wordt de MRU opnieuw ingesteld voor de gebruiker op de momenteel aangemelde methode.
Ondersteuning voor externe identiteiten
Een externe identiteit B2B-gastgebruiker kan CBA op de thuistenant gebruiken. Als de instellingen voor meerdere tenants voor de resourcetenant zijn ingesteld om MFA van de thuistenant te vertrouwen, wordt de CBA van de gebruiker op de basistenant gehonoreerd. Zie B2B-samenwerking tussen tenants configureren voor meer informatie. Op dit moment wordt CBA voor een resourcetenant niet ondersteund.
Verwante inhoud
- Overzicht van Microsoft Entra CBA
- Microsoft Entra CBA instellen
- Microsoft Entra CBA-certificaatintrekkingslijst
- Microsoft Entra CBA op iOS-apparaten
- Microsoft Entra CBA op Android-apparaten
- Aanmelden met Windows-smartcard met behulp van Microsoft Entra CBA
- Certificaat gebruikers-ID's
- Federatieve gebruikers migreren
- Veelgestelde vragen
- Problemen met Microsoft Entra CBA oplossen