Technické koncepty ověřování založené na certifikátech microsoft Entra

Tento článek popisuje technické koncepty, které vysvětlují, jak funguje ověřování na základě certifikátů (CBA) společnosti Microsoft Entra. Získejte technické znalosti, abyste lépe věděli, jak ve svém tenantovi nastavit a spravovat Microsoft Entra CBA.

Jak funguje ověřování založené na certifikátech společnosti Microsoft Entra?

Následující obrázek znázorňuje, co se stane, když se uživatel pokusí přihlásit k aplikaci v tenantovi, který má nakonfigurovanou sadu Microsoft Entra CBA.

Následující kroky shrnují proces Microsoft Entra CBA:

1. Uživatel se pokusí o přístup k aplikaci, jako je portál Moje aplikace.

2. Pokud uživatel ještě není přihlášený, bude přesměrován na přihlašovací stránku uživatele Microsoft Entra ID na adrese https://login.microsoftonline.com/.

3. Zadají svoje uživatelské jméno na přihlašovací stránce Microsoft Entra a pak vyberou Další. Id Microsoft Entra dokončí zjišťování domovské sféry pomocí názvu tenanta. Pomocí uživatelského jména vyhledá uživatele v tenantovi.

   

4. ID Microsoft Entra kontroluje, jestli je pro tenanta nastavená CBA. Pokud je CBA nastavená, zobrazí se uživateli odkaz na použití certifikátu nebo čipové karty na stránce s heslem. Pokud se uživateli nezobrazuje přihlašovací odkaz, ujistěte se, že je pro tenanta nastavený jazyk CBA.

   Další informace naleznete v tématu Jak zapneme Microsoft Entra CBA?.

   Poznámka:

   Pokud je pro tenanta nastavený CBA, uvidí všichni uživatelé odkaz Použít certifikát nebo čipovou kartu na přihlašovací stránce hesla. Pro aplikaci, která jako zprostředkovatele identity používá Microsoft Entra ID, se ale můžou úspěšně ověřit jenom uživatelé, kteří jsou v oboru CBA.

   

   Pokud zpřístupníte jiné metody ověřování, jako je přihlášení telefonem nebo bezpečnostní klíče, můžou se uživatelům zobrazit jiné přihlašovací dialogové okno.

   

5. Jakmile uživatel vybere CBA, klient se přesměruje na koncový bod ověřování certifikátu. Pro veřejné ID Microsoft Entra je https://certauth.login.microsoftonline.comkoncový bod ověřování certifikátu . Pro Azure Government je https://certauth.login.microsoftonline.uskoncový bod ověřování certifikátu .

   Koncový bod provádí vzájemné ověřování TLS (Transport Layer Security) a v rámci metody handshake protokolu TLS požaduje klientský certifikát. V protokolu přihlášení se zobrazí položka pro tento požadavek.

   Poznámka:

   Správce by měl povolit přístup k přihlašovací stránce uživatele a koncovému *.certauth.login.microsoftonline.com bodu ověřování certifikátu pro vaše cloudové prostředí. Vypněte kontrolu protokolu TLS na koncovém bodu ověřování certifikátu, abyste zajistili, že požadavek na klientský certifikát bude úspěšný jako součást metody handshake protokolu TLS.

   Ujistěte se, že vypnutí kontroly protokolu TLS funguje také pro rady vystavitele s novou adresou URL. Nezakódujte adresu URL pomocí ID tenanta. ID tenanta se může změnit pro uživatele B2B (Business-to-Business). Regulární výraz umožňuje, aby předchozí adresa URL i nová adresa URL fungovaly, když vypnete kontrolu protokolu TLS. Například v závislosti na proxy serveru použijte *.certauth.login.microsoftonline.com nebo *certauth.login.microsoftonline.com. V Azure Government použijte *.certauth.login.microsoftonline.us nebo *certauth.login.microsoftonline.us.

   Pokud přístup není povolený, CBA selže, pokud zapnete rady vystavitele.

6. Microsoft Entra ID požaduje klientský certifikát. Uživatel vybere klientský certifikát a pak vybere OK.

   

7. Microsoft Entra ID ověřuje seznam odvolaných certifikátů (CRL), aby se ujistil, že certifikát není odvolán a že je platný. Id Microsoft Entra identifikuje uživatele pomocí vazby uživatelského jména nakonfigurované v tenantovi k mapování hodnoty pole certifikátu na hodnotu atributu uživatele.

8. Pokud se jedinečný uživatel najde prostřednictvím zásad podmíněného přístupu Microsoft Entra, které vyžadují vícefaktorové ověřování (MFA) a pravidlo vazby ověřování certifikátu splňuje vícefaktorové ověřování, Microsoft Entra ID uživatele okamžitě přihlásí. Pokud se vyžaduje vícefaktorové ověřování, ale certifikát splňuje jenom jeden faktor, pokud je uživatel již zaregistrovaný, nabízí se jako druhý faktor přihlášení bez hesla a FIDO2.

9. Microsoft Entra ID dokončí proces přihlášení tím, že odešle zpět primární obnovovací token, čímž potvrdí úspěšné přihlášení.

Pokud je přihlášení uživatele úspěšné, může uživatel získat přístup k aplikaci.

Rady vystavitele (Preview)

Rady vystavitele odesílají zpět indikátor důvěryhodné certifikační autority jako součást metody handshake protokolu TLS. Seznam důvěryhodných certifikačních autorit je nastavený na předmět certifikačních autorit, které tenant nahraje do úložiště důvěryhodnosti Microsoft Entra. Klient prohlížeče nebo nativní klient aplikace může použít nápovědy, které server odešle zpět k filtrování certifikátů zobrazených v nástroji pro výběr certifikátu. Klient zobrazí pouze ověřovací certifikáty vydané certifikačními autoritami v úložišti důvěryhodnosti.

Zapnutí nápovědy vystavitele

Pokud chcete zapnout rady vystavitele, zaškrtněte políčko Rady vystavitele . Správce zásad ověřování by měl po ověření, že proxy server, který má nastavenou kontrolu protokolu TLS, správně aktualizovat, a pak uložit změny.

