Technické informace o ověřování založeném na certifikátech společnosti Microsoft Entra

Tento článek vysvětluje, jak funguje ověřování založené na certifikátech Microsoft Entra (CBA) a podrobně popisuje technické podrobnosti o konfiguracích Microsoft Entra CBA.

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

Následující obrázek popisuje, co se stane, když se uživatel pokusí přihlásit k aplikaci v tenantovi, kde je povolený Microsoft Entra CBA.

Teď si projdeme jednotlivé kroky:

1. Uživatel se pokusí o přístup k aplikaci, například portál MyApps.

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

3. Uživatel zadá své uživatelské jméno na přihlašovací stránku Microsoft Entra a pak vybere Další. Microsoft Entra ID provádí zjišťování sféry domů pomocí názvu tenanta a uživatelské jméno se používá k vyhledání uživatele v tenantovi.

   

4. Microsoft Entra ID kontroluje, jestli je pro tenanta povolený CBA. Pokud je CBA povolená, 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 v tenantovi povolený CBA. Další informace najdete v tématu Návody povolení jazyka CBA společnosti Microsoft Entra?.

   Poznámka:

   Pokud je jazyk CBA v tenantovi povolený, zobrazí se všem uživatelům odkaz na použití certifikátu nebo čipové karty na stránce s heslem. V rámci CBA se ale můžou úspěšně ověřit pouze uživatelé v aplikaci, která jako zprostředkovatele identity (IdP) používá Microsoft Entra ID.

   

   Pokud jste povolili jiné metody ověřování, jako je Telefon přihlášení nebo klíče zabezpečení, můžou se uživatelům zobrazit jiná přihlašovací obrazovka.

   

5. Jakmile uživatel vybere ověřování na základě certifikátů, klient se přesměruje do koncového bodu ověření certifikátu, což je https://certauth.login.microsoftonline.com pro veřejné ID Entra. Pro Azure Government je https://certauth.login.microsoftonline.uskoncový bod ověření certifikátu .

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

   Poznámka:

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

   Ujistěte se, že zakázání kontroly protokolu TLS funguje také pro novou adresu URL s pokyny vystavitele. Neokódujte adresu URL s ID tenanta, protože se může změnit pro uživatele B2B. Regulární výraz umožňuje, aby stará i nová adresa URL fungovala pro zakázání kontroly protokolu TLS. Například v závislosti na proxy serveru, použití *.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ý, ověřování na základě certifikátů selže, pokud povolíte nadcházející funkci nápovědy důvěryhodné certifikační autority.

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

   Poznámka:

   Důvěryhodné rady certifikační autority nejsou podporované, takže seznam certifikátů není možné dále vymezit. V budoucnu se snažíme tuto funkci přidat.

   

7. Id Microsoft Entra ověřuje seznam odvolaných certifikátů, aby se ujistil, že certifikát není odvolán a 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 najde jedinečný uživatel se zásadami podmíněného přístupu, které vyžadují vícefaktorové ověřování, a pravidlo vazby ověřování certifikátu splňuje vícefaktorové ověřování , microsoft Entra ID uživatele okamžitě podepíše. Pokud se vyžaduje vícefaktorové ověřování, ale certifikát splňuje jenom jeden faktor, nabízí se přihlášení bez hesla nebo FIDO2 jako druhý faktor, pokud už jsou zaregistrované.

9. Id Microsoft Entra dokončí proces přihlášení odesláním primárního obnovovacího tokenu zpět, aby bylo uvedeno úspěšné přihlášení.

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

Ověřování na základě certifikátů je schopné vícefaktorového ověřování

Microsoft Entra CBA je schopen vícefaktorového ověřování (MFA). Microsoft Entra CBA může být buď jednofaktorový (SF), nebo vícefaktorový (MF) v závislosti na konfiguraci tenanta. PovoleníM CBA může uživatel potenciálně dokončit vícefaktorové ověřování. Uživatel může potřebovat další konfiguraci k dokončení vícefaktorového ověřování a ověření k registraci dalších metod ověřování, pokud je uživatel v oboru CBA.

Pokud má uživatel s podporou CBA jenom certifikát SF (Single Factor) a potřebuje dokončit vícefaktorové ověřování:

1. Použijte heslo a certifikát SF.
2. Vydání dočasného přístupového passu
3. Zásady ověřování Správa istrator přidají telefonní číslo a povolí ověřování hlasových a textových zpráv pro uživatelský účet.

Pokud uživatel s podporou CBA ještě nevystavil certifikát a potřebuje dokončit vícefaktorové ověřování:

1. Vydání dočasného přístupového passu
2. Zásady ověřování Správa istrator přidají telefonní číslo a povolí ověřování hlasových a textových zpráv pro uživatelský účet.

Pokud uživatel s podporou CBA nemůže používat certifikát MF, například na mobilním zařízení bez podpory čipových karet, a musí dokončit vícefaktorové ověřování:

1. Vydání dočasného přístupového passu
2. Uživatel musí zaregistrovat jinou metodu MFA (když uživatel může použít certifikát MF).
3. Použijte heslo a certifikát MF (pokud uživatel může použít certifikát MF).
4. Zásady ověřování Správa istrator přidají telefonní číslo a povolí ověřování hlasových a textových zpráv pro uživatelský účet.

Vícefaktorové ověřování s ověřováním založeným na jednofaktorovém certifikátu (Preview)

Microsoft Entra CBA lze použít jako druhý faktor pro splnění požadavků vícefaktorového ověřování s jednofaktorovými certifikáty. Mezi podporované kombinace patří:

1. CBA (první faktor) a přihlášení k telefonu bez hesla (bez hesla jako druhý faktor)
2. CBA (první faktor) a klíče zabezpečení FIDO2 (druhý faktor)
3. Heslo (první faktor) a CBA (druhý faktor)

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

Důležité

Uživatel se považuje za MFA, který je schopen zahrnout do nastavení metody CBA. To znamená, že uživatel nemůže použít důkaz v rámci 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.

Postup nastavení přihlašování k telefonu bez hesla (PSI) pomocí CBA

Aby přihlášení bez hesla fungovalo, měli by uživatelé zakázat starší oznámení prostřednictvím své mobilní aplikace.

1. Přihlaste se do Centra pro správu Microsoft Entra jako alespoň zásady ověřování Správa istrator.

2. Postupujte podle pokynů v tématu Povolení ověřování přihlašování telefonem bez hesla.

   Důležité

   V předchozí konfiguraci se ujistěte, že jste zvolili možnost Bez hesla. Musíte změnit režim ověřování pro všechny skupiny přidané pro rozhraní PSI do bez hesla. Pokud zvolíte Libovolná, CBA a PSI nefungují.

3. Vyberte Možnost Vícefaktorové ověřování>Ochrany>Další nastavení vícefaktorové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 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

Podívejme se na příklad uživatele, který má jednofaktorový certifikát a je nakonfigurovaný pro přihlašování bez hesla.

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

   

2. Vyberte Přihlásit se pomocí certifikátu.

   

   Pokud jste povolili jiné metody ověřování, jako jsou Telefon přihlašovací klíče nebo klíče zabezpečení FIDO2, můžou se uživatelům zobrazit jiná přihlašovací obrazovka.

   

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

   

4. Vzhledem k tomu, že je certifikát nakonfigurovaný tak, aby byl silný jednofaktorové ověřování, potřebuje uživatel druhý faktor pro splnění požadavků vícefaktorového ověřování. Uživatel uvidí dostupné další faktory, což je v tomto případě 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. Zadejte číslo, které se zobrazí na obrazovce prohlížeče nebo aplikace, do Microsoft Authenticatoru.

   

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

Principy zásad vazby ověřování

Zásady vazby ověřování pomáhají určit sílu ověřování jako jednofaktorové nebo vícefaktorové. Správce může změnit výchozí hodnotu z jednofaktorového na vícefaktorové nebo nastavit vlastní konfigurace zásad buď pomocí polí OID vystavitele nebo vystavitele nebo vystavitele a identifikátoru zásad v certifikátu.

Silné stránky certifikátů

Správce může určit, jestli jsou certifikáty jednofaktorové nebo vícefaktorové síly. 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 cyklu mgmt.

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

Pokud má uživatel vícefaktorový certifikát, může provádět vícefaktorové ověřování pouze s certifikáty. Zásady ověřování Správa istrator by ale měly zajistit, aby certifikáty byly chráněny kódem PIN nebo biometrickým kódem, aby se považovaly za multifactor.

Jak ID Microsoft Entra řeší více pravidel vazeb zásad ověřování

Vzhledem k tomu, že lze vytvořit více pravidel zásad vazby vlastního ověřování s různými poli certifikátů, jako je použití identifikátoru vystavitele + identifikátoru zásad, nebo pouze identifikátoru zásad nebo pouze vystavitele. níže jsou uvedené kroky, které slouží k určení úrovně ochrany ověřování, když se vlastní pravidla překrývají. Jsou to následující:

1. Pravidla identifikátoru vystavitele a zásady mají přednost před pravidly OID zásad. Pravidla identifikátoru zásad mají přednost před pravidly vystavitele certifikátů.
2. Jako první se vyhodnocují pravidla vystavitele a identifikátorů zásad. Pokud máte vlastní pravidlo s vystavitelem CA1 a zásadou OID 1.2.3.4.5 s vícefaktorovým ověřováním, udělí se MFA pouze certifikát A, který splňuje hodnotu vystavitele i identifikátor zásady.
3. Dále se vyhodnocují vlastní pravidla využívající identifikátory OID zásad. Pokud máte certifikát A se zásadou OID 1.2.3.4.5 a odvozené přihlašovací údaje B založené na daném certifikátu mají zásadu OID 1.2.3.4.5.6, a vlastní pravidlo se definuje jako identifikátor zásad s hodnotou 1.2.3.4.5 s vícefaktorovým ověřováním, pouze certifikát A splňuje vícefaktorové ověřování a přihlašovací údaje B splňují pouze jednofaktorové ověřování. Pokud uživatel použil odvozené přihlašovací údaje během přihlašování a byl nakonfigurován tak, aby měl 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 v případě, že certifikát obsahuje dvě 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. Dále se vyhodnocují vlastní pravidla využívající certifikační autoritu vystavitele.
6. Pokud má certifikát porovnávání identifikátorů zásad i pravidel vystavitele, identifikátor zásady se vždy zkontroluje jako první a pokud se nenajde žádné pravidlo zásady, zkontrolují se vazby vystavitele. OID zásad má vyšší prioritu vazby silného ověřování než vystavitel.
7. Pokud jedna certifikační autorita vytvoří vazbu na vícefaktorové ověřování, všechny uživatelské certifikáty, které certifikační autorita vydá jako MFA. Stejná logika platí pro jednofaktorové ověřování.
8. Pokud se jeden identifikátor zásady sváže s vícefaktorovým ověřováním, všechny uživatelské certifikáty, které obsahují tento identifikátor OID zásad jako jedno z identifikátorů OID uživatele (uživatelský certifikát může mít více identifikátorů OID zásad), se kvalifikují jako vícefaktorové ověřování.
9. Jeden vystavitel certifikátu může mít pouze jednu platnou silnou ověřovací vazbu (to znamená, že certifikát nemůže svázat s jedním faktorem i vícefaktorovým ověřováním).

Důležité

Existuje známý problém, kdy správce tenanta Entra konfiguruje pravidlo zásad ověřování CBA pomocí vystavitele a identifikátoru zásad některé scénáře registrace zařízení, mezi které patří:

• Registrace Windows Hello pro firmy
• Registrace klíče zabezpečení Fido2
• Přihlášení Telefon bez hesla windows

Registrace zařízení ve scénářích připojení k pracovišti, Id entra a hybridního připojení zařízení Entra ID nejsou ovlivněny. Pravidla zásad ověřování CBA používající identifikátory zásad vystavitele NEBO zásady nemají vliv. Pokud chcete tento problém zmírnit, měli by správci:

• Upravte pravidla zásad ověřování na základě certifikátů, která aktuálně používají možnosti Vystavitel a Identifikátor zásad, a odeberte požadavek Vystavitel nebo identifikátor identifikátoru a uložte ho. NEBO
• Odeberte pravidlo zásad ověřování, které aktuálně používá identifikátor vystavitele a zásady, a vytvořte pravidla pouze s použitím identifikátoru vystavitele nebo zásady.

Pracujeme na opravě problému.

Principy zásad 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í se hlavní název objektu SAN (Subject Alternate Name) v certifikátu mapuje na atribut UserPrincipalName objektu uživatele k určení uživatele.

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

Pro vazby certifikátů existuje sedm podporovaných metod. 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, jako jsou identifikátory klíče subjektu nebo veřejný klíč SHA1. Tyto identifikátory vyjadřují vyšší záruku, že k ověření příslušného 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 spřažení s nízkou úrovní. Microsoft Entra ID implementuje tři mapování považované za spřažení na základě opakovaně použitelných identifikátorů. Ostatní jsou považovány za vazby s vysokou spřažení. Další informace najdete v tématu certificateUserIds.

Pole mapování certifikátu	Příklady hodnot v certificateUserIds	Atributy objektu uživatele	Typ
HlavníNázev	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 (Preview)	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í
Předmět (Preview)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	nízká spřažení
LYŽAŘSKÉ	X509:<SKI>123456789abcdef	certificateUserIds	vysoká spřažení
SHA1PublicKey	X509:<SHA1-PUKEY>123456789abcdef	certificateUserIds	vysoká spřažení
IssuerAndSerialNumber (Preview)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48 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í

Definování vazby spřažení na úrovni tenanta a přepsání vlastními pravidly (Preview)

Pomocí této funkce může zásady ověřování Správa istrator nakonfigurovat, jestli se uživatel může ověřit pomocí mapování vazeb uživatelského jména s nízkou spřažení nebo s vysokou spřažení. Pro tenanta můžete nastavit požadovanou vazbu spřažení, která platí pro všechny uživatele. Výchozí hodnotu pro celého tenanta můžete také přepsat vytvořením vlastních pravidel založených na identifikátoru vystavitele a zásadách nebo identifikátoru zásad nebo vystavitele.

Jak Id Microsoft Entra řeší více pravidel vazeb zásad uživatelského jména

Použijte vazbu s nejvyšší prioritou (nejnižším číslem).

