Tekniska begrepp för Microsoft Entra-certifikatbaserad autentisering

Den här artikeln beskriver tekniska begrepp för att förklara hur Microsoft Entra-certifikatbaserad autentisering (CBA) fungerar. Få den tekniska bakgrunden för att bättre veta hur du konfigurerar och hanterar Microsoft Entra CBA i din klientorganisation.

Hur fungerar Microsoft Entra-certifikatbaserad autentisering?

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

Följande steg sammanfattar Microsoft Entra CBA-processen:

1. En användare försöker komma åt ett program, till exempel MyApps-portalen.

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

3. De anger sitt användarnamn på inloggningssidan för Microsoft Entra och väljer sedan Nästa. Microsoft Entra ID slutför identifiering av hemsfär med hjälp av klientorganisationens namn. Det använder användarnamnet för att leta upp användaren i klientorganisationen.

   

4. Microsoft Entra ID kontrollerar om CBA har konfigurerats för klientorganisationen. Om CBA har konfigurerats 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 har konfigurerats för klientorganisationen.

   Mer information finns i Hur aktiverar vi Microsoft Entra CBA?.

   Kommentar

   Om CBA har konfigurerats för klientorganisationen ser alla användare länken Använd ett certifikat eller smartkort på inloggningssidan för lösenord. Men endast användare som är i omfånget för CBA kan autentisera för ett program som använder Microsoft Entra-ID som identitetsprovider.

   

   Om du gör andra autentiseringsmetoder tillgängliga, till exempel telefoninloggning eller säkerhetsnycklar, kan användarna se en annan inloggningsdialogruta.

   

5. När användaren har valt CBA omdirigeras klienten till slutpunkten för certifikatautentisering. För offentligt Microsoft Entra-ID är https://certauth.login.microsoftonline.comslutpunkten för certifikatautentisering . För Azure Government är https://certauth.login.microsoftonline.usslutpunkten för certifikatautentisering .

   Slutpunkten utför ömsesidig TLS-autentisering (Transport Layer Security) och begär klientcertifikatet som en del av TLS-handskakningen. En postering för den här begäran visas i inloggningsloggen.

   Kommentar

   En administratör bör tillåta åtkomst till användarens inloggningssida och till *.certauth.login.microsoftonline.com slutpunkten för certifikatautentisering för din molnmiljö. Inaktivera TLS-inspektion på slutpunkten för certifikatautentisering för att säkerställa att klientcertifikatbegäran lyckas som en del av TLS-handskakningen.

   Se till att det även fungerar för utfärdartips med den nya URL:en att stänga av TLS-inspektionen. Hårdkoda inte URL:en med klientorganisations-ID:t. Klientorganisations-ID:t kan ändras för B2B-användare (business-to-business). Använd ett reguljärt uttryck för att tillåta att både den tidigare URL:en och den nya URL:en fungerar när du inaktiverar TLS-inspektion. 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 CBA om du aktiverar tips för utfärdare.

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

   

7. Microsoft Entra-ID verifierar listan över återkallade certifikat (CRL) för att se till att certifikatet inte har återkallats och att det ä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 via en microsoft entra-princip för villkorsstyrd åtkomst som kräver multifaktorautentisering (MFA) 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 lösenordslös inloggning och FIDO2 som andra faktorer om användaren redan är registrerad.

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

Om användarinloggningen lyckas kan användaren komma åt programmet.

Tips för utfärdare (förhandsversion)

Utfärdartips skickar tillbaka en betrodd CA-indikator som en del av TLS-handskakningen. Listan över betrodda certifikatutfärdare är inställd på de certifikatutfärdare som klientorganisationen laddar upp till Microsoft Entra-förtroendearkivet. En webbläsarklient eller inbyggd programklient kan använda de tips som servern skickar tillbaka för att filtrera certifikaten som visas i certifikatväljaren. Kunden visar endast de autentiseringscertifikat som utfärdats av certifikatutfärdarna i förtroendebutiken.

Aktivera tips för utfärdare

Om du vill aktivera tips för utfärdare markerar du kryssrutan Tips för utfärdare . En administratör för autentiseringsprinciper bör välja Jag bekräftar när du har kontrollerat att proxyn som har TLS-kontroll har konfigurerats har uppdaterats korrekt och sedan spara ändringarna.