Poznámka:

Pokud má vaše organizace brány firewall nebo proxy servery, které používají kontrolu protokolu TLS, potvrďte, že jste vypnuli kontrolu protokolu TLS koncového bodu certifikační autority, který dokáže spárovat libovolný název [*.]certauth.login.microsoftonline.compodle používaného konkrétního proxy serveru.

Poznámka:

Po zapnutí nápovědy vystavitele má adresa URL certifikační autority formát <tenantId>.certauth.login.microsoftonline.com.

Šíření aktualizace úložiště důvěry certifikační autority

Když zapnete rady vystavitele a přidáte, aktualizujete nebo odstraníte certifikační autority z úložiště důvěryhodnosti, může dojít k prodlevě až 10 minut, zatímco se rady vystavitele rozšíří zpět do klienta. Správce zásad ověřování by se měl přihlásit pomocí certifikátu po zpřístupnění nápovědy vystavitele k zahájení šíření.

Uživatelé se nemůžou ověřovat pomocí certifikátů vydaných novými certifikačními autoritami, dokud se nebudou šířit rady. Uživatelům se při šíření aktualizací úložiště důvěryhodnosti certifikační autority zobrazí následující chybová zpráva:

MFA s jednofaktorovým CBA

Microsoft Entra CBA se kvalifikuje pro ověřování first-factor authentication i druhé-factor authentication.

Tady je několik podporovaných kombinací:

• CBA (první faktor) a přístupové klíče (druhý faktor)
• CBA (první faktor) a přihlášení k telefonu bez hesla (druhý faktor)
• CBA (první faktor) a klíče zabezpečení FIDO2 (druhý faktor)
• Heslo (první faktor) a CBA (druhý faktor)

Uživatelé musí mít způsob, jak získat vícefaktorové ověřování a zaregistrovat přihlášení bez hesla nebo FIDO2 před přihlášením pomocí Microsoft Entra CBA.

Důležité

Uživatel se považuje za podporující vícefaktorové ověřování, pokud se jeho uživatelské jméno zobrazí v nastavení metody CBA. V tomto scénáři nemůže uživatel použít svoji identitu jako součást ověřování k registraci dalších dostupných metod. Ujistěte se, že uživatelé bez platného certifikátu nejsou zahrnuti v nastavení metody CBA. Další informace o tom, jak ověřování funguje, naleznete v tématu Vícefaktorové ověřování Microsoft Entra.

Možnosti získání funkce vícefaktorového ověřování s povoleným CBA

Microsoft Entra CBA může být buď jednofaktorový, nebo vícefaktorový v závislosti na konfiguraci tenanta. ZapnutíM CBA může uživatel dokončit vícefaktorové ověřování. Uživatel, který má jednofaktorový certifikát nebo heslo, musí k dokončení vícefaktorového ověřování použít jiný faktor.

Nepovolujeme registraci jiných metod bez toho, abychom napřed splňovali vícefaktorové ověřování. Pokud uživatel nemá zaregistrovanou žádnou jinou metodu vícefaktorového ověřování a je v oboru pro CBA, nemůže k registraci jiných metod ověřování a získání vícefaktorového ověřování použít důkaz o identitě.

Pokud má uživatel podporující CBA jenom jednofaktorový certifikát a potřebuje dokončit vícefaktorové ověřování, zvolte jednu z těchto možností pro ověření uživatele:

• Uživatel může zadat heslo a použít jednofaktorový certifikát.
• Správce zásad ověřování může vydat dočasný přístup.
• Správce zásad ověřování může přidat telefonní číslo a povolit ověřování hlasových nebo textových zpráv pro uživatelský účet.

Pokud uživatel podporující CBA nevystavil certifikát a potřebuje dokončit vícefaktorové ověřování, zvolte jednu z těchto možností pro ověření uživatele:

• Správce zásad ověřování může vydat dočasný přístup.
• Správce zásad ověřování může přidat telefonní číslo a povolit ověřování hlasových nebo textových zpráv pro uživatelský účet.

Pokud uživatel podporující CBA nemůže použít vícefaktorový certifikát, například pokud používá mobilní zařízení bez podpory čipových karet, ale musí dokončit vícefaktorové ověřování, zvolte jednu z těchto možností pro ověření uživatele:

• Správce zásad ověřování může vydat dočasný přístup.
• Uživatel může zaregistrovat jinou metodu vícefaktorového ověřování (když uživatel může na zařízení použít vícefaktorový certifikát).
• Správce zásad ověřování může přidat telefonní číslo a povolit ověřování hlasových nebo textových zpráv pro uživatelský účet.

Nastavení přihlášení k telefonu bez hesla pomocí CBA

Aby přihlášení telefonem bez hesla fungovalo, vypněte nejdřív starší oznámení prostřednictvím mobilní aplikace pro uživatele.

1. Přihlaste se do Centra pro správu Microsoft Entra jako alespoň správce zásad ověřování.

2. Dokončete kroky popsané v tématu Povolení ověřování přihlašování telefonem bez hesla.

   Důležité

   Ujistěte se, že jste vybrali možnost bez hesla . U všech skupin, které přidáte do přihlášení k telefonu bez hesla, je nutné změnit hodnotu režimu ověřování na bez hesla. Pokud vyberete Možnost Libovolný, CBA a přihlášení bez hesla nefungují.

3. Vyberte Entra ID>Vícefaktorové ověřování>Další nastavení cloudového vícefaktorového ověřování.

   

4. V části Možnosti ověření zrušte zaškrtnutí políčka Oznámení prostřednictvím mobilní aplikace a pak vyberte Uložit.

   

Tok ověřování vícefaktorového ověřování pomocí jednofaktorových certifikátů a přihlašování bez hesla

Představte si příklad uživatele, který má jednofaktorový certifikát a je nakonfigurovaný pro přihlášení bez hesla. Jako uživatel byste dokončili tyto kroky:

1. Zadejte hlavní název uživatele (UPN) a pak vyberte Další.

   

