technické koncepty ověřování založené na certifikátech Microsoft Entra

Tento článek popisuje technické koncepty, které vysvětlují, jak Microsoft Entra ověřování pomocí certifikátů (CBA) funguje. Získejte technické znalosti, abyste lépe věděli, jak nastavit a spravovat Microsoft Entra CBA ve vašem tenantovi.

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

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 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 Microsoft Entra ID uživatele na adrese https://login.microsoftonline.com/.

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

   

4. Microsoft Entra ID zkontroluje, jestli je pro klienta nastavena 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 nastaveno CBA.

   Další informace najdete 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 poskytovatele identity používá Microsoft Entra ID, se ale mohou úspěšně ověřit jen uživatelé, kteří jsou v rozsahu 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é Microsoft Entra ID je koncový bod ověřování certifikátu https://certauth.login.microsoftonline.com. Pro Azure Government je koncový bod ověřování certifikátu https://certauth.login.microsoftonline.us.

   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í inspekce TLS funguje také pro tipy vydavatele 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ěří seznam odvolaných certifikátů (CRL), aby se zajistilo, že certifikát není odvolaný a že je platný. Microsoft Entra ID identifikuje uživatele pomocí vazby uživatelského jména nakonfigurované v tenantovi pro mapování hodnoty pole certifikátu na hodnotu atributu uživatele.

8. Pokud se jedinečný uživatel najde prostřednictvím zásad Microsoft Entra Podmíněný přístup, které vyžadují vícefaktorové ověřování (MFA), a certifikátová pravidlo vazby ověřování splňuje požadavky MFA, 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í odesláním primárního obnovovacího tokenu zpět, který označuje úspěšné přihlášení.

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

Tipy vydavatele

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

Chcete-li zapnout nápovědy vydavatele, zaškrtněte políčko Nápovědy vydavatele. Správce zásad ověřování by měl vybrat možnost Potvrzuji poté, co ověří, že proxy server s nastavenou kontrolou TLS je správně aktualizován, a poté 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 t<tenantId>.certauth.login.microsoftonline.com.

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

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

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 CA zobrazí následující chybová zpráva:

MFA s jednofaktorovým CBA

Microsoft Entra CBA se kvalifikuje pro ověřování prvního faktoru i druhého faktoru ověřování.

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 možnost 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, najdete v tématu Microsoft Entra vícefaktorové ověřování.

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í CBA může umožnit uživateli potenciálně provést 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řístupový průkaz.
• 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živateli s podporou CBA nebyl vydán certifikát a potřebuje pro dokončení vícefaktorového 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řístupový průkaz.
• 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řístupový průkaz.
• 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 k Centrum pro správu Microsoft Entra alespoň jako 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 Libovolný, CBA a přihlášení bez hesla nefungují.

3. Vyberte Entra ID>Multifactor authentication>Další nastavení ověřování založeného na cloudu.

   

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 MFA ověřování pomocí certifikátů pro jednofaktorové ověřování a přihlašování bez použití 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. V aplikaci Microsoft Authenticator vyberte možnost Schválit žádost.

   

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

6. V Microsoft Authenticator 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í

Politika vazby ověřování pomáhá nastavit sílu ověřování na jednofaktorovou nebo vícefaktorovou. 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 Microsoft Entra ověřování, která vychází z NIST 800-63B SP 800-63B, Pokyny pro digitální identity: Ověřování a řízení životního cyklu.

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, 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 OID 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 vystavitele a zásad OID se vyhodnocují jako první. Pokud máte vlastní pravidlo s certifikační autoritou vystavitele CA1 a identifikátorem zásad 1.2.3.4.5 s MFA, vícefaktorové ověřování je přiřazeno pouze certifikátu A, který splňuje jak hodnotu vystavitele, tak 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 OID zásad 1.2.3.4.5 a odvozeným přihlašovacím údajem B na základě tohoto certifikátu, který má identifikátor OID zásad 1.2.3.4.5.6, a vlastní pravidlo je definováno jako identifikátor OID zásad, 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í vystavující certifikační autority. Pokud má certifikát odpovídající identifikátor zásad OID a pravidla vystavitele, je identifikátor zásad OID 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 je jeden OID zásady přiřazen vícefaktorovému ověřování, všechny uživatelské certifikáty, které zahrnují tento OID zásady, jsou způsobilé jako MFA. (Uživatelský certifikát může obsahovat více OID zásad.)
8. Jeden vystavitel certifikátu může mít pouze jednu platnou vazbu pro silné ověřování (to znamená, že certifikát nemůže být svázán jak s jednofaktorovým ověřováním, tak s vícefaktorovým ověřováním).