Uppdateringsspridning för CA-förtroendearkiv

När du har aktiverat tips för utfärdare och lagt till, uppdaterat eller tagit bort certifikatutfärdare från förtroendearkivet kan det uppstå en fördröjning på upp till 10 minuter medan utfärdartips sprids tillbaka till klienten. En administratör för autentiseringsprinciper bör logga in med ett certifikat när utfärdartips har gjorts tillgängliga för att initiera spridning.

Användare kan inte autentisera med hjälp av certifikat som utfärdas av nya certifikatutfärdare förrän tips sprids. Användarna ser följande felmeddelande när CA-förtroendelagringsuppdateringar sprids:

MFA med enfaktors-CBA

Microsoft Entra CBA kvalificerar sig för både förstafaktorautentisering och andrafaktorautentisering.

Här följer några kombinationer som stöds:

• CBA (första faktorn) och passkoder (andra faktorn)
• CBA (första faktorn) och lösenordslös inloggning via telefon (andra faktorn)
• CBA (första faktorn) och FIDO2-säkerhetsnycklar (andra faktorn)
• Lösenord (första faktorn) och CBA (andra faktorn) (förhandsversion)

Användare måste ha ett sätt att hämta MFA och registrera lösenordslös inloggning eller FIDO2 innan de loggar in med hjälp av Microsoft Entra CBA.

Alternativ för att hämta MFA-kapacitet med enfaktorcertifikat

Microsoft Entra CBA kan vara antingen en faktor eller multifaktor beroende på klientkonfigurationen. Om du aktiverar CBA kan en användare eventuellt slutföra MFA. En användare som har ett enfaktorcertifikat måste använda en annan faktor för att slutföra MFA.

Vi tillåter inte registrering av andra metoder utan att först uppfylla MFA. Om användaren inte har någon annan MFA-metod registrerad och omfånget för CBA kan användaren inte använda identitetsbevis för att registrera andra autentiseringsmetoder och hämta MFA.

Om den CBA-kompatibla användaren bara har ett enfaktorcertifikat och behöver slutföra MFA väljer du något av följande alternativ för att autentisera användaren:

• Användaren kan ange ett lösenord och använda ett enfaktorcertifikat.
• En administratör för autentiseringsprinciper kan utfärda ett tillfälligt åtkomstpass.
• En administratör för autentiseringsprinciper kan lägga till ett telefonnummer och tillåta röst- eller sms-autentisering för användarkontot.

Om den CBA-kompatibla användaren inte har utfärdats något certifikat och behöver slutföra MFA väljer du något av följande alternativ för att autentisera användaren:

• En administratör för autentiseringsprinciper kan utfärda ett tillfälligt åtkomstpass.
• En administratör för autentiseringsprinciper kan lägga till ett telefonnummer och tillåta röst- eller sms-autentisering för användarkontot.

Om den CBA-kompatibla användaren inte kan använda ett multifaktorcertifikat, till exempel om de använder en mobil enhet utan stöd för smartkort, men de behöver slutföra MFA, väljer du något av följande alternativ för att autentisera användaren:

• En administratör för autentiseringsprinciper kan utfärda ett tillfälligt åtkomstpass.
• Användaren kan registrera en annan MFA-metod (när användaren kan använda ett multifaktorcertifikat på en enhet).
• En administratör för autentiseringsprinciper kan lägga till ett telefonnummer och tillåta röst- eller sms-autentisering för användarkontot.

Konfigurera lösenordslös telefoninloggning med CBA

För att lösenordslös telefoninloggning ska fungera inaktiverar du först äldre meddelanden via mobilappen för användaren.

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

2. Slutför stegen som beskrivs i Aktivera lösenordsfri autentisering för telefoninloggning.

   Viktigt!

   Kontrollera att du väljer alternativet Lösenordslös . För alla grupper som du lägger till i lösenordslös telefoninloggning måste du ändra värdet för autentiseringsläge till Lösenordslös. Om du väljer Alla fungerar inte CBA- och lösenordsfri inloggning.