2. Vyberte Použít certifikát nebo čipovou kartu.

   

   Pokud zpřístupníte jiné metody ověřování, jako je přihlášení telefonem nebo bezpečnostní klíče, můžou se uživatelům zobrazit jiné přihlašovací dialogové okno.

   

3. V nástroji pro výběr klientského certifikátu vyberte správný uživatelský certifikát a pak vyberte OK.

   

4. Vzhledem k tomu, že certifikát je nakonfigurovaný tak, aby byl silnou stránkou jednofaktorového ověřování, potřebujete druhý faktor pro splnění požadavků vícefaktorového ověřování. Dostupné další faktory se zobrazují v dialogovém okně pro přihlášení. V tomto případě se jedná o přihlášení bez hesla. Vyberte Schválit žádost v aplikaci Microsoft Authenticator.

   

5. Na telefonu se zobrazí oznámení. Vyberte Schválit přihlášení?.

6. V Microsoft Authenticatoru zadejte číslo, které vidíte v prohlížeči nebo aplikaci.

   

7. Vyberte Ano a můžete se ověřit a přihlásit.

Zásady vazby ověřování

Zásady vazby ověřování pomáhají nastavit sílu ověřování jako jednofaktorové nebo vícefaktorové. Správce zásad ověřování může změnit výchozí metodu z jednofaktorového na vícefaktorové. Správce může také nastavit vlastní konfigurace zásad buď pomocí IssuerAndSubject, PolicyOIDnebo Issuer a PolicyOID v certifikátu.

Síla certifikátu

Správci zásad ověřování můžou určit, jestli je síla certifikátu jednofaktorová nebo vícefaktorová. Další informace najdete v dokumentaci, která mapuje úrovně ověřování NIST na metody ověřování Microsoft Entra, které vycházejí z NIST 800-63B SP 800-63B, Digital Identity Guidelines: Ověřování a životního cyklu řízení.

Vícefaktorové ověřování certifikátů

Pokud má uživatel vícefaktorový certifikát, může vícefaktorové ověřování provádět pouze pomocí certifikátů. Správce zásad ověřování by se ale měl ujistit, že certifikáty jsou chráněné kódem PIN nebo biometrickým kódem, které se mají považovat za vícefaktorové.

Více pravidel vazeb zásad ověřování

Pomocí různých atributů certifikátu můžete vytvořit několik vlastních pravidel zásad vazby ověřování. Příkladem je použití vystavitele a identifikátoru zásady nebo pouze identifikátoru zásady nebo pouze vystavitele.

Následující posloupnost určuje úroveň ochrany ověřování, když se vlastní pravidla překrývají:

1. Pravidla identifikátorů vystavitele a zásad mají přednost před pravidly OID zásad. Pravidla identifikátoru zásad mají přednost před pravidly vystavitele certifikátů.
2. Pravidla identifikátorů vystavitele a zásad se vyhodnocují jako první. Pokud máte vlastní pravidlo s certifikační autoritou vystavitele CA1 a identifikátorem 1.2.3.4.5 zásad s MFA, dostane se vícefaktorové ověřování pouze certifikát A, který splňuje hodnotu vystavitele i identifikátor zásady.
3. Vyhodnocují se vlastní pravidla, která používají identifikátory OID zásad. Pokud máte certifikát A s identifikátorem 1.2.3.4.5 zásad a odvozenými přihlašovacími údaji B na základě tohoto certifikátu, který má identifikátor 1.2.3.4.5.6zásady , a vlastní pravidlo je definováno jako identifikátor zásady, který má hodnotu 1.2.3.4.5 s vícefaktorovým ověřováním, splňuje MFA pouze certifikát A. Credential B splňuje pouze jednofaktorové ověřování. Pokud uživatel při přihlašování použil odvozené přihlašovací údaje a nakonfiguroval vícefaktorové ověřování, zobrazí se uživateli výzva k úspěšnému ověření.
4. Pokud dojde ke konfliktu mezi několika identifikátory OID zásad (například pokud má certifikát dva identifikátory OID zásad, kdy jeden vytvoří vazbu na jednofaktorové ověřování a druhý s vícefaktorovým ověřováním), pak s certifikátem zachází jako s jednofaktorovým ověřováním.
5. Vyhodnocují se vlastní pravidla, která používají certifikační autority vystavitele. Pokud má certifikát odpovídající identifikátor zásad a pravidla vystavitele, je identifikátor zásady vždy kontrolován jako první. Pokud se nenajde žádné pravidlo zásad, zkontrolují se vazby vystavitele. Identifikátor zásady má vyšší prioritu vazby silného ověřování než vystavitel.
6. Pokud je jedna certifikační autorita propojena s vícefaktorovým ověřováním, všechny uživatelské certifikáty, které vydá, jsou kvalifikovány jako MFA. Stejná logika platí pro jednofaktorové ověřování.
7. Pokud se jeden identifikátor zásady sváže s vícefaktorové ověřování, všechny uživatelské certifikáty, které obsahují tento identifikátor OID zásad, se kvalifikují jako MFA. (Uživatelský certifikát může mít více identifikátorů OID zásad.)
8. Jeden vystavitel certifikátu může mít jenom jednu platnou vazbu silného ověřování (to znamená, že certifikát nemůže svázat s jednofaktorovým ověřováním i s vícefaktorovým ověřováním).

Důležité

V současné době ve známém problému, který se řeší, pokud správce zásad ověřování vytvoří pravidlo zásad CBA pomocí vystavitele i identifikátoru zásad, ovlivní některé scénáře registrace zařízení.

Mezi ovlivněné scénáře patří:

• Registrace Windows Hello pro firmy
• Registrace klíče zabezpečení FIDO2
• Přihlášení k telefonu bez hesla Ve Windows

Registrace zařízení ve scénářích připojení k síti na pracovišti, ID Microsoft Entra a hybridních připojených scénářů Microsoft Entra není ovlivněna. Pravidla zásad CBA, která používají vystavitele nebo identifikátor zásad, nejsou ovlivněna.

Pokud chcete tento problém zmírnit, měl by správce zásad ověřování dokončit jednu z následujících možností:

• Upravte pravidlo zásad CBA, které aktuálně používá vystavitele i identifikátor zásad k odebrání vystavitele nebo požadavku ID zásady.
• Odeberte pravidlo zásad ověřování, které aktuálně používá vystavitele i identifikátor zásady, a pak vytvořte pravidlo, které používá pouze vystavitele nebo identifikátor zásady.

Zásady vazby uživatelského jména

Zásady vazby uživatelského jména pomáhají ověřit certifikát uživatele. Ve výchozím nastavení je hlavní název subjektu (SAN) v certifikátu mapován na userPrincipalName atribut objektu uživatele k identifikaci uživatele.

Dosažení vyššího zabezpečení pomocí vazeb certifikátů

Microsoft Entra podporuje sedm metod pro použití vazeb certifikátů. Obecně platí, že typy mapování se považují za vysoce spřažení, pokud jsou založené na identifikátorech, které nemůžete opakovaně použít, například SubjectKeyIdentifier (SKI) nebo SHA1PublicKey. Tyto identifikátory poskytují vyšší záruku, že k ověření uživatele je možné použít pouze jeden certifikát.

Typy mapování založené na uživatelských jménech a e-mailových adresách se považují za nízké spřažení. Microsoft Entra ID implementuje tři mapování, která jsou považována za nízkou spřažení na základě opakovaně použitelných identifikátorů. Ostatní jsou považovány za vazby s vysokou afinitou. Další informace najdete v tématu certificateUserIds.

Pole mapování certifikátu	Příklady hodnot v certificateUserIds	Atributy objektu uživatele	Typ
PrincipalName	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	Nízká spřažení
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	Nízká spřažení
IssuerAndSubject	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	Nízká spřažení
Subject	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	Nízká spřažení
SKI	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	Vysoká spřažení
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR Hodnota SHA1PublicKey (hash SHA1 celého obsahu certifikátu včetně veřejného klíče) je ve vlastnosti kryptografického otisku certifikátu.	certificateUserIds	Vysoká spřažení
IssuerAndSerialNumber	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT Pokud chcete získat správnou hodnotu sériového čísla, spusťte tento příkaz a uložte hodnotu uvedenou v certificateUserIds: Syntaxe: certutil –dump –v [~certificate path~] >> [~dumpFile path~] Příklad: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	Vysoká spřažení

Důležité

K vyhledání správné CertificateBasedAuthentication hodnoty uživatele v certifikátu můžete použít .

Definice a přepsání vazby spřažení

Správce zásad ověřování může nakonfigurovat, jestli se uživatelé můžou ověřovat pomocí mapování vazby uživatelského jména s nízkou nebo vysokou spřažení.

Nastavte požadovanou vazbu spřažení pro tenanta, která platí pro všechny uživatele. Pokud chcete přepsat výchozí hodnotu pro celého tenanta, vytvořte vlastní pravidla založená na vystavitele a identifikátoru zásady, nebo pouze identifikátoru zásady nebo pouze vystavitele.

Více pravidel vazeb zásad uživatelského jména

K vyřešení více pravidel vazeb zásad uživatelského jména používá ID Microsoft Entra vazbu s nejvyšší prioritou (nejnižší číslo):

1. Vyhledá objekt uživatele pomocí uživatelského jména nebo hlavního názvu uživatele (UPN).
2. Získá seznam všech vazeb uživatelského jména nastavené správcem zásad ověřování v konfiguraci metody CBA seřazené podle atributu priority . V současné době se v Centru pro správu nezobrazuje priorita. Microsoft Graph vrátí priority atribut pro každou vazbu. Pak se priority použijí v procesu vyhodnocení.
3. Pokud má tenant nakonfigurovanou vazbu s vysokou spřažení nebo pokud hodnota certifikátu odpovídá vlastnímu pravidlu, které vyžaduje vazbu s vysokou spřažení, odebere ze seznamu všechny vazby s nízkou spřažení.
4. Vyhodnotí každou vazbu v seznamu, dokud nedojde k úspěšnému ověření.
5. Pokud je pole certifikátu X.509 nakonfigurované vazby na prezentovaném certifikátu, ID Microsoft Entra porovnává hodnotu v poli certifikátu s hodnotou atributu objektu uživatele.
   • Pokud se najde shoda, ověření uživatele proběhne úspěšně.
   • Pokud se shoda nenajde, přesune se na další vazbu priority.
6. Pokud pole certifikátu X.509 není na zobrazeném certifikátu, přesune se na další vazbu priority.
7. Ověří všechny nakonfigurované vazby uživatelského jména, dokud jeden z nich nezískne shodu a ověření uživatele proběhne úspěšně.
8. Pokud se shoda nenajde u žádné z nakonfigurovaných vazeb uživatelského jména, ověření uživatele se nezdaří.

Zabezpečení konfigurace Microsoft Entra pomocí více vazeb uživatelského jména

Každý z atributů uživatele Microsoft Entra, které jsou k dispozici pro vazbu certifikátů na uživatelské účty Microsoft Entra (userPrincipalNameonPremiseUserPrincipalName, a certificateUserIds) má jedinečné omezení, aby se zajistilo, že certifikát odpovídá pouze jednomu uživatelskému účtu Microsoft Entra. Microsoft Entra CBA však podporuje více metod vazby v zásadách vazby uživatelského jména. Správce zásad ověřování může pojmout jeden certifikát použitý v několika konfiguracích uživatelských účtů Microsoft Entra.

Důležité

Pokud konfigurujete více vazeb, ověřování Microsoft Entra CBA je stejně zabezpečené jako vaše vazba s nejnižší spřažení, protože CBA ověřuje každou vazbu pro ověření uživatele. Pokud chcete zabránit scénáři, kdy jeden certifikát odpovídá více účtům Microsoft Entra, může správce zásad ověřování:

• Nakonfigurujte jednu metodu vazby v zásadách vazby uživatelského jména.
• Pokud má tenant nakonfigurované více metod vazeb a nechce povolit mapování jednoho certifikátu na více účtů, musí správce zásad ověřování zajistit, aby všechny povolené metody nakonfigurované v mapování zásad na stejný účet Microsoft Entra. Všechny uživatelské účty by měly mít hodnoty, které odpovídají všem vazbám.
• Pokud má tenant nakonfigurovaných více metod vazeb, měl by správce zásad ověřování zajistit, aby neměl více než jednu vazbu s nízkou spřažení.

