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 aktiverar jag 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 telefoninloggning 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 avsedd för offentligt Microsoft 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 tips för utfärdare.

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

   

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.

Förstå tips för utfärdare (förhandsversion)

Utfärdartips skickar tillbaka en betrodd CA-indikation som en del av TLS-handskakningen. Listan över betrodda certifikatutfärdare är inställd på certifikatutfärdare som laddats upp av klientorganisationen i Entra-förtroendearkivet. Webbläsarklienten eller den interna programklienten använder tipsen som skickas tillbaka av servern för att filtrera certifikaten som visas i certifikatväljaren. Klienten visar endast de autentiseringscertifikat som utfärdats av certifikatutfärdarna i förtroendearkivet.

Aktivera tips för utfärdare

Om du vill aktivera klickar du på kryssrutan Utfärdartips. Administratörer av autentiseringsprinciper bör klicka på Jag bekräftar när du har kontrollerat att proxyn med TLS-inspektionen är korrekt uppdaterad och spara.

Uppdateringsspridning för CA-förtroendearkiv

När du aktiverar tips för utfärdare och lägger till, uppdaterar eller tar bort certifikatutfärdare från förtroendetillståndet finns det en fördröjning på upp till 10 minuter för att sprida utfärdarens tips tillbaka till klienten. Användare kan inte autentisera med certifikat som utfärdats av de nya certifikatutfärdarna förrän tipsen sprids.

Administratörer av autentiseringsprinciper bör logga in med ett certifikat när de har aktiverat tips för utfärdare för att initiera spridningen. Användarna ser felmeddelandet nedan när CA-förtroendelagringsuppdateringar sprids.

MFA-kapacitet för certifikatbaserad autentisering

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

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 nyckelnycklar (andra faktorn)
2. CBA (första faktorn) och lösenordslös inloggning via telefon (andra faktorn)
3. CBA (första faktorn) och FIDO2-säkerhetsnycklar (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.

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

MFA med certifikatbaserad autentisering som andra faktor (förhandsversion)

CBA kan användas som en andra faktor som Lösenord (första faktorn) och CBA (andra faktorn) för att få MFA.

Förstå autentiseringsbindningsprincipen

Autentiseringsbindningsprincipen hjälper till att fastställa styrkan i autentiseringen som antingen en faktor eller multifaktor. Administratörer av autentiseringsprinciper 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ärdar- och princip-OID-fält i certifikatet.

Certifikatstyrkor

Administratörer av autentiseringsprinciper 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).

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
SKIDA	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	hög tillhörighet
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	certificateUserIds	hög tillhörighet
IssuerAndSerialNumber (förhandsversion)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT 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 administratören för autentiseringsprincip i konfigurationen för CBA-autentiseringsmetod som sorteras 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 för autentiseringsprinciper kan hantera ett certifikat till flera konfigurationer av Microsoft Entra-användarkonton.

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 Microsoft 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>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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ändarnamnbindningen är inställd på att peka på fältet certificateUserIds för att söka efter den specifika bindningstypen (det vill säga 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 (det vill säga stark autentisering), till exempel Issuer + SerialNumber, kan det se ut så här:

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

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 Microsoft Entra ID.

Stöd för ett certifikat med flera Microsoft 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.

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 (det vill: Administratörer av autentiseringsprinciper 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 (det vill säga 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>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

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.

Hybridsynkronerade konton För synkroniserade konton kommer metoden att vara annorlunda. Administratörer av autentiseringsprinciper kan mappa unika värden till varje användarkonto som ska använda certifikatet, men det skulle vara svårt att fylla i alla värden i varje konto i Microsoft Entra-ID. I stället bör Microsoft Entra Connect filtrera önskade värden per konto till unika värden som fylls i i kontot i Microsoft Entra-ID. Unikhetsregeln gäller inom gränsen för en enskild katalog/klientorganisation (det vill: Administratörer av autentiseringsprinciper 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 med användare till en enda Microsoft Entra-klientorganisation. I det här fallet tillämpar Microsoft Entra Connect 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 för att inkludera önskat certifikatvärde för den typen av användarkonto (till exempel detaljerad information, administratör, utvecklare och så vidare). Välj ett nyckelattribut i AD som talar om för synkroniseringen vilken användarkontotyp användaren utvärderar (till exempel 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>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Skog 1 – Konto2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Skog 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

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

Steg för att synkronisera med certificateUserIds

1. Konfigurera Microsoft Entra Connect för att lägga till fältet alternativeSecurityIds i Metaverse
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 Microsoft 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 Microsoft 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 Microsoft 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

Processen för återkallande av certifikat gör det möjligt för administratörer av autentiseringsprinciper att å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.

Administratörer av autentiseringsprinciper 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.

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 enligt gränserna på tjänstsidan (45 MB i offentligt Microsoft Entra-ID och 150 MB i Azure US Government-moln).

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 uppdateringsdatum och, 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.

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.

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

Förstå CRL-validering (förhandsversion)

En crl är en post med digitala certifikat som har återkallats före slutet av giltighetsperioden av en certifikatutfärdare (CA). När certifikatutfärdare laddas upp till Microsoft Entra-förtroendearkivet krävs inte en CRL, eller mer specifikt attributet CrlDistributionPoint. En certifikatutfärdare kan laddas upp utan en CRL-slutpunkt, och certifikatbaserad autentisering misslyckas inte om en utfärdande certifikatutfärdare inte har angett någon CRL.

För att stärka säkerheten och undvika felkonfigurationer kan en administratör för autentiseringsprinciper kräva att CBA-autentisering misslyckas om ingen CRL har konfigurerats för en certifikatutfärdare som utfärdar ett slutanvändarcertifikat.

Aktivera CRL-validering

Om du vill aktivera CRL-validering klickar du på Kräv CRL-validering (rekommenderas).

När detta har aktiverats misslyckas cba-certifikatet om slutanvändarcertifikatet har utfärdats av en certifikatutfärdare utan konfigurerad CRL.

En administratör för autentiseringsprinciper kan undanta en ca om dess crl har problem som bör åtgärdas. Klicka på Lägg till undantag och välj eventuella certifikatutfärdare som ska undantas.

Certifikatutfärdarna i den undantagna listan behöver inte ha crl konfigurerat och slutanvändarcertifikaten som de utfärdar misslyckas inte med autentiseringen.

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

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 för autentiseringsprinciper 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 hämta loggningsinformation som kan skickas till en administratör för autentiseringsprinciper, 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å.

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