1. Vyhledejte objekt uživatele pomocí uživatelského jména nebo hlavního názvu uživatele.
2. Získejte seznam všech vazeb uživatelského jména, které nastaví správce tenanta v konfiguraci metody ověřování CBA seřazené podle atributu priority. V současné době se v uživatelském prostředí portálu nezpřístupní koncept priority. Graph vám vrátí atribut priority pro každou vazbu a použije se v procesu vyhodnocení.
3. Pokud má tenant povolenou vazbu s vysokou spřažení nebo pokud hodnota certifikátu odpovídá vlastnímu pravidlu, které vyžaduje vazbu s vysokým spřažením, odeberte ze seznamu všechny vazby s nízkými spřažení.
4. Vyhodnoťte každou vazbu v seznamu, dokud nedojde k úspěšnému ověření.
5. Pokud je v zobrazeném certifikátu pole certifikátu X.509 nakonfigurované vazby, odpovídá ID Microsoft Entra hodnotě v poli certifikátu s hodnotou atributu objektu uživatele.
   1. Pokud se najde shoda, ověření uživatele proběhne úspěšně.
   2. Pokud se shoda nenajde, přejděte na další vazbu priority.
6. Pokud pole certifikátu X.509 není na zobrazeném certifikátu, přejděte na další vazbu priority.
7. Ověřte všechny nakonfigurované vazby uživatelského jména, dokud jedna 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 (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) k dispozici pro vazbu certifikátů s uživatelskými účty Microsoft Entra 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, které správci umožňují umístit jeden certifikát do více konfigurací uživatelských účtů Entra.

Důležité

Pokud konfigurujete více vazeb, ověřování Microsoft Entra CBA je stejně bezpečné jako nejnižší spřažení vazby, protože CBA ověří 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 zásady ověřování Správa istrator:

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

Předpokládejme například, že máte dvě vazby uživatelského jména na PrincipalName namapované na UPN a SubjectKeyIdentifier (SKI) na certificateUserIds. Pokud chcete, aby se certifikát používal jenom pro jeden účet, musí zásady ověřování Správa istrator zajistit, aby měl účet hlavní název uživatele(UPN), který je v certifikátu, a implementovat mapování SKI v atributu certificateUserId stejného účtu.

Podpora více certifikátů s jedním uživatelským účtem Entra (M:1)

Existují scénáře, kdy organizace vydává více certifikátů pro jednu identitu. Nejčastěji se jedná o odvozené přihlašovací údaje pro mobilní zařízení nebo také pro sekundární čipovou kartu nebo zařízení s podporou x509, jako je Yubikey.

Účty pouze v cloudu Pro účty pouze v cloudu můžete mapovat více certifikátů (až 5) pro použití vyplněním pole CertificateUserIds (autorizační informace na portálu User Portal) jedinečnými hodnotami, které identifikují jednotlivé certifikáty. Pokud organizace používá vazby s vysokou spřažení, například Issuer + SerialNumber, hodnoty v rámci CertificateUserIds můžou vypadat takto:

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

V tomto příkladu první hodnota představuje X509Certificate1 a druhá hodnota představuje X509Certificate2. Uživatel může předložit buď certifikát při přihlášení, a pokud je vazba uživatelského jména CBA nastavena tak, aby odkazovat na pole certificateUserIds, aby hledal konkrétní typ vazby (tj. Issuer+SerialNumber v tomto příkladu), pak se uživatel úspěšně přihlásí.

Hybridní synchronizované účty Pro synchronizované účty můžete mapovat více certifikátů pro použití vyplněním pole altSecurityIdentities v AD hodnotami identifikujícími jednotlivé certifikáty. Pokud organizace používá vazby s vysokým spřažením (tj. silné ověřování), například vystavitel + sériové číslo, může to vypadat takto:

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

V tomto příkladu první hodnota představuje X509Certificate1 a druhá hodnota představuje X509Certificate2. Tyto hodnoty se pak musí synchronizovat s polem certificateUserIds v Azure AD.

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

Existují scénáře, kdy organizace potřebuje, aby uživatel použil stejný certifikát k ověření ve více identitách. Nejčastěji se jedná o účty pro správu. Může se jednat také o účty pro vývojáře nebo dočasné účty služeb. V tradiční službě AD se pole altSecurityIdentities používá k naplnění hodnot certifikátu a během přihlášení se k nasměrování ad na požadovaný účet použije nápověda ke kontrole přihlášení. S Microsoft Entra CBA se to liší a neexistuje žádná nápověda. Zjišťování domovské sféry místo toho identifikuje požadovaný účet pro kontrolu hodnot certifikátu. Dalším klíčovým rozdílem je, že Microsoft Entra CBA vynucuje jedinečnost v poli certificateUserIds. To znamená, že oba účty nemohou naplnit stejné hodnoty certifikátu.

Důležité

Není to velmi zabezpečená konfigurace pro použití stejných přihlašovacích údajů k ověření v různých účtech Entra ID a nedoporučuje se povolit jeden certifikát pro více uživatelských účtů Entra.

Účty pouze v cloudu Pro účty pouze v cloudu potřebujete vytvořit více vazeb uživatelského jména a musíte namapovat jedinečné hodnoty na každý uživatelský účet, který bude používat certifikát. Každý účet se ověří pomocí jiné vazby uživatelského jména. To platí v rámci hranice jednoho adresáře nebo tenanta (tj. správce tenanta může mapovat certifikát pro použití v jiném adresáři nebo tenantovi i za předpokladu, že hodnoty zůstanou jedinečné pro každý účet).