Máte například dvě vazby uživatelského jména namapované na PrincipalNameUPNa SubjectKeyIdentifier (SKI) jsou namapovány na certificateUserIds. Pokud chcete, aby se certifikát používal jenom pro jeden účet, musí správce zásad ověřování zajistit, aby měl účet hlavní název uživatele (UPN), který je v certifikátu. Správce pak implementuje SKI mapování v certificateUserIds atributu stejného účtu.

Podpora více certifikátů pomocí jednoho uživatelského účtu Microsoft Entra (M:1)

V některých scénářích organizace vydává několik certifikátů pro jednu identitu. Může se jednat o odvozené přihlašovací údaje pro mobilní zařízení, ale může se jednat také o sekundární čipovou kartu nebo zařízení s podporou držitelů přihlašovacích údajů X.509, jako je YubiKey.

Účty jen pro cloud (M:1)

V případě účtů jen pro cloud můžete namapovat až pět certifikátů, které chcete použít, vyplněním certificateUserIds pole jedinečnými hodnotami k identifikaci jednotlivých certifikátů. Pokud chcete namapovat certifikáty, přejděte v Centru pro správu na kartu Informace o autorizaci .

Pokud organizace používá vazby s vysokou spřažení, například IssuerAndSerialNumber, hodnoty v certificateUserIds můžou vypadat jako v následujícím příkladu:

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

V tomto příkladu první hodnota představuje X509Certificate1. Druhá hodnota představuje X509Certificate2. Uživatel může při přihlášení předložit certifikát. Pokud je vazba uživatelského jména CBA nastavená tak, aby odkazovat na certificateUserIds pole, aby hledala konkrétní typ vazby (v tomto příkladu), IssuerAndSerialNumberuživatel se úspěšně přihlásí.

Hybridní synchronizované účty (M:1)

U synchronizovaných účtů můžete mapovat více certifikátů. V místní službě Active Directory vyplňte altSecurityIdentities pole hodnotami, které identifikují jednotlivé certifikáty. Pokud vaše organizace používá vazby s vysokou spřažení (to znamená silné ověřování), IssuerAndSerialNumbernapříklad , můžou tyto hodnoty vypadat jako v těchto příkladech:

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

V tomto příkladu první hodnota představuje X509Certificate1. Druhá hodnota představuje X509Certificate2. Hodnoty se pak musí synchronizovat s polem certificateUserIds v MICROSOFT Entra ID.

Podpora jednoho certifikátu s více uživatelskými účty Microsoft Entra (1:M)

V některých scénářích organizace vyžaduje, aby uživatel použil stejný certifikát k ověření ve více identitách. Může se jednat o účet správce nebo pro vývojářský nebo dočasný účet služby.

V místní službě Active Directory altSecurityIdentities pole naplní hodnoty certifikátu. Během přihlašování se používá nápověda k nasměrování služby Active Directory na zamýšlený účet ke kontrole přihlášení.

Microsoft Entra CBA má jiný proces a není zahrnuta žádná nápověda. Místo toho zjišťování domovské sféry identifikuje zamýšlený účet a zkontroluje hodnoty certifikátu. Microsoft Entra CBA také vynucuje jedinečnost v certificateUserIds poli. Dva účty nemůžou naplnit stejné hodnoty certifikátu.

Důležité

Použití stejných přihlašovacích údajů k ověření v různých účtech Microsoft Entra není zabezpečená konfigurace. Doporučujeme nepovolit použití jednoho certifikátu pro více uživatelských účtů Microsoft Entra.

Účty jen pro cloud (1:M)

Pro účty pouze v cloudu vytvořte více vazeb uživatelského jména a namapujte jedinečné hodnoty na každý uživatelský účet, který certifikát používá. Přístup k jednotlivým účtům se ověřuje pomocí jiné vazby uživatelského jména. Tato úroveň ověřování se vztahuje na hranici jednoho adresáře nebo tenanta. Správce zásad ověřování může certifikát namapovat tak, aby ho používal v jiném adresáři nebo tenantovi, pokud hodnoty zůstávají jedinečné pro každý účet.

Naplňte certificateUserIds pole jedinečnou hodnotou, která identifikuje certifikát. Pokud chcete pole naplnit, přejděte v Centru pro správu na kartu Informace o autorizaci .

Pokud organizace používá vazby s vysokou spřažení (to znamená silné ověřování), IssuerAndSerialNumber a SKIhodnoty můžou vypadat jako v následujícím příkladu:

Vazby uživatelského jména:

• IssuerAndSerialNumber > certificateUserIds
• SKI > certificateUserIds

Hodnoty uživatelského účtu certificateUserIds :
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

Když teď některý uživatel při přihlášení zobrazí stejný certifikát, uživatel se úspěšně přihlásí, protože jeho účet odpovídá jedinečné hodnotě daného certifikátu. Jeden účet se ověřuje pomocí IssuerAndSerialNumber vazby a druhý pomocí SKI vazby.

Poznámka:

Počet účtů, které lze tímto způsobem použít, je omezen počtem vazeb uživatelského jména nakonfigurovaných v tenantovi. Pokud organizace používá pouze vazby s vysokou spřažení, maximální počet podporovaných účtů je tři. Pokud organizace používá také vazby s nízkou spřažení, počet se zvýší na sedm účtů: jeden PrincipalName, jeden RFC822Name, SKIjeden SHA1PublicKey, jeden , jeden IssuerAndSubject, jeden IssuerAndSerialNumbera druhý Subject.

Hybridní synchronizované účty (1:M)