Důležité

V rámci aktuálně řešeného známého problému, pokud správce zásad ověřování vytvoří pravidlo zásad CBA za použití jak vystavitele, tak identifikátoru zásad, ovlivní to 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
• Windows přihlášení k telefonu bez hesla

Registrace zařízení ve scénářích připojení k síti na pracovišti, Microsoft Entra ID a Microsoft Entra hybridních připojení nejsou ovlivněné. 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á jak vystavitele, tak OID zásad, k odebrání požadavku na vystavitele nebo OID zásad.
• 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 alternativní název subjektu (SAN) "Principální Jméno" v certifikátu mapován na atribut userPrincipalName objektu uživatele, aby identifikoval 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 s vysokou afinitou, pokud jsou založené na identifikátorech, které nemůžete znovu 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ízkou afinitu. Microsoft Entra ID implementuje tři mapování, která jsou považována za nízkou afinitu podle 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á afinita
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	Nízká afinita
IssuerAndSubject	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	Nízká afinita
Subject	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	Nízká afinita
SKI	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	Vysoká afinita
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á afinita
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á afinita

Důležité

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

Definovat a přepsat spřaženou vazbu

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

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.

Pravidla pro vazbu více zásad uživatelských jmen

Pokud chcete vyřešit mnohonásobná pravidla vázání zásad pro uživatelská jména, Microsoft Entra ID používá 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í atribut priority pro každou vazbu. Pak se priority použijí v procesu vyhodnocení.
3. Pokud má tenant nakonfigurovanou vazbu s vysokou afinitou, nebo pokud hodnota certifikátu odpovídá vlastnímu pravidlu, které vyžaduje vazbu s vysokou afinitou, ze seznamu odebere všechny vazby s nízkou afinitou.
4. Vyhodnotí každou vazbu v seznamu, dokud nedojde k úspěšnému ověření.
5. Pokud je v zobrazeném certifikátu pole X.509 certifikátu konfigurované vazby, Microsoft Entra ID porovná 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ší prioritní vazbu.
6. Pokud se pole certifikátu X.509 nenachází na předloženém certifikátu, přechází se na další přidělení 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ů objektu uživatele Microsoft Entra, které jsou k dispozici pro vytvoření vazby certifikátů k Microsoft Entra uživatelským účtům (userPrincipalName, onPremiseUserPrincipalName a certificateUserIds), má jedinečné omezení, aby se zajistilo, že certifikát odpovídá pouze jednomu Microsoft Entra uživatelskému účtu. Microsoft Entra však v zásadě vazby uživatelského jména podporuje několik metod vazby. 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í CBA od Microsoft Entra je stejně bezpečné jako vaše vazba s nejnižší preferencí, protože CBA zpracovává 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 nakonfigurováno více způsobů vazby 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 ve zásadě odpovídaly stejnému účtu Microsoft Entra. Všechny uživatelské účty by měly mít hodnoty, které odpovídají všem vazbám.
• Pokud má tenant nakonfigurováno více metod vazby, měl by správce zásady ověřování zajistit, aby neměl více než jednu vazbu s nízkou prioritou.

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ů s jedním uživatelským účtem 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 afinitou, například IssuerAndSerialNumber, hodnoty v certificateUserIds mohou 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 odkazovala na pole certificateUserIds k hledání konkrétního typu vazby (v tomto příkladu IssuerAndSerialNumber), už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í Active Directory vyplňte pole altSecurityIdentities hodnotami, které identifikují jednotlivé certifikáty. Pokud vaše organizace používá vazby s vysokou přilnavostí (to znamená silné ověřování) jako IssuerAndSerialNumber, 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, vývojářský účet nebo dočasný účet.

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

Microsoft Entra CBA má jiný proces a není zahrnuta žádná nápověda. Zjišťování domén domovské sféry místo toho identifikuje zamýšlený účet a zkontroluje hodnoty certifikátu. Microsoft Entra CBA také vynucuje jedinečnost v poli certificateUserIds. 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 afinitou (to znamená silné ověřování), jako jsou IssuerAndSerialNumber a SKI, hodnoty 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 afinitou, podporuje maximálně tři účty. Pokud organizace používá také vazby s nízkou afinitou, počet se zvýší na sedm účtů: jeden PrincipalName, jeden RFC822Name, jeden SKI, jeden SHA1PublicKey, jeden IssuerAndSubject, jeden IssuerAndSerialNumber a jeden 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 tento přístup ztěžuje. Místo toho by služba Microsoft Entra Connect měla filtrovat hodnoty pro každý účet tak, aby byly přiřazené jedinečné hodnoty 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é více služba Active Directory doménových struktur, které přispívají uživatelům do jednoho tenanta Microsoft Entra. V tomto případě Microsoft Entra Connect použije filtr na každý z služba Active Directory lesů se stejným cílem: naplní pouze specifickou, jedinečnou hodnotu do cloudového účtu.

