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

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.

Nu doorlopen we elke stap:

1. De gebruiker probeert toegang te krijgen tot een toepassing, zoals MyApps-portal.

2. Als de gebruiker nog niet is aangemeld, wordt de gebruiker omgeleid naar de aanmeldingspagina van Microsoft Entra ID-gebruiker op https://login.microsoftonline.com/.

3. 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.

   

4. 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.

   

5. 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 Microsoft 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 hints voor verleners inschakelt.

6. Microsoft Entra ID vraagt een clientcertificaat aan. De gebruiker kiest het clientcertificaat en selecteert OK.

   

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

8. 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.

9. Microsoft Entra ID voltooit het aanmeldingsproces door een primair vernieuwingstoken terug te sturen om aan te geven dat de aanmelding is geslaagd.

10. Als de gebruiker zich met succes heeft aangemeld, heeft deze toegang tot de toepassing.

Informatie over hints voor verleners (preview)

Hints voor verleners sturen een vertrouwde CA-indicatie terug als onderdeel van de TLS-handshake. De lijst met vertrouwde CA's is ingesteld op het onderwerp van de certificeringsinstanties (CA's) die door de tenant in het Entra-vertrouwensarchief zijn geüpload. Browsersclient of systeemeigen toepassingsclient gebruiken de hints die door de server worden teruggestuurd 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

Klik op het selectievakje Hints voor verleners inschakelen. Beheerders van verificatiebeleid moeten op I bevestigen nadat u ervoor hebt gezorgd dat de proxy waarvoor TLS-inspectie is ingeschakeld, correct is bijgewerkt en opslaat.

Notitie

Als uw organisatie firewalls of proxy's met TLS-inspectie heeft, bevestigt u dat u TLS-inspectie hebt uitgeschakeld van het certificaatauth-eindpunt dat kan overeenkomen met een willekeurige naam onder [*.]certauth.login.microsoftonline.com, aangepast volgens de specifieke proxy die wordt gebruikt.

Notitie

De URL van de certificeringsinstantie heeft een indeling t{tenantId}.certauth.login.microsoftonline.com nadat hints voor verleners zijn ingeschakeld.

Updatedoorgifte van ca-vertrouwensarchief

Nadat u hints voor verleners hebt ingeschakeld en CA's hebt toegevoegd, bijgewerkt of verwijderd uit de vertrouwensstatus, is er een vertraging van maximaal 10 minuten om de hints voor verleners weer door te geven aan de client. Gebruikers kunnen pas verifiëren met certificaten die zijn uitgegeven door de nieuwe CA's nadat de hints zijn doorgegeven.

Beheerders van verificatiebeleid moeten zich aanmelden met een certificaat nadat ze hints voor verleners hebben ingeschakeld om de doorgifte te initiëren. Gebruikers zien het onderstaande foutbericht wanneer updates voor het vertrouwensarchief van CA worden doorgegeven.

MFA-mogelijkheid voor verificatie op basis van certificaten

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:

1. Gebruik een wachtwoord en SF-certificaat.
2. Geef een tijdelijke toegangspas op.
3. Verificatiebeleidsbeheerder voegt een telefoonnummer toe en staat spraak-/sms-berichtverificatie toe voor het gebruikersaccount.

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

1. Geef een tijdelijke toegangspas op.
2. Verificatiebeleidsbeheerder voegt een telefoonnummer toe en staat spraak-/sms-berichtverificatie 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:

1. Geef een tijdelijke toegangspas op.
2. De gebruiker moet een andere MFA-methode registreren (wanneer de gebruiker MF-certificaat kan gebruiken).
3. Gebruik het wachtwoord en het MF-certificaat (wanneer de gebruiker MF-certificaat kan gebruiken).
4. Verificatiebeleidsbeheerder voegt een telefoonnummer toe en staat spraak-/sms-berichtverificatie toe voor het gebruikersaccount.

MFA met verificatie op basis van één factor certificaat

