Teknisk djupdykning i Microsoft Entra-certifikatbaserad autentisering

Den här artikeln beskriver hur Microsoft Entra-certifikatbaserad autentisering (CBA) fungerar och fördjupar sig i teknisk information om Microsoft Entra CBA-konfigurationer.

Hur fungerar Microsoft Entra-certifikatbaserad autentisering?

Följande bild beskriver vad som händer när en användare försöker logga in på ett program i en klientorganisation där Microsoft Entra CBA är aktiverat.

Nu ska vi gå igenom varje steg:

1. Användaren försöker komma åt ett program, till exempel MyApps-portalen.

2. Om användaren inte redan är inloggad omdirigeras användaren till inloggningssidan för Microsoft Entra-ID-användare på https://login.microsoftonline.com/.

3. Användaren anger sitt användarnamn på inloggningssidan för Microsoft Entra och väljer sedan Nästa. Microsoft Entra-ID gör identifiering av hemsfär med klientnamnet och användarnamnet används för att leta upp användaren i klientorganisationen.

   

4. Microsoft Entra ID kontrollerar om CBA är aktiverat för klientorganisationen. Om CBA är aktiverat ser användaren en länk till Använd ett certifikat eller smartkort på lösenordssidan. Om användaren inte ser inloggningslänken kontrollerar du att CBA är aktiverat i klientorganisationen. Mer information finns i Hur gör jag för att aktivera Microsoft Entra CBA?.

   Kommentar

   Om CBA är aktiverat i klientorganisationen ser alla användare länken till Använd ett certifikat eller smartkort på lösenordssidan. Men endast användare i omfånget för CBA kan autentiseras mot ett program som använder Microsoft Entra-ID som identitetsprovider (IdP).

   

   Om du har aktiverat andra autentiseringsmetoder som Telefon inloggning eller säkerhetsnycklar kan användarna se en annan inloggningsskärm.

   

5. När användaren har valt certifikatbaserad autentisering omdirigeras klienten till certauth-slutpunkten, som är https://certauth.login.microsoftonline.com för offentligt Entra-ID. För Azure Government är https://certauth.login.microsoftonline.uscertauth-slutpunkten .

   Slutpunkten utför ömsesidig TLS-autentisering och begär klientcertifikatet som en del av TLS-handskakningen. En post för den här begäran visas i inloggningsloggen.

   Kommentar

   Nätverksadministratören bör tillåta åtkomst till användarens inloggningssida och certauth-slutpunkten *.certauth.login.microsoftonline.com för kundens molnmiljö. Inaktivera TLS-inspektion på certauth-slutpunkten för att se till att klientcertifikatbegäran lyckas som en del av TLS-handskakningen.

   Kontrollera att TLS-inspektionens inaktiverande också fungerar för den nya URL:en med tips från utfärdaren. Hårdkoda inte URL:en med tenantId eftersom den kan ändras för B2B-användare. Använd ett reguljärt uttryck för att tillåta att både den gamla och den nya URL:en fungerar för TLS-inspektionsaktivering. Beroende på proxyn använder du *.certauth.login.microsoftonline.com till exempel eller *certauth.login.microsoftonline.com. I Azure Government använder du *.certauth.login.microsoftonline.us eller *certauth.login.microsoftonline.us.

   Om inte åtkomst tillåts misslyckas certifikatbaserad autentisering om du aktiverar den kommande funktionen betrodda CA-tips.

6. Microsoft Entra ID begär ett klientcertifikat. Användaren väljer klientcertifikatet och väljer Ok.

   Kommentar

   Betrodda CA-tips stöds inte, så listan över certifikat kan inte begränsas ytterligare. Vi tittar på att lägga till den här funktionen i framtiden.

   

7. Microsoft Entra-ID verifierar listan över återkallade certifikat för att kontrollera att certifikatet inte har återkallats och är giltigt. Microsoft Entra-ID identifierar användaren med hjälp av den användarnamnsbindning som konfigurerats för klientorganisationen för att mappa certifikatfältets värde till värdet för användarattributet.

8. Om en unik användare hittas med en princip för villkorsstyrd åtkomst som kräver multifaktorautentisering och bindningsregeln för certifikatautentisering uppfyller MFA, loggar Microsoft Entra-ID in användaren omedelbart. Om MFA krävs men certifikatet endast uppfyller en enda faktor erbjuds antingen lösenordslös inloggning eller FIDO2 som en andra faktor om de redan är registrerade.

9. Microsoft Entra-ID:t slutför inloggningsprocessen genom att skicka tillbaka en primär uppdateringstoken för att indikera lyckad inloggning.

10. Om användaren har loggat in kan användaren komma åt programmet.

Certifikatbaserad autentisering är MFA-kompatibel

Microsoft Entra CBA kan multifaktorautentisering (MFA). Microsoft Entra CBA kan vara antingen enkelfaktor (SF) eller multifaktor (MF) beroende på klientkonfigurationen. Om du aktiverar CBA kan en användare eventuellt slutföra MFA. En användare kan behöva mer konfiguration för att slutföra MFA och kunna registrera andra autentiseringsmetoder när användaren är i omfånget för CBA.

Om den CBA-aktiverade användaren bara har ett SF-certifikat (Single Factor) och behöver slutföra MFA:

1. Använd ett lösenord och ett SF-certifikat.
2. Utfärda ett tillfälligt åtkomstpass.
3. Administratör för autentiseringsprincip lägger till ett telefonnummer och tillåter röst-/textmeddelandeautentisering för användarkontot.

Om den CBA-aktiverade användaren ännu inte har utfärdats något certifikat och behöver slutföra MFA:

1. Utfärda ett tillfälligt åtkomstpass.
2. Administratör för autentiseringsprincip lägger till ett telefonnummer och tillåter röst-/textmeddelandeautentisering för användarkontot.

Om den CBA-aktiverade användaren inte kan använda ett MF-certifikat, till exempel på mobila enheter utan stöd för smartkort, och behöver slutföra MFA:

1. Utfärda ett tillfälligt åtkomstpass.
2. Användaren måste registrera en annan MFA-metod (när användaren kan använda MF-certifikat).
3. Använd lösenord och MF-certifikat (när användaren kan använda MF-certifikat).
4. Administratör för autentiseringsprincip lägger till ett telefonnummer och tillåter röst-/textmeddelandeautentisering för användarkontot.

MFA med enfaktorcertifikatbaserad autentisering (förhandsversion)

Microsoft Entra CBA kan användas som en andra faktor för att uppfylla MFA-kraven med enfaktorcertifikat. Några av de kombinationer som stöds är:

1. CBA (första faktorn) och lösenordslös inloggning via telefon (lösenordslös inloggning som andra faktor)
2. CBA (första faktorn) och FIDO2-säkerhetsnycklar (andra faktorn)
3. Lösenord (första faktorn) och CBA (andra faktorn)

Användare måste ha ett annat sätt att få MFA och registrera lösenordslös inloggning eller FIDO2 i förväg för att logga in med Microsoft Entra CBA.

Viktigt!

En användare anses vara MFA-kapabel när de ingår i CBA-metodinställningarna. Det innebär att användaren inte kan använda bevis som en del av sin autentisering för att registrera andra tillgängliga metoder. Kontrollera att användare utan ett giltigt certifikat inte ingår i CBA-metodinställningarna. Mer information om hur autentisering fungerar finns i Microsoft Entra multifaktorautentisering.

Steg för att konfigurera lösenordslös telefoninloggning (PSI) med CBA

För att lösenordslös inloggning ska fungera bör användarna inaktivera äldre meddelanden via sin mobilapp.

1. Logga in på administrationscentret för Microsoft Entra som minst administratör för autentiseringsprinciper.

2. Följ stegen i Aktivera lösenordslös autentisering för telefoninloggning.

   Viktigt!

   I föregående konfiguration kontrollerar du att du har valt alternativet Lösenordslös . Du måste ändra autentiseringsläget för alla grupper som har lagts till för PSI till Lösenordsfri. Om du väljer Alla fungerar inte CBA och PSI.

3. Välj Skydd>Multifaktorautentisering>Ytterligare molnbaserade inställningar för multifaktorautentisering.

   

4. Under Verifieringsalternativ avmarkerar du Meddelande via mobilapp och väljer Spara.

   

MFA-autentiseringsflöde med hjälp av certifikat med en faktor och lösenordsfri inloggning

Nu ska vi titta på ett exempel på en användare som har ett enfaktorcertifikat och som har konfigurerats för lösenordslös inloggning.

1. Ange användarens huvudnamn (UPN) och välj Nästa.

   

2. Välj Logga in med ett certifikat.

   

   Om du har aktiverat andra autentiseringsmetoder som Telefon inloggning eller FIDO2-säkerhetsnycklar kan användarna se en annan inloggningsskärm.

   

3. Välj rätt användarcertifikat i klientcertifikatväljaren och välj OK.

   

4. Eftersom certifikatet är konfigurerat för att vara enfaktorautentiseringsstyrka behöver användaren en andra faktor för att uppfylla MFA-kraven. Användaren ser tillgängliga andra faktorer, vilket i det här fallet är lösenordsfri inloggning. Välj Godkänn en begäran i min Microsoft Authenticator-app.

   

5. Du får ett meddelande på din telefon. Välj Godkänn inloggning?.

6. Ange det nummer som visas på webbläsar- eller appskärmen i Microsoft Authenticator.

   

7. Välj Ja så kan användaren autentisera och logga in.

Förstå autentiseringsbindningsprincipen

Autentiseringsbindningsprincipen hjälper till att fastställa styrkan i autentiseringen som antingen en faktor eller multifaktor. En administratör kan ändra standardvärdet från enfaktor till multifaktor eller konfigurera anpassade principkonfigurationer antingen med hjälp av utfärdarens ämne eller princip-OID- eller utfärdare- och princip-OID-fält i certifikatet.

Certifikatstyrkor

En administratör kan avgöra om certifikaten är enfaktors- eller multifaktorstyrka. Mer information finns i dokumentationen som mappar NIST Authentication Assurance Levels till Microsoft Entra-autentiseringsmetoder, som bygger på NIST 800-63B SP 800-63B, Riktlinjer för digital identitet: autentisering och livscykel Mgmt.

Multifaktorcertifikatautentisering

När en användare har ett multifaktorcertifikat kan de endast utföra multifaktorautentisering med certifikat. En administratör för autentiseringsprinciper bör dock se till att certifikaten skyddas med en PIN-kod eller biometrisk kod som ska betraktas som multifaktor.

Så här löser Microsoft Entra-ID flera bindningsregler för autentiseringsprinciper

Eftersom flera regler för bindning av anpassad autentisering kan skapas med olika certifikatfält som att använda utfärdare + princip-OID, eller bara princip-OID eller bara utfärdare. nedan visas de steg som används för att fastställa autentiseringsskyddsnivån när anpassade regler överlappar varandra. De är följande:

1. Utfärdare + princip-OID-regler har företräde framför princip-OID-regler. Princip-OID-regler har företräde framför certifikatutfärdarregler.
2. Utfärdare + princip-OID-regler utvärderas först. Om du har en anpassad regel med utfärdaren CA1 och princip OID 1.2.3.4.5 med MFA får endast certifikat A som uppfyller både utfärdarvärdet och princip-OID MFA.
3. Därefter utvärderas anpassade regler med hjälp av princip-OID:er. Om du har ett certifikat A med principen OID 1.2.3.4.5 och en härledd autentiseringsuppgift B baserat på certifikatet har en princip OID 1.2.3.4.5.6, och den anpassade regeln definieras som Princip-OID med värdet 1.2.3.4.5 med MFA, endast certifikat A uppfyller MFA och autentiseringsuppgifter B endast uppfyller enfaktorautentisering. Om användaren använde härledda autentiseringsuppgifter under inloggningen och har konfigurerats för att ha MFA uppmanas användaren att ange en andra faktor för lyckad autentisering.
4. Om det finns en konflikt mellan flera princip-OID :er (till exempel när ett certifikat har två princip-OID:er, där den ena binder till enfaktorautentisering och den andra binder till MFA) behandlar du certifikatet som en enfaktorautentisering.
5. Därefter utvärderas anpassade regler med utfärdarens CA.
6. Om ett certifikat har både princip-OID- och Issuer-regler som matchar kontrolleras principens OID alltid först, och om ingen principregel hittas kontrolleras utfärdarbindningarna. Princip-OID har en högre prioritet för autentiseringsbindning än utfärdaren.
7. Om en certifikatutfärdare binder till MFA kvalificerar sig alla användarcertifikat som CA-problemen är MFA. Samma logik gäller för enfaktorautentisering.
8. Om en princip-OID binder till MFA kvalificeras alla användarcertifikat som innehåller den här princip-OID:en som en av OID:erna (ett användarcertifikat kan ha flera princip-OID:er) som MFA.
9. En certifikatutfärdare kan bara ha en giltig stark autentiseringsbindning (det vill: ett certifikat kan inte binda till både en faktor och MFA).

Viktigt!

Det finns ett känt problem där en Entra-klientadministratör konfigurerar en principregel för CBA-autentisering med både utfärdare och princip-OID påverkar vissa scenarier för enhetsregistrering, inklusive:

• Windows Hello för företag-registrering
• Registrering av Säkerhetsnyckel för Fido2
• Windows Lösenordsfri Telefon inloggning

Enhetsregistrering med Workplace Join, Entra ID och Hybrid Entra ID-enhetsanslutningsscenarier påverkas inte. CBA-autentiseringsprincipregler med antingen Utfärdare ELLER Princip-OID påverkas inte. För att minimera bör administratörerna:

• Redigera de certifikatbaserade autentiseringsprincipreglerna som för närvarande använder alternativ för både utfärdare och princip-OID och ta bort antingen utfärdaren eller OID-kravet och spara. ELLER
• Ta bort autentiseringsprincipregeln som för närvarande använder både utfärdare och princip-OID och skapa regler med endast utfärdare eller princip-OID

Vi arbetar med att åtgärda problemet.

Förstå principen för användarnamnbindning

Principen för användarnamnbindning hjälper till att verifiera användarens certifikat. Som standard mappas san-huvudnamnet (Subject Alternate Name) i certifikatet till attributet UserPrincipalName för användarobjektet för att fastställa användaren.

Uppnå högre säkerhet med certifikatbindningar

Det finns sju metoder som stöds för certifikatbindningar. I allmänhet betraktas mappningstyper som hög tillhörighet om de baseras på identifierare som du inte kan återanvända, till exempel ämnesnyckelidentifierare eller sha1 offentlig nyckel. Dessa identifierare ger en högre försäkran om att endast ett enda certifikat kan användas för att autentisera respektive användare.

Mappningstyper baserade på användarnamn och e-postadresser anses vara låg tillhörighet. Microsoft Entra ID implementerar tre mappningar som anses vara låg tillhörighet baserat på återanvändbara identifierare. De andra betraktas som bindningar med hög tillhörighet. Mer information finns i certificateUserIds.

Fält för certifikatmappning	Exempel på värden i certificateUserIds	Attribut för användarobjekt	Typ
Huvudnamn	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	låg tillhörighet
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	låg tillhörighet
IssuerAndSubject (förhandsversion)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	låg tillhörighet
Ämne (förhandsversion)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	låg tillhörighet
SKI	X509:<SKI>123456789abcdef	certificateUserIds	hög tillhörighet
SHA1PublicKey	X509:<SHA1-PUKEY>123456789abcdef	certificateUserIds	hög tillhörighet
IssuerAndSerialNumber (förhandsversion)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48 Om du vill hämta rätt värde för serienummer kör du det här kommandot och lagrar värdet som visas i CertificateUserIds: Syntax: Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Exempel: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	hög tillhörighet

Definiera tillhörighetsbindning på klientorganisationsnivå och åsidosätt med anpassade regler (förhandsversion)

Med den här funktionen kan en administratör för autentiseringsprinciper konfigurera om en användare kan autentiseras med hjälp av bindningsmappning med låg tillhörighet eller hög tillhörighet. Du kan ange Obligatorisk tillhörighetsbindning för klientorganisationen, vilket gäller för alla användare. Du kan också åsidosätta standardvärdet för hela klientorganisationen genom att skapa anpassade regler baserat på utfärdare och princip-OID, princip-OID eller utfärdare.

Så här löser Microsoft Entra-ID flera bindningsregler för användarnamnsprinciper

Använd bindningen högsta prioritet (lägsta antal).