Do pole altSecurityIdentities v služba Active Directory zadejte hodnoty, které identifikují certifikát. Uveďte konkrétní hodnotu certifikátu pro daný typ uživatelského účtu (například detailed, adminnebo developer). V služba Active Directory vyberte atribut klíče. 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 do pole certificateUserIds v Microsoft Entra ID.

Synchronizace s certificateUserIds:

1. Nakonfigurujte Microsoft Entra Connect pro přidání pole alternativeSecurityIds do metaverse.
2. Pro každou místní Active Directory doménovou strukturu 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, zda jsou altSecurityIdentities a atribut klíče msDS-cloudExtensionAttribute1 naplněné. Pokud nejsou naplněny, zkontroluje se, zda je altSecurityIdentities naplněn. Pokud je prázdný, nastavte ho na hodnotu NULL. Jinak je účet ve výchozím nastavení.

Také v tomto příkladu filtrujte pouze na mapování IssuerAndSerialNumber. Pokud je atribut klíče vyplněný, hodnota je zkontrolována, zda 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 hodnota developer, filtrovat podle hodnoty SubjectKeyIssuer 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í, kterou najde.

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

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 atributu ovládacího prvku altSecurityIdentities neodpovídá žádné z hledaných hodnot, je předána hodnota AuthoritativeNull. Tato hodnota zajišťuje, že předchozí nebo následná pravidla, která plní alternativeSecurityId, budou ignorována. Výsledek je v Microsoft Entra ID prázdný.

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. Spusťte synchronizační cyklus pro dokončení základního souboru 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)

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 po řetězci CA. 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 k Centrum pro správu Microsoft Entra alespoň jako Správce zásad ověřování.

2. Přejděte na Entra ID> Metody ověřování>> Ověřování na základě certifikátu.

3. Pod Konfigurovat přejděte k zásadám určení vystavitele certifikátu.

   

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. Zvolte Přidat a uložte pravidlo.

    

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á scoping pravidla.

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ásady zaměření.

  

• 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

Pomocí integrované Microsoft Entra Phishing-rezistentní MFA autentizační síly můžete vytvořit zásadu podmíněného přístupu k ověřování, která definuje použití CBA pro přístup k prostředku. Zásady umožňují 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.

Výkon 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í úrovně ověřování přejděte do 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 přihlašovacích protokolech 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í. Ve druhém scénáři certifikát splňuje požadavek vícefaktorového 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> nejsou naplněny 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 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 Centrum 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 Interrupted znamená, že Microsoft Entra ID ověřil, že CBA je nastaveno pro tenanta. 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 správy 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. Je potřeba 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 jiné dostupné metody přihlášení.

   

Resetování volby certifikátu v Microsoft Edge

Prohlížeč Microsoft Edge přidal funkci, která resetuje výběr certifikátu bez nutnosti 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í pomocí 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í na jiném zařízení pomocí jiné metody ověřování, resetuje se MRU na aktuálně použitou metodu přihlášení.

Podpora externí identity

Externí uživatel typu host B2B může používat CBA v domovském tenantovi. Pokud je pro tenant prostředku nastaveno, aby důvěřoval vícefaktorovému ověřování z domovského tenanta, bude respektováno certifikátové ověřování uživatele na domovském tenantovi. Další informace najdete v tématu Konfigurace přístupu mezi tenanty spolupráce B2B. CBA na tenantovi zdrojů se v současné době nepodporuje.

Související obsah

• Přehled Microsoft Entra CBA
• Technické podrobné informace o Microsoft Entra CBA
• Pokud nakonfigurovat Microsoft Entra CBA
• Microsoft Entra seznam odvolaných certifikátů CBA
• Microsoft Entra CBA na zařízeních s Androidem
• Přihlášení do Windows pomocí čipové karty a Microsoft Entra CBA
• ID uživatele certifikátu
• Postup migrace federovaných uživatelů
• Nejčastější dotazy
• Microsoft Entra seznam odvolaných certifikátů CBA
• Microsoft Entra CBA na zařízeních s Androidem
• Přihlášení do Windows pomocí čipové karty a Microsoft Entra CBA
• ID uživatele certifikátu
• Postup migrace federovaných uživatelů
• Nejčastější dotazy