3. Välj Entra-ID>Multifaktorautentisering>Ytterligare molnbaserade inställningar för multifaktorautentisering.

   

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

   

MFA-autentiseringsflöde med hjälp av enfaktorcertifikat och lösenordsfri inloggning

Överväg ett exempel på en användare som har ett enfaktorcertifikat och som har konfigurerats för lösenordslös inloggning. Som användare utför du följande steg:

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

   

2. Välj Använd ett certifikat eller smartkort.

   

   Om du gör andra autentiseringsmetoder tillgängliga, till exempel telefoninloggning eller säkerhetsnycklar, kan användarna se en annan inloggningsdialogruta.

   

3. I klientcertifikatväljaren väljer du rätt användarcertifikat och väljer sedan OK.

   

4. Eftersom certifikatet är konfigurerat för att vara styrkan i enfaktorautentisering behöver du en andra faktor för att uppfylla MFA-kraven. Tillgängliga andra faktorer visas i inloggningsdialogrutan. I det här fallet är det lösenordslös 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. I Microsoft Authenticator anger du det nummer som du ser i webbläsaren eller appen.

   

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

Autentiseringsbindningsprincip

Autentiseringsbindningsprincipen hjälper till att ange autentiseringens styrka som antingen en faktor eller multifaktor. En administratör för autentiseringsprinciper kan ändra standardmetoden från enfaktor till multifaktor. En administratör kan också konfigurera anpassade principkonfigurationer antingen med hjälp IssuerAndSubjectav , PolicyOIDeller Issuer och PolicyOID i certifikatet.

Certifikatstyrka

Administratörer av autentiseringsprinciper kan avgöra om certifikatstyrkan är en faktor eller multifaktor. 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 MFA med hjälp av certifikat. En administratör för autentiseringsprinciper bör dock se till att certifikaten skyddas av en PIN-kod eller biometrisk kod som ska betraktas som multifaktor.

Bindningsregler för flera autentiseringsprinciper

Du kan skapa flera regler för anpassade autentiseringsbindningar med hjälp av olika certifikatattribut. Ett exempel är att använda utfärdaren och princip-OID, eller bara princip-OID, eller bara utfärdaren.

Följande sekvens avgör autentiseringsskyddsnivån när anpassade regler överlappar varandra:

1. Utfärdare och 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 och 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. Anpassade regler som använder princip-OID utvärderas. Om du har ett certifikat A med princip-OID för 1.2.3.4.5 och en härledd autentiseringsuppgift B baserat på certifikatet som har en princip-OID för 1.2.3.4.5.6, och den anpassade regeln definieras som en princip-OID som har värdet 1.2.3.4.5 med MFA, uppfyller endast certifikat A MFA. Autentiseringsuppgift B uppfyller endast enfaktorautentisering. Om användaren använde en härledd autentiseringsuppgift under inloggningen och konfigurerades för 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 en binder till enfaktorautentisering och de andra bindningarna till MFA), behandlar du certifikatet som enfaktorautentisering.
5. Anpassade regler som använder utfärdarens certifikatutfärdare utvärderas. Om ett certifikat har matchande princip-OID- och utfärdarregler kontrolleras principens OID alltid först. Om ingen principregel hittas kontrolleras utfärdarbindningarna. Princip-OID har en högre bindningsprioritet med stark autentisering än utfärdaren.
6. Om en certifikatutfärdare ansluter sig till MFA kvalificerar sig alla användarcertifikat som den utfärdar som MFA. Samma logik gäller för enfaktorautentisering.
7. Om en princip-OID binder till MFA kvalificerar sig alla användarcertifikat som inkluderar den här princip-OID:en som en av OID:erna som MFA. (Ett användarcertifikat kan ha flera princip-OID:er.)
8. En certifikatutfärdare kan bara ha en giltig bindning med stark autentisering (det vill: ett certifikat kan inte binda till både enfaktorautentisering och till MFA).

Bindningsprincip för användarnamn

Principen för användarnamnbindning hjälper till att verifiera användarens certifikat. Som standard mappas certifikatets alternativa namn (SAN) huvudnamn i certifikatet userPrincipalName till attributet för användarobjektet för att identifiera användaren.

Uppnå högre säkerhet med hjälp av certifikatbindningar