1. Leta upp användarobjektet med hjälp av användarnamnet eller användarens huvudnamn.
2. Hämta listan över alla konfigurationer av användarnamnsbindningar av klientadministratören i cba-autentiseringsmetodkonfigurationen sorterad efter attributet "prioritet". I dag exponeras inte begreppet prioritet i portalens UX. Graph returnerar prioritetsattributet för varje bindning och de används i utvärderingsprocessen.
3. Om klientorganisationen har hög tillhörighetsbindning aktiverad eller om certifikatvärdet matchar en anpassad regel som kräver hög tillhörighetsbindning tar du bort alla bindningar med låg tillhörighet från listan.
4. Utvärdera varje bindning i listan tills en lyckad autentisering inträffar.
5. Om X.509-certifikatfältet för den konfigurerade bindningen finns på det visade certifikatet matchar Microsoft Entra-ID värdet i certifikatfältet med attributevärdet för användarobjektet.
   1. Om en matchning hittas lyckas användarautentiseringen.
   2. Om en matchning inte hittas går du till nästa prioritetsbindning.
6. Om fältet X.509-certifikat inte finns på det visade certifikatet går du vidare till nästa prioritetsbindning.
7. Verifiera alla konfigurerade användarnamnsbindningar tills en av dem resulterar i en matchning och användarautentiseringen lyckas.
8. Om en matchning inte hittas på någon av de konfigurerade användarnamnsbindningarna misslyckas användarautentiseringen.

Skydda Microsoft Entra-konfiguration med flera användarnamnsbindningar

Vart och ett av microsoft entra-objektattributen (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) som är tillgängliga för att binda certifikat till Microsoft Entra-användarkonton har en unik begränsning för att säkerställa att ett certifikat endast matchar ett enda Microsoft Entra-användarkonto. Microsoft Entra CBA stöder dock flera bindningsmetoder i principen för användarnamnsbindning som gör att en administratör kan hantera ett certifikat till flera konfigurationer av Entra-användarkonton.

Viktigt!

Om du konfigurerar flera bindningar är Microsoft Entra CBA-autentisering bara lika säker som din lägsta tillhörighetsbindning eftersom CBA verifierar varje bindning för att autentisera användaren. För att förhindra ett scenario där ett enskilt certifikat matchar flera Microsoft Entra-konton kan en administratör för autentiseringsprinciper:

• Konfigurera en enda bindningsmetod i principen för användarnamnbindning.
• Om en klientorganisation har flera bindningsmetoder konfigurerade och inte vill tillåta att ett certifikat mappas till flera konton, måste administratören för autentiseringsprincip se till att alla tillåtna metoder som konfigurerats i principkartan till samma Microsoft Entra-konto. Alla användarkonton ska ha värden som matchar alla bindningar.
• Om en klientorganisation har flera konfigurerade bindningsmetoder bör administratören för autentiseringsprinciper se till att de inte har fler än en bindning med låg tillhörighet.

Anta till exempel att du har två användarnamnsbindningar på PrincipalName mappade till UPN och SubjectKeyIdentifier (SKI) till certificateUserIds. Om du vill att ett certifikat endast ska användas för ett enda konto måste en administratör för autentiseringsprincip se till att kontot har det UPN som finns i certifikatet och implementera SKI-mappningen i attributet certificateUserId för samma konto.

Stöd för flera certifikat med ett Entra-användarkonto (M:1)

Det finns scenarier där en organisation utfärdar flera certifikat för en enda identitet. Oftast kan detta vara en härledd autentiseringsuppgift för en mobil enhet eller kan även vara för ett sekundärt smartkort eller x509-autentiseringshållare som kan användas, till exempel en Yubikey.

Endast molnkonton För endast molnkonton kan du mappa flera certifikat (upp till 5) för användning genom att fylla i fältet certificateUserIds (auktoriseringsinformation i användarportalen) med unika värden som identifierar varje certifikat. Om organisationen använder bindningar med hög tillhörighet, till exempel Issuer + SerialNumber, kan värden i CertificateUserIds se ut så här:

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

I det här exemplet representerar det första värdet X509Certificate1 och det andra värdet representerar X509Certificate2. Användaren kan visa antingen certifikat vid inloggning och så länge cba-användarnamnsbindningen är inställd på att peka på fältet certificateUserIds för att söka efter den specifika bindningstypen (dvs. Issuer+SerialNumber i det här exemplet) kommer användaren att logga in.

Hybridsynkroniserade konton För synkroniserade konton kan du mappa flera certifikat för användning genom att fylla i fältet altSecurityIdentiteter i AD de värden som identifierar varje certifikat. Om organisationen använder bindningar med hög tillhörighet (dvs. stark autentisering), till exempel Issuer + SerialNumber, kan det se ut så här:

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

I det här exemplet representerar det första värdet X509Certificate1 och det andra värdet representerar X509Certificate2. Dessa värden måste sedan synkroniseras med fältet certificateUserIds i Azure AD.

Stöd för ett certifikat med flera Entra-användarkonton (1:M)

Det finns scenarier där en organisation behöver användaren för att använda samma certifikat för att autentisera till flera identiteter. Oftast är detta för administrativa konton. Det kan också vara för utvecklarkonton eller tillfälliga tjänstkonton. I traditionell AD används fältet altSecurityIdentities för att fylla i certifikatvärdena och ett tips används under inloggningen för att dirigera AD till önskat konto för att söka efter inloggningen. Med Microsoft Entra CBA är detta annorlunda och det finns inget tips. I stället identifierar Home Realm Discovery det önskade kontot för att kontrollera certifikatvärdena. Den andra viktiga skillnaden är att Microsoft Entra CBA framtvingar unikhet i fältet certificateUserIds. Det innebär att två konton inte kan fylla i samma certifikatvärden.

