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.

Jaké jsou následující 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 přihlášení k telefonu 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 na koncový bod ověření certifikátu, což je https://certauth.login.microsoftonline.com pro veřejné ID Microsoft 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. V protokolu přihlášení se zobrazí položka pro tento požadavek.

   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 rady vystavitele.

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

   

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.

Principy tipů vystavitele (Preview)

Rady vystavitele odesílají zpět označení 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 (CA) nahraných tenantem v úložišti důvěryhodnosti Entra. Klient prohlížeče nebo nativní klient aplikace může použít nápovědy odeslané serverem 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.

Povolení nápovědy vystavitele

Chcete-li povolit zaškrtnutí políčka Rady vystavitele. Správci zásad ověřování by měli vybrat Potvrzuji po ověření, zda je proxy server s povolenou kontrolou protokolu TLS správně aktualizován, a uložit.

Poznámka:

Pokud má vaše organizace brány firewall nebo proxy servery s kontrolou TLS, uvědomte si, že jste zakázali inspekci TLS koncového bodu certauth, který umožňuje ověřit shodu libovolného názvu v rámci [*.]certauth.login.microsoftonline.com, přizpůsobeného specifikům používaného proxy serveru.

Poznámka:

Adresa URL certifikační autority je ve formátu t{tenantId}.certauth.login.microsoftonline.com poté, co jsou povoleny náznaky vystavitele.

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

Jakmile povolíte rady vystavitele a přidáte, aktualizujete nebo odstraníte certifikační autority ze stavu důvěryhodnosti, dojde ke zpoždění až 10 minut, než se do klienta rozšíří rady vystavitele. Uživatelé se nemůžou ověřovat pomocí certifikátů vydaných novými certifikačními autoritami, dokud nebudou rozšířeny rady.

Správci zásad ověřování by se měli přihlásit pomocí certifikátu poté, co povolí rady vystavitele, aby zahájili šíření. Když jsou aktualizace úložiště důvěryhodných certifikátů v propagaci, zobrazí se uživatelům následující chybová zpráva.

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

Microsoft Entra CBA je podporováno jako první faktor i druhý faktor autentizace. Mezi podporované kombinace patří:

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

Poznámka:

CBA jako druhý faktor v iOSu má známé problémy a je blokovaný v iOSu. Pracujeme na řešení problémů a měli bychom je podporovat v iOSu.

Uživatelé musí mít možnost 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 je považován za způsobilého pro MFA, když je zahrnut 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.

Možnosti získání funkce vícefaktorového ověřování s jednofaktorovými certifikáty

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 s jednofaktorovým certifikátem potřebuje k dokončení vícefaktorového ověřování další faktor, což je důvod, proč nepovolíme registraci jiných metod bez splnění vícefaktorového ověřování. Pokud uživatel nemá zaregistrovanou žádnou jinou ověřovací metodu MFA a je přiřazen do oblasti pro ověřovací metodu CBA, nemůže provést potřebné kroky k registraci dalších ověřovacích metod a tím získat vícefaktorové ověřování.

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žití hesla a certifikátu SF (OR)
2. Správce zásad ověřování může vydat předběžný přístupový průkaz (NEBO)
3. Správce zásad ověřování přidá 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. Správce politiky ověřování může vydat dočasný přístupový průkaz (NEBO)
2. Správce zásad ověřování přidá 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. Správce zásad ověřování přístupu může vydat dočasný přístupový kód.
2. Uživatel musí zaregistrovat jinou metodu MFA (pokud uživatel může použít certifikát MF na některém zařízení) (NEBO).
3. Správce zásad ověřování přidá telefonní číslo a povolí ověřování hlasových a textových zpráv pro uživatelský účet.

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ň správce zásad ověřování.

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í>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 je přihlášení k telefonu 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ávci zásad ověřování můžou 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ávci zásad ověřování můžou 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. 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é.

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 OID zásad 1.2.3.4.5, které vyžaduje vícefaktorové ověřování, pouze certifikát A, který splňuje jak hodnotu vystavitele, tak OID zásad, získává vícefaktorové ověřování.
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 zásad ověřování Microsoft Entra konfiguruje pravidlo zásad ověřování CBA pomocí identifikátoru vystavitele i identifikátoru zásad, což ovlivňuje některé scénáře registrace zařízení, jako například:

• 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 pracovišti, Microsoft Entra ID a Hybridní připojení zařízení Microsoft Entra nejsou ovlivněné. Pravidla pro ověřování CBA, která používají buď identifikátor vystavitele NEBO identifikátor OID zásady, nejsou ovlivněna. Správci zásad ověřování by měli zmírnit následující:

• 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ŽE	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	vysoká spřažení
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	certificateUserIds	vysoká spřažení
IssuerAndSerialNumber (Preview)	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í

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

Pomocí této funkce může správce zásad ověřování nakonfigurovat, jestli se uživatel může ověřit pomocí mapování vazby 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 nastavené správcem zásad ověřování v konfiguraci metody ověřování CBA seřazené podle atributu priority. V současné době se koncept priority nezobrazuje v uživatelském prostředí portálu. Graph 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, což umožňuje správci zásad ověřování přizpůsobit jeden certifikát více konfigurací uživatelských účtů Microsoft 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 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 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 vazby, 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í.

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 pouze 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, a implementovat mapování SKI v atributu certificateUserId stejného účtu.

Podpora více certifikátů pomocí jednoho uživatelského účtu Microsoft 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>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

V tomto příkladu první hodnota představuje X509Certificate1 a druhá hodnota představuje X509Certificate2. Uživatel může při přihlášení předložit buď certifikát, a pokud je vazba uživatelského jména CBA nastavena tak, aby odkazovalo na pole certificateUserIds pro vyhledání konkrétního typu vazby (tj. Issuer+SerialNumber v tomto příkladu), uživatel se ú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 (to znamená silné ověřování), například Issuer + SerialNumber, může to vypadat takto:

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 a druhá hodnota představuje X509Certificate2. Tyto 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)

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 k naplnění hodnot certifikátu používá pole altSecurityIdentities a během přihlašování se k nasměrování AD na požadovaný účet k přihlášení použije nápověda. 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 dva účty nemůžou naplnit stejné hodnoty certifikátu.

Důležité

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