Microsoft Entra CBA wordt ondersteund als zowel de eerste factor als de selcond-factor voor verificatie. Enkele van de ondersteunde combinaties zijn:

1. CBA (eerste factor) en wachtwoordsleutels (tweede factor)
2. CBA (eerste factor) en aanmelding zonder wachtwoord (tweede factor)
3. CBA (eerste factor) en FIDO2-beveiligingssleutels (tweede factor)
4. Wachtwoord (eerste factor) + CBA (tweede factor) (preview)

Notitie

CBA als tweede factor voor iOS heeft bekende problemen en wordt geblokkeerd op iOS. We werken aan het oplossen van de problemen en moeten worden ondersteund in iOS.

Gebruikers moeten een 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.

1. Meld u aan bij het Microsoft Entra-beheercentrum als ten minste een verificatiebeleidsbeheerder.

2. 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.

3. Selecteer Meervoudige verificatie>voor beveiliging>Aanvullende multi-factor authentication-instellingen in de cloud.

   

4. Schakel onder Verificatieopties meldingen uit via de mobiele app en selecteer Opslaan.

   

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

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

1. Voer uw UPN (User Principal Name) in en selecteer Volgende.

   

2. Kies Aanmelden met een certificaat.

   

   Als u andere verificatiemethoden hebt ingeschakeld, zoals telefoon-aanmelding of FIDO2-beveiligingssleutels, zien gebruikers mogelijk een ander aanmeldingsscherm.

   

3. Kies het juiste gebruikerscertificaat in de clientcertificaatkiezer en selecteer OK.

   

4. 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.

   

5. U ontvangt een melding op uw telefoon. Selecteer Aanmelden goedkeuren?.

6. Voer het nummer in dat u in het browser- of app-scherm ziet in Microsoft Authenticator.

   

7. 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. Beheerders van verificatiebeleid kunnen de standaardwaarde wijzigen van één factor in multifactor of aangepaste beleidsconfiguraties instellen met behulp van de onderwerp- of beleids-OID- of beleids-OID-velden in het certificaat.

Sterke certificaten

Beheerders van verificatiebeleid kunnen 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 verificatiebeleidsbeheerder 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:

1. Issuer + policy OID-regels hebben voorrang op beleids-OID-regels. Beleids-OID-regels hebben voorrang op regels voor certificaatverleners.
2. 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.
3. 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.
4. 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.
5. Vervolgens worden aangepaste regels met ca-verlener geëvalueerd.
6. 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.
7. 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.
8. 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).
9. 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 Microsoft Entra Authentication Policy Administrator een CBA-verificatiebeleidsregel configureert met behulp van zowel Issuer als Policy OID gevolgen heeft voor sommige scenario's voor apparaatregistratie, waaronder:

• Windows Hello voor Bedrijven-inschrijving
• Registratie van Fido2-beveiligingssleutel
• Aanmelden bij Windows Phone zonder wachtwoord

Apparaatregistratie met Workplace Join, Microsoft Entra ID en hybride Microsoft Entra-apparaatdeelnamescenario's worden niet beïnvloed. CBA-verificatiebeleidsregels die gebruikmaken van Issuer OR Policy OID, worden niet beïnvloed. Om dit te verhelpen, moeten beheerders van verificatiebeleid:

• 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>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	hoge affiniteit
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	certificateUserIds	hoge affiniteit
IssuerAndSerialNumber (preview)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT 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 verificatiebeleidsbeheerder configureren of een gebruiker kan worden geverifieerd met behulp van bindingstoewijzing met lage affiniteit of 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).