Viktigt!

Det är inte en mycket säker konfiguration att använda samma autentiseringsuppgifter för att autentisera till olika Entra-ID-konton och vi rekommenderar att du inte tillåter ett certifikat för flera Entra-användarkonton.

Endast molnkonton För endast molnkonton måste du skapa flera användarnamnsbindningar och behöva mappa unika värden till varje användarkonto som ska använda certifikatet. Varje konto autentiseras till med en annan användarnamnsbindning. Detta gäller inom gränsen för en enskild katalog/klientorganisation (d.v.s. Innehavaradministratören kan mappa certifikatet för användning i en annan katalog/klientorganisation, så länge värdena förblir unika per konto också).

Fyll i fältet certificateUserIds (auktoriseringsinformation i användarportalen) med ett unikt värde som identifierar önskat certifikat. Om organisationen använder bindningar med hög tillhörighet (dvs. stark autentisering) till exempel Issuer + SerialNumber och SKI kan det se ut så här:

Användarnamnsbindningar:

• Utfärdare + serienummer –> CertificateUserIds
• SKI –> CertificateUserIds

Värden för användarkontot CertificateUserIds:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Nu när någon av användarna visar samma certifikat vid inloggningen loggar användaren in eftersom deras konto matchar ett unikt värde på certifikatet. Ett konto autentiseras till att använda Issuer+SerialNumber och det andra med ski-bindning.

Kommentar