Microsoft Entra har stöd för sju metoder för att använda certifikatbindningar. I allmänhet betraktas mappningstyper som hög tillhörighet om de baseras på identifierare som du inte kan återanvända, till exempel SubjectKeyIdentifier (SKI) eller SHA1PublicKey. Dessa identifierare ger en högre försäkran om att endast ett enda certifikat kan användas för att autentisera en 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 affinitet. Mer information finns i certificateUserIds.

Definiera och åsidosätta tillhörighetsbindning

En administratör för autentiseringsprinciper kan konfigurera om användare kan autentisera med hjälp av bindningsmappning med låg tillhörighet eller hög tillhörighet.

Ange Obligatorisk tillhörighetsbindning för klientorganisationen, vilket gäller för alla användare. Om du vill åsidosätta standardvärdet för hela klientorganisationen skapar du anpassade regler baserat på utfärdaren och princip-OID, eller bara princip-OID, eller bara utfärdaren.

Bindningsregler för flera användarnamn

För att lösa flera bindningsregler för användarnamnsprinciper använder Microsoft Entra ID bindning med högst prioritet (lägsta antal):

1. Söker efter användarobjektet med hjälp av användarnamnet eller UPN.
2. Hämtar listan över alla användarnamnsbindningar som konfigurerats av administratören för autentiseringsprincip i CBA-metodkonfigurationen som sorteras efter priority attributet. För närvarande visas inte prioritet i administrationscentret. Microsoft Graph returnerar attributet priority för varje bindning. Sedan används prioriteringar i utvärderingsprocessen.
3. Om klientorganisationen har konfigurerat bindning med hög tillhörighet eller om certifikatvärdet matchar en anpassad regel som kräver bindning med hög tillhörighet tar du bort alla bindningar med låg tillhörighet från listan.
4. Utvärderar 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.
   • Om en match hittas är användarautentiseringen lyckad.
   • Om en matchning inte hittas flyttas 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. Validerar 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-konfigurationen med hjälp av flera användarnamnsbindningar

Vart och ett av de Microsoft Entra-användarobjektattribut som är tillgängliga för att binda certifikat till Microsoft Entra-användarkonton (userPrincipalName, onPremiseUserPrincipalNameoch certificateUserIds) 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. En administratör för autentiseringsprinciper kan hantera ett certifikat som används i flera konfigurationer av Microsoft Entra-användarkonton.

Du har till exempel två användarnamnsbindningar på PrincipalName mappade till UPNoch SubjectKeyIdentifier (SKI) mappas till certificateUserIds. Om du bara vill att ett certifikat ska användas för ett enda konto måste en administratör för autentiseringsprinciper se till att kontot har det UPN som finns i certifikatet. Sedan implementerar administratören mappningen SKI i certificateUserIds attributet för samma konto.

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

I vissa scenarier utfärdar en organisation flera certifikat för en enda identitet. Det kan vara en härledd autentiseringsuppgift för en mobil enhet, men det kan också vara för ett sekundärt smartkort eller en innehavare av X.509-autentiseringsuppgifter, till exempel en YubiKey.

Endast molnkonton (M:1)

För endast molnkonton kan du mappa upp till fem certifikat som ska användas genom att fylla i certificateUserIds fältet med unika värden för att identifiera varje certifikat. Om du vill mappa certifikaten går du till fliken Auktoriseringsinformation i administrationscentret.

Om organisationen använder bindningar med hög tillhörighet som IssuerAndSerialNumberkan värden i certificateUserIds se ut som i följande exempel:

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. Det andra värdet representerar X509Certificate2. Användaren kan visa något av certifikaten vid inloggningen. Om CBA-användarnamnbindningen är inställd på att certificateUserIds peka på fältet för att söka efter den specifika bindningstypen (i det här exemplet IssuerAndSerialNumber), loggar användaren in.

Hybridsynkronerade konton (M:1)

För synkroniserade konton kan du mappa flera certifikat. Fyll i altSecurityIdentities fältet i den lokala Active Directory med de värden som identifierar varje certifikat. Om din organisation använder bindningar med hög tillhörighet (det vill säga stark autentisering) som IssuerAndSerialNumberkan värdena 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. Det andra värdet representerar X509Certificate2. Värdena måste sedan synkroniseras till fältet certificateUserIds i Microsoft Entra-ID.

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