Vyplňte pole certificateUserIds (autorizační informace na portálu User Portal) jedinečnou hodnotou identifikující požadovaný certifikát. Pokud organizace používá vazby s vysokou spřažení (tj. silné ověřování), například vystavitel + sériové číslo a SKI, může to vypadat takto:

Vazby uživatelského jména:

• Vystavitel + sériové číslo –> CertificateUserIds
• SKI –> CertificateUserIds

Hodnoty CertificateUserIds uživatelského účtu:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Když teď některý uživatel zobrazí stejný certifikát při přihlášení, 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ěří pomocí vystavitele a sériového čísla a druhého pomocí vazby SKI.

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 vysokým spřažením, počet podporovaných účtů bude omezen na 3. Pokud organizace také využívá vazby s nízkou spřažení, toto číslo se zvýší na 7 účtů (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Hybridní synchronizované účty Pro synchronizované účty se přístup bude lišit. I když správce tenanta může mapovat jedinečné hodnoty na každý uživatelský účet, který bude používat certifikát, běžný postup naplnění všech hodnot na každý účet v Id Entra by to ztěžovalo. Místo toho by služba Azure AD Připojení měla vyfiltrovat požadované hodnoty pro každý účet na jedinečné hodnoty naplněné do účtu v id Entra. Pravidlo jedinečnosti platí v rámci hranice jednoho adresáře nebo tenanta (tj. správce tenanta může mapovat certifikát pro použití v jiném adresáři nebo tenantovi i za předpokladu, že hodnoty zůstanou jedinečné pro každý účet). Organizace navíc může mít více doménových struktur AD, které přispívají uživatelům do jednoho tenanta Entra ID. V takovém případě azure AD Připojení použije filtr na každou z těchto doménových struktur AD se stejným cílem naplnit pouze požadovanou jedinečnou hodnotu cloudového účtu.

Naplňte pole altSecurityIdentities v AD hodnotami identifikujícími požadovaný certifikát a zahrňte požadovanou hodnotu certifikátu pro daný typ uživatelského účtu (např. detailee, admin, vývojář atd.). Vyberte atribut klíče v AD, který oznámí synchronizaci typu uživatelského účtu, který uživatel vyhodnocuje (např. msDS-cloudExtensionAttribute1). Tento atribut naplňte hodnotou typu uživatele, kterou chcete mít, například detailee, admin nebo vývojář. Pokud se jedná o primární účet uživatele, může být hodnota ponechána prázdná nebo null.

Účty můžou vypadat takto:

Doménová struktura 1 – Account1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Doménová struktura 1 – Account2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

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

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

Postup synchronizace s certificateUserIds

1. Konfigurace služby Azure AD Connect pro přidání pole alternativeSecurityIds do metaverse
2. Pro každou doménovou strukturu AD nakonfigurujte nové vlastní příchozí pravidlo s vysokou prioritou (nízké číslo nižší než 100). Přidejte transformaci výrazu s polem altSecurityIdentities jako zdrojem. Cílový výraz bude používat atribut klíče, který jste vybrali a naplnili, a také mapování na typy uživatelů, které jste definovali.
3. 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 příkladu výše jsou altSecurityIdentities a atribut klíče msDS-cloudExtensionAttribute1is nejprve kontrolovány, aby se zjistilo, jestli jsou naplněné. Pokud ne, zkontroluje se altSecurityIdentities a zjistí, jestli je naplněný. Pokud je prázdný, nastavíme ho na hodnotu NULL. Jinak účet spadá do výchozího případu a v tomto příkladu filtrujeme pouze na mapování Issuer+SerialNumber. Pokud je atribut klíče vyplněný, je tato hodnota zaškrtnutá a zkontroluje, jestli je rovna jednomu z našich definovaných typů uživatelů. V tomto příkladu, pokud je tato hodnota detailee, pak vyfiltrujeme hodnotu SHA1PublicKey z altSecurityIdentities. Pokud je hodnota vývojář, vyfiltrujeme hodnotu SubjectKeyIssuer z altSecurityIdentities. Může existovat více hodnot certifikátu určitého typu. Například několik hodnot PrincipalName nebo více hodnot SKI nebo SHA1-PUKEY. Filtr získá všechny hodnoty a synchronizuje se do ID Entra – ne jenom první, které najde.

1. Druhý příklad, který ukazuje, jak odeslat prázdnou hodnotu, pokud je atribut ovládacího prvku prázdný, je níže.

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 neodpovídá žádné z hodnot hledání v atributu ovládacího prvku, je předána AutoritativníNull. Tím se zajistí, že předchozí nebo následná pravidla, která naplní hodnotu alternativeSecurityId, budou ignorována a výsledek bude v ID Entra prázdný.

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

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

Principy procesu odvolání certifikátu

Proces odvolání certifikátu umožňuje správci odvolat dříve vydaný certifikát, aby se použil k budoucímu ověření. Odvolání certifikátu neodvolá již vydané tokeny uživatele. Podle pokynů ručně odvoláte tokeny při konfiguraci odvolání.

Microsoft Entra ID stáhne a ukládá do mezipaměti seznam odvolaných certifikátů (CRL) zákazníků ze své certifikační autority a kontroluje, jestli jsou certifikáty při ověřování uživatele odvolány.

Správce může nakonfigurovat distribuční bod seznamu CRL během procesu nastavení důvěryhodných vystavitelů v tenantovi Microsoft Entra. Každý důvěryhodný vystavitel by měl mít CRL, na který se dá odkazovat pomocí internetové adresy URL.

Důležité

Maximální velikost seznamu CRL pro MICROSOFT Entra ID pro úspěšné stažení interaktivního přihlašování a mezipaměti je 20 MB ve veřejném ID Entra a 45 MB v cloudech Azure US Government a doba potřebná ke stažení seznamu CRL nesmí překročit 10 sekund. Pokud microsoft Entra ID nemůže stáhnout CRL, ověřování na základě certifikátu pomocí certifikátů vystavených odpovídající certifikační autoritou selže. Osvědčeným postupem je zachovat soubory seznamu CRL v mezích limitů velikosti, zachovat životnost certifikátů v přiměřené mezích a vyčistit prošlé certifikáty. Další informace najdete v tématu Omezení velikosti seznamu CRL?.

Když uživatel provede interaktivní přihlášení pomocí certifikátu a CRL překročí interaktivní limit cloudu, jeho počáteční přihlášení selže s následující chybou:

Seznam odvolaných certifikátů stažený z {uri} překročil maximální povolenou velikost ({size} bajtů) pro seznamy CRL v MICROSOFT Entra ID. Zkuste to znovu za několik minut. Pokud problém přetrvává, obraťte se na správce tenanta.

Po chybě se Microsoft Entra ID pokusí stáhnout CRL v souladu s limity na straně služby (45 MB ve veřejném ID Entra a 150 MB v cloudech Azure US Government).

Důležité

Pokud správce přeskočí konfiguraci seznamu CRL, Microsoft Entra ID neprovádí žádné kontroly seznamu CRL během ověřování uživatele na základě certifikátu. To může být užitečné pro počáteční řešení potíží, ale nemělo by se brát v úvahu pro produkční použití.

Od této chvíle nepodporujeme protokol OCSP (Online Certificate Status Protocol) z důvodů výkonu a spolehlivosti. Místo stažení seznamu CRL při každém připojení klientským prohlížečem pro OCSP stáhne Microsoft Entra ID při prvním přihlášení a uloží ho do mezipaměti, čímž se zlepší výkon a spolehlivost ověření seznamu CRL. Také indexujeme mezipaměť, aby vyhledávání bylo při každém hledání mnohem rychlejší. Zákazníci musí publikovat seznamy CRL pro odvolání certifikátu.

Následující kroky představují typický tok kontroly seznamu CRL:

1. Id Microsoft Entra se pokusí stáhnout CRL při prvním přihlášení libovolného uživatele s certifikátem odpovídajícího důvěryhodného vystavitele nebo certifikační autority.
2. Microsoft Entra ID ukládá do mezipaměti a znovu používá CRL pro jakékoli následné použití. Respektuje datum příští aktualizace a pokud je k dispozici, datum publikování seznamu CRL (používané certifikačními autoritami systému Windows Server) v dokumentu seznamu CRL.
3. Ověřování na základě certifikátů uživatele selže, pokud:

   • Pro důvěryhodného vystavitele byl nakonfigurovaný CRL a ID Microsoft Entra nemůže stáhnout CRL kvůli dostupnosti, velikosti nebo omezení latence.

   • Certifikát uživatele je uvedený jako odvolaný v seznamu CRL.

     

   • Microsoft Entra ID se pokusí stáhnout nový CRL z distribučního bodu, pokud vypršela platnost dokumentu seznamu CRL v mezipaměti.

Poznámka:

Microsoft Entra ID zkontroluje CRL vydávající certifikační autority a další certifikační autority v řetězu důvěryhodnosti PKI až do kořenové certifikační autority. Pro ověření seznamu CRL v řetězu PKI máme limit až 10 certifikačních autorit z klientského certifikátu typu list. Cílem tohoto omezení je zajistit, aby špatný objekt actor nepřenesl službu tak, že nahraje řetězec PKI s velkým počtem certifikačních autorit s větší velikostí seznamu CRL. Pokud má řetězec infrastruktury veřejných klíčů tenanta více než 5 certifikačních autorit a v případě ohrožení zabezpečení certifikační autority by měl správce odebrat ohroženého důvěryhodného vystavitele z konfigurace tenanta Microsoft Entra.

Důležité

Vzhledem k povaze cyklů ukládání seznamu CRL do mezipaměti a publikování se důrazně doporučuje v případě odvolání certifikátu odvolat také všechny relace ovlivněného uživatele v Microsoft Entra ID.

Odteď neexistuje způsob, jak ručně vynutit stahování seznamu CRL ani ho znovu opakovat.

Postup konfigurace odvolání

Pokud chcete odvolat klientský certifikát, Microsoft Entra ID načte seznam odvolaných certifikátů (CRL) z adres URL nahraných jako součást informací certifikační autority a uloží ho do mezipaměti. Poslední časové razítko publikování (vlastnost Effective Date ) v seznamu CRL se používá k zajištění, že seznam CRL je stále platný. Seznam CRL se pravidelně odkazuje na odvolání přístupu k certifikátům, které jsou součástí seznamu.

Pokud je vyžadováno okamžité odvolání (například pokud uživatel ztratí zařízení), může být autorizační token uživatele zneplatněný. Pokud chcete autorizační token zneplatnit, nastavte pole StsRefreshTokenValidFrom pro tohoto konkrétního uživatele pomocí Prostředí Windows PowerShell. Je nutné aktualizovat pole StsRefreshTokenValidFrom pro každého uživatele, pro kterého chcete odvolat přístup.

Chcete-li zajistit zachování odvolání, je nutné nastavit datum účinnosti seznamu CRL na datum po hodnotě nastavené stsRefreshTokenValidFrom a zajistit, aby příslušný certifikát byl v seznamu CRL.

Poznámka:

Moduly Azure AD a MSOnline PowerShell jsou od 30. března 2024 zastaralé. Další informace najdete v aktualizaci vyřazení. Po tomto datu je podpora těchto modulů omezená na pomoc s migrací na sadu Microsoft Graph PowerShell SDK a opravy zabezpečení. Zastaralé moduly budou dál fungovat až do 30. března 2025.

Doporučujeme migrovat na Microsoft Graph PowerShell , abyste mohli pracovat s Microsoft Entra ID (dříve Azure AD). Běžné dotazy k migraci najdete v nejčastějších dotazech k migraci. Poznámka: Verze 1.0.x msOnline mohou dojít k přerušení po 30. červnu 2024.

Následující kroky popisují proces aktualizace a zneplatnění autorizačního tokenu nastavením pole StsRefreshTokenValidFrom .

1. Připojení do PowerShellu:

   Connect-MgGraph
   

2. Načtěte aktuální hodnotu StsRefreshTokensValidFrom pro uživatele:

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

3. Nakonfigurujte novou hodnotu StsRefreshTokensValidFrom pro uživatele, který se rovná aktuálnímu časovému razítku:

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

Datum, které nastavíte, musí být v budoucnu. Pokud datum není v budoucnu, StsRefreshTokensValidFrom vlastnost není nastavena. Pokud je datum v budoucnu, StsRefreshTokensValidFrom je nastaven na aktuální čas (nikoli datum označené příkazem Set-MsolUser).

Jak CBA funguje se zásadami síly ověřování podmíněného přístupu

Zákazníci můžou vytvořit zásadu síly ověřování podmíněného přístupu, která určí, že se pro přístup k prostředku použije jazyk CBA.

Můžete použít integrovanou sílu ověřování MFA odolnou proti útokům phishing. Tato zásada povoluje 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í sílu ověřování, která umožní přístup k citlivým prostředkům jenom CBA. Jazyk CBA můžete povolit jako jednofaktorový, vícefaktorový nebo obojí. Další informace najdete v tématu Síla ověřování podmíněného přístupu.

Síla ověřování CBA s pokročilými možnostmi

V zásadách metod ověřování CBA může správce určit sílu certifikátu pomocí zásad vazby ověřování v metodě CBA. Teď můžete nakonfigurovat pokročilé možnosti při vytváření vlastní síly ověřování tak, aby se vyžadovalo 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. 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.

Principy protokolů přihlašování

Protokoly přihlašování poskytují informace o přihlášení a způsobu, jakým vaše prostředky používají vaši uživatelé. Další informace o protokolech přihlašování najdete v tématu Protokoly přihlašování v Microsoft Entra ID.

Pojďme si projít dva scénáře, kdy certifikát splňuje jednofaktorové ověřování a druhý, kde certifikát splňuje vícefaktorové ověřování.

Pro testovací scénáře zvolte uživatele se zásadami podmíněného přístupu, které vyžadují vícefaktorové ověřování. Nakonfigurujte zásadu vazby uživatele mapováním hlavního názvu sítě SAN na userPrincipalName.

Uživatelský certifikát by měl být nakonfigurovaný jako tento snímek 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í poskytují všechny informace pro ladění problémů s přihlášením uživatele, existují časy, kdy jsou vyžadovány konkrétní hodnoty a vzhledem k tomu, že protokoly přihlašování nepodporují dynamické proměnné, protokoly přihlašování by chyběly. Příklad: Důvod selhání v protokolu přihlášení by zobrazil něco jako "Seznam odvolaných certifikátů (CRL) selhal ověření podpisu. Očekávaný identifikátor klíče subjektu {expectedSKI} neodpovídá klíči autority CRL {crlAK}. Požádejte správce tenanta, aby zkontroloval konfiguraci seznamu CRL. Kde {expectedSKI} a {crlAKI} nejsou vyplněné správnými hodnotami.

Když se uživatelům přihlášení pomocí CBA nepodaří, zkopírujte podrobnosti protokolu z odkazu Další podrobnosti na chybové stránce. Podrobnější informace najdete na stránce s informacemi o chybách CBA.

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

Pro první testovací scénář nakonfigurujte zásady ověřování, ve kterých pravidlo subjektu vystavitele 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, kde pravidlo subjektu vystavitele splňuje jednofaktorové ověřování.

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

   Pojďme se podrobněji podívat na některé položky, které najdete v protokolech přihlášení.

   První položka vyžaduje certifikát X.509 od uživatele. Stav Přerušeno znamená, že ID Entra Microsoftu ověřilo, že je v tenantovi povolený jazyk CBA a že se požaduje certifikát pro ověření.

   

   Podrobnosti o aktivitě ukazují, že je to jen část očekávaného toku přihlášení, kde uživatel vybere certifikát.

   

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

   

   Tyto další 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á k prostředku přístup.

   

Testování vícefaktorového ověřování

Pro další testovací scénář nakonfigurujte zásady ověřování, ve kterých pravidlo policyOID 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 splňovala vícefaktorové ověřování, přihlášení uživatele je úspěšné bez druhého faktoru.

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

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

   

   Podrobnosti o aktivitě ukazují, že je to jen část očekávaného toku přihlášení, kde uživatel vybere certifikát.

   

   Položka se stavem Přerušení obsahuje 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: Hlavní název; Atribut uživatele: userPrincipalName; Pořadí: 1 Toto ukazuje, které pole certifikátu SAN PrincipalName bylo namapováno na atribut uživatele userPrincipalName a má prioritu 1.
   Úroveň ověřování uživatelských certifikátů	multiFactorAuthentication
   Typ úrovně ověřování uživatelských certifikátů	PolicyId To 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í se hodnota identifikátoru identifikátoru OID z certifikátu.

Vysvětlení chybové stránky ověřování na základě certifikátu

Ověření na základě certifikátu může selhat z důvodů, jako je neplatný certifikát, nebo uživatel vybral nesprávný certifikát nebo certifikát s vypršenou platností nebo kvůli problému se seznamem odvolaných certifikátů (CRL). Když ověření certifikátu selže, zobrazí se uživateli tato chyba:

Pokud CBA v prohlížeči selže, i když je příčinou selhání zrušení výběru certifikátu, musíte zavřít relaci prohlížeče a otevřít novou relaci, abyste mohli CBA zkusit znovu. Vyžaduje se nová relace, protože prohlížeče ukládají certifikát do mezipaměti. Po opakování pokusu o obnovení jazyka CBA prohlížeč odešle certifikát uložený v mezipaměti během výzvy PROTOKOLU TLS, což způsobí selhání přihlášení a chybu ověření.

Vyberte Další podrobnosti a získejte informace o protokolování, které se dají odeslat správci, který pak může získat další informace z protokolů přihlášení.

Vyberte Další způsoby, jak se přihlásit, a vyzkoušejte další metody, které má uživatel k přihlášení k dispozici.

Poznámka:

Pokud v prohlížeči zkusíte CBA zopakovat, kvůli problému s ukládáním do mezipaměti prohlížeče se to pořád nedaří. Uživatelé musí otevřít novou relaci prohlížeče a znovu se přihlásit.

Ověřování na základě certifikátů v metodách MostRecentlyUsed (MRU)

Jakmile se uživatel úspěšně ověří pomocí jazyka CBA, nastaví se metoda ověřování MostRecentlyUsed (MRU) uživatele na CBA. Když příště uživatel zadá hlavní název uživatele (UPN) a vybere Další, uživatel se přestěhodí přímo do metody CBA a nemusí vybrat Použít certifikát nebo čipovou kartu.

Pokud chcete resetovat metodu MRU, musí uživatel zrušit výběr certifikátu, vybrat Další způsoby přihlášení a vybrat jinou metodu dostupnou pro uživatele a úspěšně ověřit.

Podpora externí identity

Externí identita nemůže pro tenanta prostředku provádět vícefaktorové ověřování pomocí jazyka Microsoft Entra CBA. Místo toho požádejte uživatele, aby provedl vícefaktorové ověřování pomocí CBA v domovském tenantovi a nastavili pro něj nastavení mezi tenanty, aby důvěřoval vícefaktorovému ověřování z domovského tenanta.

Další informace o povolení vícefaktorového ověřování důvěryhodnosti z tenantů Microsoft Entra najdete v tématu Konfigurace přístupu mezi tenanty spolupráce B2B.

Další kroky

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