Synchronizované účty vyžadují jiný přístup. I když správce zásad ověřování může namapovat jedinečné hodnoty na každý uživatelský účet, který certifikát používá, běžný postup naplnění všech hodnot na každý účet v Microsoft Entra ID ztěžuje tento přístup. Místo toho by microsoft Entra Connect měl filtrovat hodnoty na účet tak, aby jedinečné hodnoty naplněné do účtu v Microsoft Entra ID. Pravidlo jedinečnosti se vztahuje na hranici jednoho adresáře nebo tenanta. Správce zásad ověřování může certifikát namapovat tak, aby ho používal v jiném adresáři nebo tenantovi, pokud hodnoty zůstávají jedinečné pro každý účet.

Organizace může mít také několik doménových struktur Active Directory, které přispívají uživatelům do jednoho tenanta Microsoft Entra. V tomto případě Microsoft Entra Connect použije filtr na každou doménovou strukturu služby Active Directory se stejným cílem: naplní pouze určitou jedinečnou hodnotu cloudového účtu.

Naplňte altSecurityIdentities pole ve službě Active Directory hodnotami, které identifikují certifikát. Uveďte konkrétní hodnotu certifikátu pro daný typ uživatelského účtu (například detailed, adminnebo developer). Vyberte atribut klíče ve službě Active Directory. Atribut říká synchronizaci typu uživatelského účtu, který uživatel vyhodnocuje (například msDS-cloudExtensionAttribute1). Naplňte tento atribut hodnotou typu uživatele, kterou chcete použít, například detailed, adminnebo developer. Pokud je účet primárním účtem uživatele, může být hodnota prázdná nebo null.

Zkontrolujte, že účty vypadají podobně jako v těchto příkladech:

Doménová struktura 1: Account1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Doménová struktura 1: Account2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Doménová struktura 2: ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Tyto hodnoty pak musíte synchronizovat s polem certificateUserIds v Microsoft Entra ID.

Synchronizace s certificateUserIds:

1. Nakonfigurujte Microsoft Entra Connect pro přidání alternativeSecurityIds pole do metaverse.
2. Pro každou místní doménovou strukturu Active Directory nakonfigurujte nové vlastní příchozí pravidlo s vysokou prioritou (nízké číslo nižší než 100). Expression Přidejte transformaci s polem altSecurityIdentities jako zdrojem. Cílový výraz používá klíč atribut, který jste vybrali a naplnili, a používá mapování na typy uživatelů, které jste definovali.

Příklad:

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

V tomto příkladu se nejprve zkontroluje atribut altSecurityIdentities klíče, abyste zjistili, msDS-cloudExtensionAttribute1 jestli jsou naplněné. Pokud se nenaplní, zkontroluje se, altSecurityIdentities jestli se nenaplní. Pokud je prázdný, nastavte ho na hodnotu NULL. V opačném případě je účet výchozím scénářem.

V tomto příkladu také filtrujte pouze mapování IssuerAndSerialNumber . Pokud je atribut klíče vyplněný, je tato hodnota zaškrtnutá a zkontroluje, jestli se rovná jednomu z vašich definovaných typů uživatelů. Pokud je detailedtato hodnota v příkladu , vyfiltrujte SHA1PublicKey hodnotu z altSecurityIdentities. Pokud je developerhodnota , vyfiltrujte SubjectKeyIssuer hodnotu z altSecurityIdentities.

Můžete narazit na více hodnot certifikátu určitého typu. Může se například zobrazit více PrincipalName hodnot nebo více SKI hodnot nebo více hodnot SHA1-PUKEY . Filtr získá všechny hodnoty a synchronizuje je v MICROSOFT Entra ID, ne jenom první, který najde.

Tady je druhý příklad, který ukazuje, jak nasdílit prázdnou hodnotu, pokud je atribut ovládacího prvku prázdný:

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

Pokud hodnota v altSecurityIdentities atributu ovládacího prvku neodpovídá žádné hodnotě hledání, AuthoritativeNull předá se hodnota. Tato hodnota zajišťuje, že předchozí nebo následná pravidla, která se naplní alternativeSecurityId , budou ignorována. Výsledek je prázdný v Microsoft Entra ID.

Synchronizace prázdné hodnoty:

1. Nakonfigurujte nové vlastní odchozí pravidlo s nízkou prioritou (vysoké číslo nad 160, ale v dolní části seznamu).
2. Přidejte přímou transformaci s polem alternativeSecurityIds jako zdrojem a certificateUserIds polem jako cílem.
3. Spuštěním synchronizačního cyklu dokončete populaci dat v Microsoft Entra ID.

Ujistěte se, že je jazyk CBA v každém tenantovi nakonfigurovaný s vazbami uživatelského jména odkazujícími na certificateUserIds pole pro typy polí, které jste namapovali z certifikátu. Teď může kterýkoli z těchto uživatelů předložit certifikát při přihlášení. Po ověření jedinečné hodnoty z certifikátu v certificateUserIds poli se uživatel úspěšně přihlásí.

Rozsah certifikační autority (CA) (Preview)

Rozsah certifikační autority v Microsoft Entra umožňuje správcům tenantů omezit používání konkrétních certifikačních autorit na definované skupiny uživatelů. Tato funkce vylepšuje zabezpečení a spravovatelnost CBA tím, že zajišťuje, aby se mohli ověřovat pouze autorizovaní uživatelé pomocí certifikátů vydaných konkrétními certifikačními autoritami.

Určení rozsahu certifikační autority je užitečné ve scénářích s více infrastrukturami veřejných klíčů nebo B2B, ve kterých se v různých skupinách uživatelů používá více certifikačních autorit. Pomáhá zabránit neúmyslnému přístupu a podporovat dodržování zásad organizace.

Klíčové výhody

• Omezuje použití certifikátu na konkrétní skupiny uživatelů.
• Podporuje složitá prostředí PKI prostřednictvím několika certifikačních autorit.
• Poskytuje rozšířenou ochranu proti zneužití nebo ohrožení zabezpečení certifikátu.
• Poskytuje přehled o využití certifikační autority prostřednictvím protokolů přihlašování a monitorovacích nástrojů.