I vissa scenarier kräver en organisation att en användare använder samma certifikat för att autentisera till flera identiteter. Det kan vara för ett administrativt konto eller för ett utvecklarkonto eller ett tillfälligt tjänstkonto.

I den lokala Active Directory fyller fältet altSecurityIdentities i certifikatvärdena. Ett tips används under inloggningen för att dirigera Active Directory till det avsedda kontot för att söka efter inloggning.

Microsoft Entra CBA har en annan process och inget tips ingår. I stället identifierar identifiering av hemsfär det avsedda kontot och kontrollerar certifikatvärdena. Microsoft Entra CBA framtvingar också unikhet i fältet certificateUserIds . Två konton kan inte fylla i samma certifikatvärden.

Endast molnkonton (1:M)

För endast molnbaserade konton skapar du flera användarnamnsbindningar och mappar unika värden till varje användarkonto som använder certifikatet. Åtkomst till varje konto autentiseras med hjälp av en annan användarnamnsbindning. Den här autentiseringsnivån gäller för gränsen för en enskild katalog eller klientorganisation. En administratör för autentiseringsprinciper kan mappa certifikatet så att det används i en annan katalog eller klientorganisation om värdena förblir unika per konto.

Fyll i fältet certificateUserIds med ett unikt värde som identifierar certifikatet. Om du vill fylla i fältet går du till fliken Auktoriseringsinformation i administrationscentret.

Om organisationen använder bindningar med hög tillhörighet (det vill säga stark autentisering) som IssuerAndSerialNumber och SKIkan värdena se ut som i följande exempel:

Användarnamnsbindningar:

• IssuerAndSerialNumber > certificateUserIds
• SKI > certificateUserIds

certificateUserIds Användarkontovärden:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

När någon av användarna nu visar samma certifikat vid inloggningen loggar användaren in eftersom deras konto matchar ett unikt värde på certifikatet. Ett konto autentiseras med hjälp IssuerAndSerialNumber av och det andra med hjälp av bindning SKI .

Hybridsynkronerade konton (1:M)

Synkroniserade konton kräver en annan metod. Även om en administratör för autentiseringsprinciper kan mappa unika värden till varje användarkonto som använder certifikatet, gör den här metoden svår att fylla i alla värden för varje konto i Microsoft Entra-ID. I stället bör Microsoft Entra Connect filtrera värdena per konto till unika värden som fylls i i kontot i Microsoft Entra-ID. Unikhetsregeln gäller för gränsen för en enskild katalog eller klientorganisation. En administratör för autentiseringsprinciper kan mappa certifikatet så att det används i en annan katalog eller klientorganisation om värdena förblir unika per konto.

Organisationen kan också ha flera Active Directory-skogar som bidrar användare till en enda Microsoft Entra-klientorganisation. I det här fallet tillämpar Microsoft Entra Connect filtret på var och en av Active Directory-skogarna med samma mål: fyll endast i ett specifikt unikt värde för molnkontot.

Fyll i fältet altSecurityIdentities i Active Directory med de värden som identifierar certifikatet. Inkludera det specifika certifikatvärdet för den användarkontotypen (till exempel detailed, admineller developer). Välj ett nyckelattribut i Active Directory. Attributet talar om för synkronisering vilken användarkontotyp som användaren utvärderar (till exempel msDS-cloudExtensionAttribute1). Fyll i det här attributet med det användartypsvärde som du vill använda, till exempel detailed, admineller developer. Om kontot är användarens primära konto kan värdet vara tomt eller NULL.

Kontrollera att kontona ser ut ungefär 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

Du måste sedan synkronisera dessa värden till fältet certificateUserIds i Microsoft Entra-ID.

Så här synkroniserar du till certificateUserIds:

1. Konfigurera Microsoft Entra Connect för att lägga till fältet alternativeSecurityIds i metaversumet.
2. För varje lokal Active Directory-skog konfigurerar du en ny anpassad regel för inkommande trafik med hög prioritet (ett lågt tal, under 100). Lägg till en Expression transformering med fältet altSecurityIdentities som källa. Måluttrycket använder nyckelattributet som du har valt och fyllt i, och det använder mappningen till de användartyper som du definierade.

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 det här exemplet altSecurityIdentities kontrolleras först nyckelattributet msDS-cloudExtensionAttribute1 för att se om de är ifyllda. Om de inte är ifyllda altSecurityIdentities kontrolleras om de är ifyllda. Om den är tom ställer du in den på NULL. Annars är kontot ett standardscenario.

I det här exemplet filtrerar du endast på mappningen IssuerAndSerialNumber . Om nyckelattributet är ifyllt kontrolleras värdet för att se om det är lika med någon av dina definierade användartyper. Om värdet i exemplet är detailedfiltrerar du på värdet SHA1PublicKey från altSecurityIdentities. Om värdet är developerfiltrerar du på värdet SubjectKeyIssuer från altSecurityIdentities.

Du kan stöta på flera certifikatvärden av en viss typ. Du kan till exempel se flera PrincipalName värden eller flera SKI eller SHA1-PUKEY värden. Filtret hämtar alla värden och synkroniserar dem i Microsoft Entra-ID, inte bara det första som hittas.

Här är ett andra exempel som visar hur du push-överför ett tomt värde om kontrollattributet är tomt:

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 altSecurityIdentities inte matchar något av sökvärdena i kontrollattributet skickas ett AuthoritativeNull värde. Det här värdet säkerställer att tidigare eller efterföljande regler som fylls alternativeSecurityId i ignoreras. Resultatet är tomt i Microsoft Entra-ID.

Så här synkroniserar du ett tomt värde:

1. Konfigurera en ny anpassad regel för utgående trafik med låg prioritet (ett högt tal, över 160 men längst ned i listan).
2. Lägg till en direkt transformering med fältet alternativeSecurityIds som källa och certificateUserIds fält 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 användarnamnbindningarna som pekar på certificateUserIds fältet för de fälttyper som du mappade från certifikatet. Nu kan någon av dessa användare presentera certifikatet vid inloggning. När det unika värdet från certifikatet har verifierats mot certificateUserIds fältet loggas användaren in.

Omfång för certifikatutfärdare (CA) (förhandsversion)

Ca-omfång i Microsoft Entra gör det möjligt för klientadministratörer att begränsa användningen av specifika certifikatutfärdare till definierade användargrupper. Den här funktionen förbättrar säkerheten och hanterbarheten för cba genom att se till att endast behöriga användare kan autentisera med hjälp av certifikat som utfärdats av specifika certifikatutfärdare.

CA-omfång är användbart i scenarier med flera PKI eller B2B där flera certifikatutfärdare används i olika användarpopulationer. Det hjälper till att förhindra oavsiktlig åtkomst och stöder efterlevnad av organisationsprinciper.

Viktiga fördelar

• Begränsar certifikatanvändningen till specifika användargrupper
• Stöder komplexa PKI-miljöer via flera certifikatutfärdare
• Ger förbättrat skydd mot missbruk av certifikat eller komprometterande
• Ger insyn i CA-användning via inloggningsloggar och övervakningsverktyg

En administratör kan använda CA-omfång för att definiera regler som associerar en ca (identifierad av dess SKI) med en specifik Microsoft Entra-grupp. När en användare försöker autentisera med hjälp av ett certifikat kontrollerar systemet om den utfärdande certifikatutfärdare för certifikatet är begränsad till en grupp som innehåller användaren. Microsoft Entra fortsätter upp i CA-kedjan. Den tillämpar alla omfångsregler tills användaren hittas i en av grupperna i alla omfångsregler. Om användaren inte finns i den begränsade gruppen misslyckas autentiseringen, även om certifikatet annars är giltigt.

Konfigurera ca-omfångsfunktionen

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

2. Gå till Entra ID-autentiseringsmetoder>>Certifikatbaserad autentisering.

3. Under Konfigurera går du till Omfångsprincip för certifikatutfärdare.

   

4. Välj Lägg till regel.

   

5. Välj Filtrera certifikatutfärdare efter PKI.

   Klassiska certifikatutfärdare visar alla certifikatutfärdare från den klassiska CA-butiken. Om du väljer en specifik PKI visas alla certifikatutfärdare från den valda PKI:en.