1. Zoek het gebruikersobject op met behulp van de gebruikersnaam of User Principal Name.
2. Haal de lijst op met alle gebruikersnaambindingen die zijn ingesteld door de verificatiebeleidsbeheerder in de configuratie van de CBA-verificatiemethode, 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.
3. 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.
4. Evalueer elke binding in de lijst totdat een geslaagde verificatie plaatsvindt.
5. 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.
6. Als het X.509-certificaatveld zich niet in het gepresenteerde certificaat bevindt, gaat u naar de volgende prioriteitsbinding.
7. Valideer alle geconfigureerde gebruikersnaambindingen totdat een van deze bindingen resulteert in een overeenkomst en gebruikersverificatie is geslaagd.
8. 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, waardoor een verificatiebeleidsbeheerder één certificaat kan gebruiken voor meerdere configuraties van Microsoft 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 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 de 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 de verificatiebeleidsbeheerder 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 verificatiebeleidsbeheerder ervoor zorgen dat het account de UPN heeft die aanwezig is in het certificaat en de SKI-toewijzing implementeert in het kenmerk certificateUserId van hetzelfde account.

Ondersteuning voor meerdere certificaten met één Microsoft 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:<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 en de tweede waarde X509Certificate2. De gebruiker kan een van beide certificaten presenteren bij de aanmelding en zolang de binding voor CBA-gebruikersnaam is ingesteld om te verwijzen naar het veld certificateUserIds om te zoeken naar het specifieke bindingstype (dat wil gezegd 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 hoge affiniteit (dat wil zeggen sterke verificatie), bijvoorbeeld Issuer + SerialNumber, kan dit 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 en de tweede waarde X509Certificate2. Deze waarden moeten vervolgens worden gesynchroniseerd met het veld certificateUserIds in Microsoft Entra ID.

Ondersteuning voor één certificaat met meerdere Microsoft 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 bij verschillende Microsoft Entra-accounts en het wordt aanbevolen om niet één certificaat toe te staan voor meerdere Microsoft 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 (dat wil gezegd: beheerders van verificatiebeleid kunnen 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:<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, 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 beheerders van verificatiebeleid unieke waarden kunnen toewijzen aan elk gebruikersaccount dat het certificaat gaat gebruiken, is het lastig om alle waarden in te vullen voor elk account in Microsoft Entra ID. In plaats daarvan moet Microsoft Entra Connect de gewenste waarden per account filteren op unieke waarden die zijn ingevuld in het account in Microsoft Entra-id. De uniekheidsregel is van toepassing binnen de grenzen van één map/tenant (dat wil gezegd: beheerders van verificatiebeleid kunnen 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 Microsoft Entra-tenant. In dit geval past Microsoft Entra Connect het filter toe op elk van deze AD-forests met hetzelfde doel om alleen een gewenste unieke waarde in te vullen met het cloudaccount.

Vul het veld altSecurityId-entiteiten in AD in met de waarden die het gewenste certificaat identificeren en om de gewenste certificaatwaarde voor dat gebruikersaccounttype op te nemen (zoals detailee, beheerder, ontwikkelaar, enzovoort). Selecteer een sleutelkenmerk in AD waarmee wordt gesynchroniseerd welk gebruikersaccounttype de gebruiker evalueert (zoals 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>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

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

Stappen voor het synchroniseren met certificateUserIds

1. Microsoft Entra Connect configureren om het veld alternativeSecurityIds toe te voegen aan de Metaverse
2. 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.
3. 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. Het filter haalt alle waarden op en synchroniseert met Microsoft Entra ID, niet alleen de eerste die wordt gevonden.

1. 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 Microsoft Entra-id.

1. Configureer een nieuwe aangepaste uitgaande regel met een lage prioriteit (hoog getal boven 160 – onder aan de lijst).
2. Voeg een directe transformatie toe met het veld alternativeSecurityIds als de bron en het veld certificateUserIds als doel.
3. Voer een synchronisatiecyclus uit om de populatie van de gegevens in Microsoft 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 certificaatintrekkingsproces kunnen beheerders van verificatiebeleid 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.

Beheerders van verificatiebeleid kunnen 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 Microsoft 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 Microsoft Entra-id en 150 MB in Azure US Government-clouds).

Belangrijk

Als een verificatiebeleidsbeheerder 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:

1. 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.
2. 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.
3. 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, moeten beheerders van verificatiebeleid 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.

1. Verbinding maken met PowerShell:

   Connect-MgGraph
   

2. Haal de huidige waarde StsRefreshTokensValidFrom voor een gebruiker op:

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

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

Inzicht in CRL-validatie (preview)

Een CRL is een record van digitale certificaten die zijn ingetrokken vóór het einde van de geldigheidsperiode door een certificeringsinstantie (CA). Wanneer CA's worden geüpload naar het Vertrouwensarchief van Microsoft Entra, is een CRL of meer specifiek het kenmerk CrlDistributionPoint niet vereist. Een CA kan worden geüpload zonder een CRL-eindpunt en verificatie op basis van certificaten mislukt niet als een verlenende CA geen CRL heeft opgegeven.

Om de beveiliging te versterken en onjuiste configuraties te voorkomen, kan een verificatiebeheerder van verificatiebeleid vereisen dat CBA-verificatie mislukt als er geen CRL is geconfigureerd voor een CA die een certificaat voor eindgebruikers uitgeeft.

CRL-validatie inschakelen

Als u CRL-validatie wilt inschakelen, klikt u op CRL-validatie vereisen (aanbevolen).

Als CBA is ingeschakeld, mislukt het certificaat van de eindgebruiker dat is uitgegeven door een CA zonder CRL geconfigureerd.

Een verificatiebeleidsbeheerder kan een CA uitsluiten als de bijbehorende CRL problemen heeft die moeten worden opgelost. Klik op Uitzondering toevoegen en selecteer eventuele CA's die moeten worden uitgesloten.

De CA's in de uitgesloten lijst zijn niet vereist om CRL te configureren en de certificaten van eindgebruikers die ze uitgeven, mislukken de verificatie niet.

Notitie

Er is een bekend probleem met de objectkiezer waarbij de geselecteerde items niet correct worden weergegeven. Gebruik het tabblad Certificeringsinstanties om CA's te selecteren of te verwijderen.

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 verificatiebeleidsbeheerder 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 begrijpen

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:

Aanmeldingsproblemen met dynamische variabelen in aanmeldingslogboeken oplossen

Hoewel aanmeldingslogboeken alle informatie bevatten voor het opsporen van fouten in de aanmeldingsproblemen van een gebruiker, zijn er situaties waarin specifieke waarden vereist zijn en omdat aanmeldingslogboeken geen ondersteuning bieden voor dynamische variabelen, zouden de aanmeldingslogboeken ontbrekende gegevens bevatten. 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.

1. 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.

2. 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.

1. 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.

2. 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.

   

   De vermelding met de status Onderbroken bevat meer diagnostische informatie 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 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:

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 verificatiebeleidsbeheerder, die op zijn beurt meer informatie kan krijgen uit de aanmeldingslogboeken.

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.

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 B2B-gastgebruiker kan CBA op de thuistenant gebruiken en als de instellingen voor meerdere tenants voor de resourcetenant zijn ingesteld om MFA van de thuistenant te vertrouwen, wordt de CBA-verificatie van de gebruiker op de basistenant gehonoreerd. Zie B2B-samenwerking tussen tenants configureren voor meerdere tenants voor meer informatie over het inschakelen van meervoudige verificatie van Vertrouwen vanuit Microsoft Entra-tenants. CBA voor resourcetenant wordt nog niet ondersteund.

Volgende stappen

• Overzicht van Microsoft Entra CBA
• Microsoft Entra CBA configureren
• Microsoft Entra CBA op iOS-apparaten
• Microsoft Entra CBA op Android-apparaten
• Windows-smartcardaanmelding met Microsoft Entra CBA
• Certificaatgebruikers-id's
• Federatieve gebruikers migreren
• Veelgestelde vragen
• Problemen met Microsoft Entra CBA oplossen