Správce může pomocí oboru certifikační autority definovat pravidla, která přidružují certifikační autoritu (identifikovanou jejím ski) ke konkrétní skupině Microsoft Entra. Když se uživatel pokusí ověřit pomocí certifikátu, systém zkontroluje, jestli je vydávající certifikační autorita pro certifikát vymezená na skupinu, která obsahuje uživatele. Microsoft Entra pokračuje v řetězu certifikační autority. Použije všechna pravidla oboru, dokud se uživatel nenajde v jedné ze skupin ve všech pravidlech oboru. Pokud uživatel není ve skupině s vymezeným oborem, ověřování selže, i když je certifikát jinak platný.

Nastavení funkce nastavení rozsahu certifikační autority

1. Přihlaste se do Centra pro správu Microsoft Entra jako alespoň správce zásad ověřování.

2. Přejděte naOvěřování> metod ověřování entra ID>na základě certifikátu.

3. V části Konfigurovat přejděte do zásad oboru vystavitele certifikátů.

   

4. Vyberte Přidat pravidlo.

   

5. Vyberte Filtrovat certifikační autority podle infrastruktury veřejných klíčů.

   Klasické certifikační autority zobrazují všechny certifikační autority z klasického úložiště certifikační autority. Výběrem konkrétní infrastruktury veřejných klíčů se zobrazí všechny certifikační autority z vybrané infrastruktury veřejných klíčů.

6. Vyberte PKI.

   

7. Seznam vystavitelů certifikátů zobrazuje všechny certifikační autority z vybrané infrastruktury veřejných klíčů. Vyberte certifikační autoritu pro vytvoření pravidla oboru.

   

8. Vyberte Přidat skupinu.

   

9. Vyberte skupinu.

   

10. Výběrem možnosti Přidat pravidlo uložte.

    

11. Zaškrtněte políčko Potvrdit a pak vyberte Uložit.

    

12. Pokud chcete upravit nebo odstranit zásady oborů certifikační autority, vyberte .... na řádku pravidla. Pokud chcete pravidlo upravit, vyberte Upravit. Pokud chcete pravidlo odstranit, vyberte Odstranit.

    

Známá omezení

• Pro každou certifikační autoritu je možné přiřadit pouze jednu skupinu.
• Podporuje se maximálně 30 pravidel rozsahu.
• Rozsah se vynucuje na střední úrovni certifikační autority.
• Nesprávná konfigurace může vést k uzamčení uživatelů, pokud neexistují žádná platná pravidla oborů.

Položky protokolu přihlášení

• Protokol přihlášení ukazuje úspěch. Na kartě Další podrobnosti se zobrazí ski certifikační autority z pravidla zásad oborů.

  

• Pokud CBA selže kvůli pravidlu rozsahu certifikační autority, karta Základní informace v protokolu přihlašování zobrazuje kód chyby 500189.

  

  Koncoví uživatelé uvidí následující chybovou zprávu:

  

Jak CBA funguje v rámci zásad ověřování podle síly podmíněného přístupu

K vytvoření zásady ověřování podmíněného přístupu, která určuje použití CBA pro přístup k prostředku, můžete použít integrovanou sílu ověřování vícefaktorového ověřování microsoft Entra Phishing . Tato zásada umožňuje pouze metody ověřování, které jsou odolné proti útokům phishing, jako jsou CBA, klíče zabezpečení FIDO2 a Windows Hello pro firmy.

Můžete také vytvořit vlastní úroveň ověřování, aby jenom CBA mělo přístup k citlivým prostředkům. CBA můžete povolit jako jednofaktorové ověřování, vícefaktorové ověřování nebo obojí. Další informace najdete v tématu Síla ověřování podmíněného přístupu.

Síla jazyka CBA s pokročilými možnostmi

V zásadách metody CBA může správce zásad ověřování určit sílu certifikátu pomocí zásady vazby ověřování v metodě CBA. Teď můžete vyžadovat použití konkrétního certifikátu na základě identifikátorů OID vystavitele a zásad, když uživatelé provádějí CBA pro přístup k určitým citlivým prostředkům. Při vytváření vlastní síly ověřování přejděte do části Upřesnit možnosti. Tato funkce poskytuje přesnější konfiguraci pro určení certifikátů a uživatelů, kteří mají přístup k prostředkům. Další informace naleznete v části Rozšířené možnosti pro sílu ověřování podmíněného přístupu.

Záznamy přihlášení

Protokoly přihlašování poskytují informace o přihlášení a způsobu použití vašich prostředků v organizaci. Další informace najdete v protokolech přihlášení v Microsoft Entra ID.

Dále zvažte dva scénáře. V jednom scénáři certifikát splňuje jednofaktorové ověřování. V druhém scénáři certifikát splňuje vícefaktorové ověřování.

Pro testovací scénáře vyberte uživatele, který má zásady podmíněného přístupu, které vyžadují vícefaktorové ověřování.

Nakonfigurujte zásady vazby uživatele mapováním alternativního názvu subjektu a hlavníhouserPrincipalName názvu na objekt uživatele.

Uživatelský certifikát by měl být nakonfigurovaný jako příklad uvedený na tomto snímku obrazovky:

Řešení potíží s přihlášením s dynamickými proměnnými v protokolech přihlašování

Přestože protokoly přihlašování obvykle poskytují všechny informace, které potřebujete k ladění problému s přihlášením, někdy se vyžadují konkrétní hodnoty. Protokoly přihlašování nepodporují dynamické proměnné, takže v některých případech protokoly přihlašování neobsahují informace, které potřebujete k ladění.

Například důvod selhání v protokolech přihlášení se může zobrazit "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." v tomto scénáři<expectedSKI> a <crlAKI> nenaplní se správnými hodnotami.

Když se přihlášení uživatele pomocí CBA nezdaří, můžete zkopírovat podrobnosti protokolu z odkazu Další podrobnosti na chybové stránce. Další informace najdete v tématu Vysvětlení chybové stránky jazyka CBA.

Testování jednofaktorového ověřování

Pro první testovací scénář nakonfigurujte zásady ověřování, ve kterých IssuerAndSubject pravidlo splňuje jednofaktorové ověřování.

1. Přihlaste se k Centru pro správu Microsoft Entra jako testovací uživatel pomocí CBA. Zásady ověřování jsou nastaveny tak, aby IssuerAndSubject pravidlo splňovalo jednofaktorové ověřování.