6. Välj en PKI.

   

7. Listan Certifikatutfärdare visar alla certifikatutfärdare från den valda PKI:en. Välj en certifikatutfärdare för att skapa en omfångsregel.

   

8. Välj Lägg till grupp.

   

9. Välj en grupp.

   

10. Välj Lägg till för att spara regeln.

    

11. Markera kryssrutan Jag bekräftar och välj sedan Spara.

    

12. Om du vill redigera eller ta bort en CA-omfångsprincip väljer du "..." på regelraden. Om du vill redigera regeln väljer du Redigera. Om du vill ta bort regeln väljer du Ta bort.

    

Kända begränsningar

• Endast en grupp kan tilldelas per CA.
• Högst 30 omfångsregler stöds.
• Omfånget upprätthålls på den mellanliggande CA-nivån.
• Felaktig konfiguration kan resultera i användarutelåsningar om det inte finns några giltiga omfångsregler.

Inloggningsposter

• Inloggningsloggen visar framgång. På fliken Ytterligare information visas CA:ens SKI från omfångsprincipregeln.

  

• När en cba misslyckas på grund av en ca-omfångsregel visar fliken Grundläggande information i inloggningsloggen felkoden 500189.

  

  Slutanvändarna ser följande felmeddelande:

  

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

Du kan använda den inbyggda MFA-autentiseringsstyrkan som är resistent mot nätfiske i Microsoft Entra för att skapa en princip för autentisering med villkorsstyrd åtkomst som anger att du ska använda CBA för att komma åt en resurs. Principen tillåter endast autentiseringsmetoder som är nätfiskeresistenta, till exempel 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 enfaktorautentisering, MFA eller både och. Mer information finns i autentiseringsstyrkan för villkorsstyrd åtkomst.

CBA-styrka med avancerade alternativ

I CBA-metodprincipen kan en administratör för autentiseringsprinciper fastställa certifikatets styrka med hjälp av en autentiseringsbindningsprincip för CBA-metoden. Nu kan du kräva att ett specifikt certifikat används baserat på utfärdare och princip-OID när användare utför CBA för att få åtkomst till vissa känsliga resurser. När du skapar en anpassad autentiseringsstyrka går du till Avancerade alternativ. 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.

Inloggningsloggar

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

Överväg sedan två scenarier. I ett scenario uppfyller certifikatet enfaktorautentisering. I det andra scenariot uppfyller certifikatet MFA.

I testscenarierna väljer du en användare som har en princip för villkorsstyrd åtkomst som kräver MFA.

Konfigurera användarbindningsprincipen genom att mappa Alternativt namn för ämne och Huvudnamn till userPrincipalName användarobjektet.

Användarcertifikatet ska konfigureras som exemplet som visas i den här skärmbilden:

Felsöka inloggningsproblem med dynamiska variabler i inloggningsloggar

Inloggningsloggar ger vanligtvis all information du behöver för att felsöka ett inloggningsproblem, men ibland krävs specifika värden. Inloggningsloggar stöder inte dynamiska variabler, så i vissa fall har inloggningsloggarna inte den information du behöver för felsökning.

Felorsaken i inloggningsloggarna kan till exempel visas "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." i det här scenariot<expectedSKI> och <crlAKI> fylls inte med rätt värden.

När användarinloggningen med CBA misslyckas kan du kopiera logginformationen från länken Mer information på felsidan. Mer information finns i Förstå CBA-felsidan.

Testa enfaktorautentisering

I det första testscenariot konfigurerar du autentiseringsprincipen där IssuerAndSubject regeln uppfyller enfaktorautentisering.

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

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

   Nästa bild visar några av de poster som du kan hitta i inloggningsloggarna.

   Den första posten begär X.509-certifikatet från användaren. Den avbrutna statusen innebär att Microsoft Entra-ID verifierade att CBA har konfigurerats för klientorganisationen. Ett certifikat begärs för autentisering.

   

   Aktivitetsinformation visar att begäran är en del av det förväntade inloggningsflödet där användaren väljer ett certifikat.

   

   Ytterligare information visar certifikatinformationen.

   

   De andra posterna visar att autentiseringen är klar, en primär uppdateringstoken skickas tillbaka till webbläsaren och användaren beviljas åtkomst till resursen.

   