účty pouze v cloudu Pro účty pouze v cloudu musíte vytvořit více vazeb uživatelského jména a namapovat jedinečné hodnoty na každý uživatelský účet, který má certifikát používat. Každý účet je autentizován pomocí jiného propojení uživatelského jména. To platí v rámci hranice jednoho adresáře nebo tenanta (to znamená, že správci zásad ověřování můžou mapovat certifikát pro použití v jiném adresáři nebo tenantovi, pokud hodnoty zůstanou také 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í (to znamená 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>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

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ěřuje pomocí Vydavatel+Sériové číslo a druhý 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ů je 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 liší. Správci zásad ověřování sice můžou namapovat jedinečné hodnoty na každý uživatelský účet, který certifikát používá, ale běžný postup naplnění všech hodnot na každý účet v Microsoft Entra ID to ztěžuje. Místo toho by microsoft Entra Connect měl filtrovat požadované hodnoty pro každý účet na jedinečné hodnoty naplněné do účtu v Microsoft Entra ID. Pravidlo jedinečnosti platí v rámci hranice jednoho adresáře nebo tenanta (to znamená, že správci zásad ověřování můžou mapovat certifikát pro použití v jiném adresáři nebo tenantovi, pokud hodnoty zůstanou také 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 Microsoft Entra. V tomto případě Microsoft Entra Connect 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 pro cloudový účet.

Do pole altSecurityIdentities v AD zadejte hodnoty identifikující požadovaný certifikát a zahrňte požadovanou hodnotu certifikátu pro daný typ uživatelského účtu (například detailee, admin, vývojář atd.). Vyberte klíčový atribut v AD, který určuje synchronizaci typu uživatelského účtu, který uživatel vyhodnocuje (například 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>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 se pak musí synchronizovat s polem certificateUserIds v Microsoft Entra ID.

Postup synchronizace s certificateUserIds

1. Konfigurace služby Microsoft Entra 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 používá 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 zkontrolová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ý, hodnota se zkontroluje, jestli se rovná jednomu z námi definovaných uživatelských typů. 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 Microsoft Entra ID – 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ý:

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, pak se předá AuthoritativeNull. Tím se zajistí, že předchozí nebo další pravidla, která naplní alternativníSecurityId, budou ignorována a výsledek bude prázdný v MICROSOFT Entra ID.

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 základní soubor dat v ID Microsoft 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 kterýkoli 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, že se uživatel úspěšně přihlásil.

Principy procesu odvolání certifikátu

Proces odvolání certifikátu umožňuje správcům zásad ověřování odvolat dříve vydaný certifikát, aby ho mohli používat pro budoucí ověřování. 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ávci zásad ověřování mohou 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 Microsoft Entra ID 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 MICROSOFT Entra ID a 150 MB v cloudech Azure US Government).

Důležité

Pokud správce zásad ověřování přeskočí konfiguraci seznamu CRL, microsoft Entra ID neprovede žá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 jednou při prvním přihlášení a uloží ho do mezipaměti. Tato akce zlepšuje výkon a spolehlivost ověřování 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 je nakonfigurován CRL a Microsoft Entra ID nemůže CRL stáhnout kvůli omezením dostupnosti, velikosti nebo 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 PKI tenanta více než 5 certifikačních autorit a dojde ke kompromitaci certifikační autority, měli by Administrátoři zásad ověřování odebrat kompromitovaného důvěryhodného vystavitele z konfigurace tenanta Microsoft Entra.

Důležité

Vzhledem k povaze ukládání CRL do mezipaměti a publikačních cyklů se důrazně doporučuje, v případě odvolání certifikátu, také odvolat všechny relace dotčené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í k 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).

Principy ověřování seznamu CRL (Preview)

CRL je záznam digitálních certifikátů, které byly odvolány před koncem jejich doby platnosti certifikační autoritou (CA). Když se certifikační autority nahrají do úložiště důvěryhodnosti Microsoft Entra, atribut CRL nebo konkrétněji atribut CrlDistributionPoint, není vyžadován. Certifikační autoritu je možné nahrát bez koncového bodu seznamu CRL a ověřování na základě certifikátu se nezdaří, pokud vydávající certifikační autorita nemá zadaný CRL.

Kvůli posílení zabezpečení a zabránění chybným konfiguracím může správce zásad ověřování vyžadovat, aby ověřování CBA selhalo, pokud pro certifikační autoritu, která vydává certifikát koncového uživatele, není nakonfigurovaný žádný CRL.

Povolení ověřování seznamu CRL

Pokud chcete povolit ověřování seznamu CRL, vyberte Vyžadovat ověření seznamu CRL (doporučeno).

Po povolení je selhání CBA způsobeno tím, že certifikát byl vydán koncovému uživateli certifikační autoritou bez nakonfigurovaného seznamu zrušených certifikátů (CRL).

Správce zásad ověřování může certifikační autoritu vyloučit, pokud má jeho CRL problémy, které by se měly opravit. Vyberte Přidat výjimku a určete všechny certifikační autority, které by měly být vyjmuty.

Certifikační autority v seznamu vyloučených certifikátů nemusí mít nakonfigurovaný seznam CRL a certifikáty koncových uživatelů, které vydávají, neprojdou ověřením.

Poznámka:

Existuje známý problém s výběrem objektu, kdy se vybrané položky nezobrazují správně. Pomocí karty Certifikační autority vyberte nebo odeberte certifikační autority.

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 zásad ověřování 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í

Ačkoli protokoly přihlašování poskytují všechny informace potřebné k ladění problémů s přihlášením uživatele, někdy jsou vyžadovány konkrétní hodnoty, a protože protokoly přihlašování nepodporují dynamické proměnné, může v nich chybět některé informace. 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 CRL, pokud {expectedSKI} a {crlAKI} nejsou vyplněny 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 zásad ověřování, 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 uživatele typu host B2B může použít CBA (Certifikátové bázi ohlášení) na domovském tenantovi. Pokud je nastavení křížového tenanta pro tenanta zdroje nastaveno tak, aby důvěřovalo vícefaktorovému ověřování (MFA) z domovského tenanta, je dodrženo ověřování CBA uživatele v domovském tenantovi. 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. CBA na tenantovi zdrojů zatím není podporováno.

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