Antalet konton som kan användas på det här sättet begränsas av antalet användarnamnsbindningar som konfigurerats för klientorganisationen. Om organisationen endast använder bindningar med hög tillhörighet begränsas antalet konton som stöds till 3. Om organisationen också använder bindningar med låg tillhörighet ökar antalet till 7 konton (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Hybridsynkronerade konton För synkroniserade konton kommer metoden att vara annorlunda. Klientadministratören kan mappa unika värden till varje användarkonto som ska använda certifikatet, men det är vanligt att fylla i alla värden för varje konto i Entra-ID, men det skulle göra det svårt. I stället bör Azure AD-Anslut filtrera önskade värden per konto till unika värden som fylls i i kontot i Etttra-ID. Unikhetsregeln gäller inom gränsen för en enskild katalog/klientorganisation (d.v.s. Klientadministratören kan mappa certifikatet för användning i en annan katalog/klientorganisation, så länge värdena förblir unika per konto också). Dessutom kan organisationen ha flera AD-skogar som bidrar användare till en enda Entra ID-klientorganisation. I det här fallet använder Azure AD Anslut filtret på var och en av dessa AD-skogar med samma mål att endast fylla i ett önskat unikt värde för molnkontot.

Fyll i fältet altSecurityIdentiteter i AD med värden som identifierar det önskade certifikatet och inkludera önskat certifikatvärde för den typen av användarkonto (t.ex. information, administratör, utvecklare osv.). Välj ett nyckelattribut i AD som talar om för synkroniseringen vilken användarkontotyp användaren utvärderar (t.ex. msDS-cloudExtensionAttribute1). Fyll i det här attributet med det värde för användartyp som du önskar, till exempel detalj, administratör eller utvecklare. Om det här är användarens primära konto kan värdet lämnas tomt/null.

Kontona kan se ut så här:

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

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

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

Dessa värden måste sedan synkroniseras till fältet certificateUserIds i Entra ID.

Steg för att synkronisera med certificateUserIds

1. Konfigurera Azure AD Connect för att lägga till fältet alternativeSecurityIds i Metaversum
2. För varje AD-skog konfigurerar du en ny anpassad inkommande regel med hög prioritet (lågt antal under 100). Lägg till en uttryckstransformering med fältet altSecurityIdentiteter som källa. Måluttrycket använder nyckelattributet som du valde och fyllde i samt mappningen till de användartyper som du definierade.
3. Till exempel:

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

I exemplet ovan kontrolleras först altSecurityIdentiteter och nyckelattributet msDS-cloudExtensionAttribute1is för att se om de är ifyllda. Annars kontrolleras altSecurityIdentiteter för att se om de är ifyllda. Om den är tom ställer vi in den på NULL. Annars faller kontot i standardfallet och i det här exemplet filtrerar vi endast till mappningen Issuer+SerialNumber. Om nyckelattributet är ifyllt kontrolleras värdet för att se om det är lika med någon av våra definierade användartyper. I det här exemplet om det värdet är detaljerat filtrerar vi till SHA1PublicKey-värdet från altSecurityIdentiteter. Om värdet är utvecklare filtrerar vi till värdet SubjectKeyIssuer från altSecurityIdentiteter. Det kan finnas flera certifikatvärden av en viss typ. Till exempel flera PrincipalName-värden eller flera SKI- eller SHA1-PUKEY-värden. Filtret hämtar alla värden och synkroniseras med Entra-ID– inte bara det första som hittas.

1. Ett andra exempel som visar hur du push-överför ett tomt värde om kontrollattributet är tomt finns nedan.

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

Om värdet i altSecurityIdentiteter inte matchar något av sökvärdena i kontrollattributet skickas en AuthoritativeNull. Detta säkerställer att tidigare eller efterföljande regler som fyller i alternativeSecurityId ignoreras och resultatet är tomt i Entra-ID.

1. Konfigurera en ny anpassad regel för utgående trafik med låg prioritet (högt antal över 160 – längst ned i listan).
2. Lägg till en direkt transformering med fältet alternativeSecurityIds som källa och fältet certificateUserIds som mål.
3. Kör en synkroniseringscykel för att slutföra datapopulationen i Entra ID.

Kontrollera att CBA i varje klientorganisation har konfigurerats med fältet Användarnamnsbindningar som pekar på fältet certificateUserIds för de fälttyper som du har mappat från certifikatet. Nu kan någon av dessa användare presentera certifikatet vid inloggning och när det unika värdet från certifikatet har verifierats mot fältet certificateUserIds kommer användaren att loggas in.

Förstå processen för återkallande av certifikat

Med processen för återkallande av certifikat kan administratören återkalla ett tidigare utfärdat certifikat från att användas för framtida autentisering. Certifikatåterkallningen återkallar inte redan utfärdade token för användaren. Följ stegen för att manuellt återkalla token vid Konfigurera återkallning.

Microsoft Entra ID laddar ned och cachelagrar kundens lista över återkallade certifikat (CRL) från certifikatutfärdaren för att kontrollera om certifikat återkallas under användarens autentisering.

En administratör kan konfigurera CRL-distributionsplatsen under installationsprocessen för betrodda utfärdare i Microsoft Entra-klientorganisationen. Varje betrodd utfärdare bör ha en CRL som kan refereras med hjälp av en internetuppkopplad URL.

Viktigt!

Den maximala storleken på en CRL för Microsoft Entra-ID som ska laddas ned på en interaktiv inloggning och cache är 20 MB i offentligt Entra-ID och 45 MB i Azure US Government-moln, och den tid som krävs för att ladda ned CRL får inte överstiga 10 sekunder. Om Microsoft Entra-ID inte kan ladda ned en CRL misslyckas certifikatbaserade autentiseringar med certifikat som utfärdats av motsvarande certifikatutfärdare. Vi rekommenderar att du håller CRL-filer inom storleksgränserna, håller certifikatets livslängd inom rimliga gränser och rensar utfallna certifikat. Mer information finns i Finns det en gräns för CRL-storlek?.

När en användare utför en interaktiv inloggning med ett certifikat och listan över återkallade certifikat överskrider den interaktiva gränsen för ett moln misslyckas den inledande inloggningen med följande fel:

"Listan över återkallade certifikat (CRL) som laddats ned från {uri} har överskridit den maximala tillåtna storleken ({size} byte) för CRL:er i Microsoft Entra-ID. Försök igen om några minuter. Kontakta klientadministratörerna om problemet kvarstår."

Efter felet försöker Microsoft Entra-ID:t ladda ned crl-certifikatet enligt gränserna på tjänstsidan (45 MB i offentligt Entra-ID och 150 MB i Azure US Government-moln).

Viktigt!

Om administratören hoppar över konfigurationen av CRL utför Inte Microsoft Entra-ID några CRL-kontroller under användarens certifikatbaserade autentisering. Detta kan vara användbart för inledande felsökning, men bör inte övervägas för produktionsanvändning.

Från och med nu stöder vi inte Online Certificate Status Protocol (OCSP) på grund av prestanda- och tillförlitlighetsskäl. I stället för att ladda ned CRL vid varje anslutning i klientwebbläsaren för OCSP laddar Microsoft Entra-ID ned en gång vid den första inloggningen och cachelagrar den, vilket förbättrar prestanda och tillförlitlighet för CRL-verifiering. Vi indexar också cachen så att sökningen går mycket snabbare varje gång. Kunder måste publicera CRL:er för återkallande av certifikat.

Följande steg är ett typiskt flöde i CRL-kontrollen:

1. Microsoft Entra-ID:t försöker ladda ned den återkallade certifikatutfärdaren vid den första inloggningen om någon användare har ett certifikat från motsvarande betrodd utfärdare eller certifikatutfärdare.
2. Microsoft Entra ID cachelagrar och återanvänder CRL för eventuell efterföljande användning. Den respekterar nästa uppdateringsdatumoch, om det är tillgängligt, Nästa CRL-publiceringsdatum (används av Windows Server-certifikatutfärdare) i CRL-dokumentet.
3. Det går inte att använda certifikatbaserad autentisering om:

   • En crl har konfigurerats för den betrodda utfärdaren och Microsoft Entra-ID:t kan inte ladda ned crl på grund av tillgänglighet, storlek eller svarstidsbegränsningar.

   • Användarens certifikat visas som återkallat på listan över återkallade certifikat.

     

   • Microsoft Entra-ID:t försöker ladda ned en ny CRL från distributionsplatsen om det cachelagrade CRL-dokumentet har upphört att gälla.

Kommentar

Microsoft Entra ID kontrollerar CRL för den utfärdande certifikatutfärdaren och andra certifikatutfärdare i PKI-förtroendekedjan upp till rotcertifikatutfärdaren. Vi har en gräns på upp till 10 certifikatutfärdare från lövklientcertifikatet för CRL-validering i PKI-kedjan. Begränsningen är att se till att en dålig aktör inte tar ner tjänsten genom att ladda upp en PKI-kedja med ett stort antal certifikatutfärdare med en större CRL-storlek. Om klientorganisationens PKI-kedja har fler än 5 certifikatutfärdare och i händelse av en CA-kompromiss bör administratören ta bort den komprometterade betrodda utfärdaren från Microsoft Entra-klientkonfigurationen.

Viktigt!

På grund av typen av CRL-cachelagring och publiceringscykler rekommenderar vi starkt att du återkallar alla sessioner för den berörda användaren i Microsoft Entra-ID om ett certifikat återkallas.

Från och med nu finns det inget sätt att manuellt framtvinga eller retrigga nedladdningen av CRL.

Så här konfigurerar du återkallelse

För att återkalla ett klientcertifikat hämtar Microsoft Entra-ID listan över återkallade certifikat (CRL) från URL:erna som laddats upp som en del av certifikatutfärdarens information och cachelagrar den. Den senaste publiceringstidsstämpeln (egenskapen Gällande datum ) i CRL används för att säkerställa att CRL fortfarande är giltig. CRL refereras regelbundet till för att återkalla åtkomsten till certifikat som ingår i listan.

Om ett mer omedelbart återkallning krävs (till exempel om en användare förlorar en enhet) kan användarens auktoriseringstoken ogiltigförklaras. Om du vill ogiltigförklara auktoriseringstoken anger du fältet StsRefreshTokenValidFrom för den här användaren med hjälp av Windows PowerShell. Du måste uppdatera fältet StsRefreshTokenValidFrom för varje användare som du vill återkalla åtkomst för.

För att säkerställa att återkallningen kvarstår måste du ange det gällande datumet för CRL till ett datum efter det värde som angetts av StsRefreshTokenValidFrom och se till att certifikatet i fråga finns i crl-listan.

Kommentar

Azure AD- och MSOnline PowerShell-moduler är inaktuella från och med den 30 mars 2024. Mer information finns i utfasningsuppdateringen. Efter det här datumet är stödet för dessa moduler begränsat till migreringshjälp till Microsoft Graph PowerShell SDK och säkerhetskorrigeringar. De inaktuella modulerna fortsätter att fungera till och med mars 30 2025.

Vi rekommenderar att du migrerar till Microsoft Graph PowerShell för att interagera med Microsoft Entra-ID (tidigare Azure AD). Vanliga migreringsfrågor finns i Vanliga frågor och svar om migrering. Obs! Versioner 1.0.x av MSOnline kan uppleva störningar efter den 30 juni 2024.

Följande steg beskriver processen för att uppdatera och ogiltigförklara auktoriseringstoken genom att ange fältet StsRefreshTokenValidFrom .

1. Anslut till PowerShell:

   Connect-MgGraph
   

2. Hämta det aktuella StsRefreshTokensValidFrom-värdet för en användare:

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

3. Konfigurera ett nytt StsRefreshTokensValidFrom-värde för användaren som är lika med den aktuella tidsstämpeln:

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

Det datum du anger måste vara i framtiden. Om datumet inte är i framtiden anges inte egenskapen StsRefreshTokensValidFrom . Om datumet är i framtiden anges StsRefreshTokensValidFrom till aktuell tid (inte det datum som anges av kommandot Set-MsolUser).

Så här fungerar CBA med en styrkeprincip för autentisering med villkorsstyrd åtkomst

Kunder kan skapa en styrkeprincip för autentisering med villkorsstyrd åtkomst för att ange att CBA ska användas för att komma åt en resurs.

Du kan använda den inbyggda nätfiskeresistenta MFA-autentiseringsstyrkan . Den principen tillåter endast autentiseringsmetoder som är nätfiskeresistenta som CBA, FIDO2-säkerhetsnycklar och Windows Hello för företag.

Du kan också skapa en anpassad autentiseringsstyrka så att endast CBA kan komma åt känsliga resurser. Du kan tillåta CBA som en enskild faktor, multifaktor eller både och. Mer information finns i autentiseringsstyrkan för villkorsstyrd åtkomst.

CBA-autentiseringsstyrka med avancerade alternativ

I principen för CBA-autentiseringsmetoder kan en administratör fastställa certifikatets styrka med hjälp av en autentiseringsbindningsprincip för CBA-metoden. Nu kan du konfigurera Avancerade alternativ när du skapar en anpassad autentiseringsstyrka för att kräva att ett specifikt certifikat används, baserat på utfärdare och princip-OID:er, när användare utför CBA för att få åtkomst till vissa känsliga resurser. Den här funktionen ger en mer exakt konfiguration för att fastställa de certifikat och användare som har åtkomst till resurser. Mer information finns i Avancerade alternativ för autentiseringsstyrka för villkorsstyrd åtkomst.

Förstå inloggningsloggar

Inloggningsloggar innehåller information om inloggningar och hur dina resurser används av dina användare. Mer information om inloggningsloggar finns i Inloggningsloggar i Microsoft Entra-ID.

Nu ska vi gå igenom två scenarier, ett där certifikatet uppfyller enfaktorautentisering och ett annat där certifikatet uppfyller MFA.

För testscenarierna väljer du en användare med en princip för villkorsstyrd åtkomst som kräver MFA. Konfigurera användarbindningsprincipen genom att mappa SAN Principal Name till UserPrincipalName.

Användarcertifikatet ska konfigureras så här:

Felsöka inloggningsproblem med dynamiska variabler i inloggningsloggar

Även om inloggningsloggar ger all information för att felsöka en användares inloggningsproblem, finns det tillfällen då specifika värden krävs och eftersom inloggningsloggar inte stöder dynamiska variabler skulle inloggningsloggarna ha information som saknas. Till exempel: Felorsaken i inloggningsloggen skulle visa något i stil med "Certifikatåterkallningslistan (CRL) misslyckades signaturverifiering. Den förväntade ämnesnyckelidentifieraren {expectedSKI} matchar inte CRL-utfärdarnyckeln {crlAK}. Be klientadministratören att kontrollera CRL-konfigurationen." där {expectedSKI} och {crlAKI} inte är ifyllda med rätt värden.

När användare loggar in med CBA misslyckas kopierar du logginformationen från länken Mer information på felsidan. Mer detaljerad information finns på sidan förstå CBA-fel

Testa enfaktorautentisering

För det första testscenariot konfigurerar du autentiseringsprincipen där utfärdarens ämnesregel uppfyller enfaktorautentisering.

1. Logga in på administrationscentret för Microsoft Entra som testanvändare med hjälp av CBA. Autentiseringsprincipen anges där utfärdarens ämnesregel uppfyller enfaktorautentisering.

2. Sök efter och välj Inloggningsloggar.

   Nu ska vi titta närmare på några av de poster som du hittar i inloggningsloggarna.

   Den första posten begär X.509-certifikatet från användaren. Statusen Avbrytd innebär att Microsoft Entra-ID verifierade att CBA är aktiverat i klientorganisationen och att ett certifikat begärs för autentisering.

   

   Aktivitetsinformationen visar att detta bara är en del av det förväntade inloggningsflödet där användaren väljer ett certifikat.

   

   Ytterligare information visar certifikatinformationen.

   

   Dessa ytterligare poster visar att autentiseringen är klar, en primär uppdateringstoken skickas tillbaka till webbläsaren och användaren får åtkomst till resursen.

   

Testa multifaktorautentisering

I nästa testscenario konfigurerar du autentiseringsprincipen där policyOID-regeln uppfyller multifaktorautentiseringen.

1. Logga in på administrationscentret för Microsoft Entra med hjälp av CBA. Eftersom principen har angetts för att uppfylla multifaktorautentiseringen lyckas användarens inloggning utan en andra faktor.

2. Sök efter och välj Inloggningar.

   Du ser flera poster i inloggningsloggarna, inklusive en post med avbruten status.

   

   Aktivitetsinformationen visar att detta bara är en del av det förväntade inloggningsflödet där användaren väljer ett certifikat.

   

   Posten med avbruten status innehåller mer diagnostikinformation på fliken Ytterligare information .

   

   Följande tabell innehåller en beskrivning av varje fält.

   Fält	beskrivning
   Användarcertifikatets ämnesnamn	Refererar till fältet ämnesnamn i certifikatet.
   Bindning av användarcertifikat	Certifikat: Huvudnamn; Användarattribut: userPrincipalName; Rangordning: 1 Detta visar vilket SAN PrincipalName-certifikatfält som mappades till userPrincipalName-användarattributet och var prioritet 1.
   Autentiseringsnivå för användarcertifikat	multiFactorAuthentication
   Typ av autentiseringsnivå för användarcertifikat	PolicyId Detta visar att princip-OID användes för att fastställa autentiseringsstyrkan.
   Identifierare för autentiseringsnivå för användarcertifikat	1.2.3.4 Detta visar värdet för OID för identifierarprincipen från certifikatet.

Förstå felsidan för certifikatbaserad autentisering

Certifikatbaserad autentisering kan misslyckas av orsaker som att certifikatet är ogiltigt eller att användaren har valt fel certifikat eller ett utgånget certifikat, eller på grund av ett problem med listan över återkallade certifikat (CRL). När certifikatverifieringen misslyckas ser användaren följande fel:

Om CBA misslyckas i en webbläsare, även om felet beror på att du avbryter certifikatväljaren, måste du stänga webbläsarsessionen och öppna en ny session för att försöka med CBA igen. En ny session krävs eftersom webbläsare cachelagrar certifikatet. När CBA görs om skickar webbläsaren det cachelagrade certifikatet under TLS-utmaningen, vilket orsakar inloggningsfel och valideringsfelet.

Välj Mer information för att få loggningsinformation som kan skickas till en administratör, som i sin tur kan få mer information från inloggningsloggarna.

Välj Andra sätt att logga in på för att prova andra metoder som är tillgängliga för användaren att logga in på.

Kommentar

Om du försöker med CBA igen i en webbläsare fortsätter det att misslyckas på grund av cachelagringsproblemet i webbläsaren. Användarna måste öppna en ny webbläsarsession och logga in igen.

Certifikatbaserad autentisering i MostRecentlyUsed-metoder (MRU)

När en användare har autentiserats med cba är användarens autentiseringsmetod MostRecentlyUsed (MRU) inställd på CBA. Nästa gång användaren anger sitt UPN och väljer Nästa, tas användaren direkt till CBA-metoden och behöver inte välja Använd certifikatet eller smartkortet.

För att återställa MRU-metoden måste användaren avbryta certifikatväljaren, välja Andra sätt att logga in och välja en annan metod som är tillgänglig för användaren och autentiseras korrekt.

Stöd för extern identitet

En extern identitet kan inte utföra multifaktorautentisering till resursklientorganisationen med Microsoft Entra CBA. Låt i stället användaren utföra MFA med hjälp av CBA i hemklientorganisationen och konfigurera inställningar för flera klientorganisationer så att resursklientorganisationen kan lita på MFA från hemklientorganisationen.

Mer information om hur du aktiverar betrodd multifaktorautentisering från Microsoft Entra-klienter finns i Konfigurera B2B-samarbete mellan klientorganisationer.

Nästa steg

• Översikt över Microsoft Entra CBA
• Så här konfigurerar du Microsoft Entra CBA
• Microsoft Entra CBA på iOS-enheter
• Microsoft Entra CBA på Android-enheter
• Inloggning med Windows-smartkort med Microsoft Entra CBA
• Certifikatanvändar-ID:t
• Så här migrerar du federerade användare
• Vanliga frågor och svar
• Felsöka Microsoft Entra CBA