Testa MFA

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

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

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

   Flera poster i inloggningsloggarna visas, inklusive en post med statusen Avbryten .

   

   Aktivitetsinformation visar att begäran är en del av det förväntade inloggningsflödet där användaren väljer ett certifikat.

   

   Posten med statusen Avbrytd visar 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: PrincipalName; användarattribut: userPrincipalName; Rangordning: 1 Det här fältet visar vilket SAN-certifikatfält PrincipalName som mappades till användarattributet userPrincipalName och var prioritet 1.
   Autentiseringsnivå för användarcertifikat	multiFactorAuthentication
   Typ av autentiseringsnivå för användarcertifikat	PolicyId Det här fältet 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 identifieringspolicyns OID-värde från certifikatet.

CBA-felsida

CBA kan misslyckas av flera orsaker. Exempel är ett ogiltigt certifikat, att användaren har valt fel certifikat eller ett utgånget certifikat eller att ett CRL-problem uppstår. När certifikatverifieringen misslyckas visas det här felmeddelandet:

Om CBA misslyckas i en webbläsare, även om felet beror på att du avbryter certifikatväljaren, stänger du webbläsarsessionen. Öppna en ny session för att prova CBA igen. En ny session krävs eftersom webbläsare cachelagrar certifikat. När CBA görs om skickar webbläsaren ett cachelagrat certifikat under TLS-utmaningen, vilket sedan orsakar inloggningsfel och valideringsfel.

1. Om du vill få loggningsinformation att skicka till en administratör för autentiseringsprinciper för mer information från inloggningsloggarna väljer du Mer information.

   

2. Välj Andra sätt att logga in på och prova andra tillgängliga autentiseringsmetoder för att logga in.

   

Återställa certifikatvalet i Microsoft Edge

Microsoft Edge-webbläsaren har lagt till en funktion som återställer certifikatvalet utan att starta om webbläsaren.

Användaren utför följande steg:

1. När CBA misslyckas visas felsidan.

   

2. Till vänster om adress-URL:en väljer du låsikonen och sedan Dina certifikatval.

   

3. Välj Återställ certifikatval.

   

4. Välj Återställ alternativ.

   

5. Välj Andra sätt att logga in på.

   

6. Välj Använd ett certifikat eller smartkort och fortsätt med CBA-autentisering.

CBA i MostRecentlyUsed-metoder

När en användare har autentiserats med hjälp av CBA anges användarens MostRecentlyUsed autentiseringsmetod (MRU) till CBA. Nästa gång användaren anger sitt UPN och väljer Nästa, ser de CBA-metoden och behöver inte välja Använd certifikatet eller smartkortet.

Om du vill återställa MRU-metoden avbryter du certifikatväljaren och väljer sedan Andra sätt att logga in på. Välj en annan tillgänglig metod och slutför sedan autentiseringen.

MRU-autentiseringsmetoden anges på användarnivå. Om en användare loggar in på en annan enhet med hjälp av en annan autentiseringsmetod återställs MRU för användaren till den för tillfället inloggade metoden.

Stöd för extern identitet

En extern B2B-gästanvändare kan använda CBA i hemklientorganisationen. Om inställningarna mellan klientorganisationer för resursklientorganisationen har konfigurerats för att lita på MFA från hemklientorganisationen respekteras användarens cba på hemklientorganisationen. Mer information finns i Konfigurera B2B-samarbete mellan klientorganisationer. För närvarande stöds inte CBA på en resursklientorganisation.

Relaterat innehåll

• Översikt över Microsoft Entra CBA
• Konfigurera Microsoft Entra CBA
• Microsoft Entra CBA-certifikatåterkallningslista
• Microsoft Entra CBA på iOS-enheter
• Microsoft Entra CBA på Android-enheter
• Inloggning med Windows-smartkort med hjälp av Microsoft Entra CBA
• Certifikatanvändar-ID:t
• Migrera federerade användare
• Vanliga frågor och svar
• Felsöka Microsoft Entra CBA