2. Vyhledejte a pak vyberte Protokoly přihlášení.

   Další obrázek znázorňuje některé položky, které najdete v protokolech přihlašování.

   První položka vyžaduje certifikát X.509 od uživatele. Stav Přerušení znamená, že ID Microsoft Entra ověřilo, že je pro tenanta nastavený jazyk CBA. K ověření se vyžaduje certifikát.

   

   Podrobnosti o aktivitě ukazují, že požadavek je součástí očekávaného toku přihlášení, ve kterém uživatel vybere certifikát.

   

   Další podrobnosti zobrazují informace o certifikátu.

   

   Ostatní položky ukazují, že ověřování je dokončeno, primární obnovovací token se odešle zpět do prohlížeče a uživatel má udělený přístup k prostředku.

   

Testování MFA

Pro další testovací scénář nakonfigurujte zásady ověřování, ve kterých policyOID pravidlo splňuje vícefaktorové ověřování.

1. Přihlaste se k Centru pro správu Microsoft Entra pomocí CBA. Vzhledem k tomu, že byla zásada nastavená tak, aby vyhovovala vícefaktorovému ověřování, přihlášení uživatele je úspěšné bez druhého faktoru.

2. Vyhledejte a pak vyberte Přihlášení.

   Zobrazí se několik položek v protokolech přihlášení, včetně položky se stavem Přerušení .

   

   Podrobnosti o aktivitě ukazují, že požadavek je součástí očekávaného toku přihlášení, ve kterém uživatel vybere certifikát.

   

   Položka se stavem Přerušení zobrazí další diagnostické informace na kartě Další podrobnosti .

   

   Následující tabulka obsahuje popis každého pole.

   Pole	Popis
   Název subjektu certifikátu uživatele	Odkazuje na pole názvu subjektu v certifikátu.
   Vazba uživatelského certifikátu	Certifikát: PrincipalName; atribut uživatele: userPrincipalName; Pořadí: 1 Toto pole ukazuje, které pole certifikátu SÍTĚ SAN PrincipalName bylo namapováno na atribut uživatele a má prioritu userPrincipalName 1.
   Úroveň ověřování uživatelských certifikátů	multiFactorAuthentication
   Typ úrovně ověřování uživatelských certifikátů	PolicyId Toto pole ukazuje, že identifikátor zásady byl použit k určení síly ověřování.
   Identifikátor na úrovni ověřování uživatelských certifikátů	1.2.3.4 Zobrazí hodnotu politiky identifikátoru OID z certifikátu.

Chybová stránka CBA

CBA může selhat z několika důvodů. Mezi příklady patří neplatný certifikát, uživatel vybral nesprávný certifikát nebo certifikát s vypršenou platností nebo dojde k problému se seznamu CRL. Pokud ověření certifikátu selže, zobrazí se uživateli tato chybová zpráva:

Pokud CBA v prohlížeči selže, i když je příčinou selhání zrušení výběru certifikátu, zavřete relaci prohlížeče. Otevřete novou relaci a zkuste CBA znovu. Vyžaduje se nová relace, protože prohlížeče ukládají certifikáty do mezipaměti. Při opakování pokusu o CBA prohlížeč odešle certifikát uložený v mezipaměti během výzvy TLS, což pak způsobí selhání přihlášení a chybu ověření.

1. Pokud chcete získat informace o protokolování pro odeslání správci zásad ověřování, abyste získali další informace z protokolů přihlašování, vyberte Další podrobnosti.

   

2. Vyberte Další způsoby přihlášení a vyzkoušejte další dostupné metody ověřování, které se mají přihlásit.

   

Resetování výběru certifikátu v Microsoft Edgi

Prohlížeč Microsoft Edge přidal funkci, která resetuje výběr certifikátu bez restartování prohlížeče.

Uživatel provede následující kroky:

1. Když CBA selže, zobrazí se chybová stránka.

   

2. Nalevo od adresy URL adresy vyberte ikonu zámku a pak vyberte Vaše volby certifikátu.

   

3. Vyberte Obnovit volby certifikátu.

   

4. Vyberte Obnovit volby.

   

5. Vyberte Další způsoby přihlášení.

   

6. Vyberte Použít certifikát nebo čipovou kartu a pokračujte v ověřování CBA.

CBA v metodách MostRecentlyUsed

Po úspěšném ověření uživatele pomocí jazyka CBA se metoda ověřování uživatele MostRecentlyUsed (MRU) nastaví na CBA. Při příštím zadání hlavního názvu uživatele (UPN) a výběru možnosti Další uvidí metodu CBA a nemusí vybrat Použít certifikát nebo čipovou kartu.

Pokud chcete resetovat metodu MRU, zrušte výběr certifikátu a pak vyberte Další způsoby přihlášení. Vyberte jinou dostupnou metodu a dokončete ověřování.

Metoda ověřování MRU je nastavená na úrovni uživatele. Pokud se uživatel úspěšně přihlásí k jinému zařízení pomocí jiné metody ověřování, resetuje se uživatel do aktuálně přihlášené metody.

Podpora externí identity

Externí uživatel typu host B2B může používat CBA v domovském tenantovi. Pokud je pro tenanta prostředku nastaveno nastavení víceklientského vztahu důvěryhodnosti vícefaktorového ověřování z domovského tenanta, bude respektovat jazyk CBA uživatele na domovském tenantovi. Další informace najdete v tématu Konfigurace přístupu mezi tenanty spolupráce B2B. CBA v tenantovi prostředků se v současné době nepodporuje.

Související obsah

• Přehled Microsoft Entra CBA
• Nastavení jazyka Microsoft Entra CBA
• Seznam odvolaných certifikátů Microsoft Entra CBA
• Microsoft Entra CBA na zařízeních s iOSem
• Microsoft Entra CBA na zařízeních s Androidem
• Přihlášení pomocí čipové karty Windows pomocí jazyka Microsoft Entra CBA
• ID uživatele certifikátu
• Migrace federovaných uživatelů
• Nejčastější dotazy
• Řešení potíží s Microsoft Entra CBA