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í domovské sféry pomocí názvu nájemce a uživatelské jméno slouží k vyhledání uživatele v nájemci.

   

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 naleznete v tématu Jak povolit Microsoft Entra CBA?.

   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. Vypněte kontrolu protokolu TLS na koncovém bodu ověřování certifikátu a ujistěte se, že požadavek na klientský certifikát proběhne úspěšně jako součást 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. Použijte regulární výraz k tomu, abyste umožnili fungování staré i nové adresy URL pro vypnutí kontroly protokolu TLS. Například v závislosti na proxy serveru použijte *.certauth.login.microsoftonline.com nebo *certauth.login.microsoftonline.com. V Azure Government použijte *.certauth.login.microsoftonline.us nebo *certauth.login.microsoftonline.us.

   Není-li přístup povolen, ověřování pomocí certifikátů selže, pokud povolíte rady vydavatele.

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ě přihlásí. 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. Microsoft Entra ID dokončí proces přihlášení tím, že odešle zpět primární obnovovací token, čímž potvrdí úspěšné přihlášení.

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

Principy tipů vystavitele (Preview)

Podněty vystavitele zasílají zpět důvěryhodnou indikaci CA jako součást procesu handshake protokolu TLS. Seznam důvěryhodných certifikačních autorit je nastaven na základě 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.

Povolte nápovědy vystavitele

Chcete-li povolit zaškrtnutí políčka Rady vystavitele. Správci zásad ověřování by měli vybrat Souhlasím poté, co se ujistí, že proxy server s povolenou kontrolou TLS je 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ěry certifikační autority

Jakmile povolíte indikace vystavitele a přidáte, aktualizujete nebo odstraníte certifikační autority ze stavu důvěry, může dojít ke zpoždění až 10 minut, než se indikace vystavitele vrátí zpět ke klientovi. Uživatelé se nemůžou ověřovat pomocí certifikátů vydaných novými certifikačními autoritami, dokud nebudou zavedeny potřebné pokyny.

Správci zásad pro ověřování se mají přihlásit pomocí certifikátu poté, co aktivují pokyny 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 přístupové 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 způsob, jak získat vícefaktorové ověřování a zaregistrovat přihlašování bez hesla nebo FIDO2 ještě před přihlášením 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í CBA může uživateli umožnit 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 nemá uživatel zaregistrovanou žádnou jinou metodu vícefaktorového ověřování (MFA) a je přidán do rozsahu pro metodu ověřování CBA, nemůže dokončit ověření potřebné k registraci dalších ověřovacích metod a tím získávat 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 povoleným CBA ještě nebyl vydán certifikát a potřebuje dokončit vícefaktorové ověřování:

1. Správce zásad ověřování může vydat předběžný 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í může vydat předběžný přístupový průkaz (NEBO)
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 Entra ID>Vícefaktorové ověřování>Další nastavení cloudového vícefaktorového ověřování.

   

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

   

Tok ověřování MFA pomocí jednofaktorových certifikátů a přihlášení 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 nakonfigurován jako jednofaktorové ověřování, uživatel potřebuje druhý faktor k 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.

Pochopení zásady 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í mohou změnit výchozí hodnotu z jednofaktoru na vícefaktorovou nebo nastavit vlastní konfigurace zásad pomocí polí subjektů vystavitele nebo OID zásad, nebo kombinací obou, ve 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 životního cyklu řízení.

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 Microsoft Entra ID řeší pravidla přiřazení vícenásobných zásad ověřování

Vzhledem k tomu, že lze vytvořit více pravidel zásad propojení vlastního ověřování s různými poli certifikátů, jako je použití vystavitele + identifikátoru zásad (OID), pouze identifikátoru zásad (OID), 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 pro identifikátor vystavitele a zásad OID mají přednost před pravidly OID zásad. Pravidla identifikátoru zásad mají přednost před pravidly vystavitele certifikátů.
2. Pravidla vystavitele a OID zásad se vyhodnocují jako první. Pokud máte vlastní pravidlo s vystavitelem CA1 a OID zásady 1.2.3.4.5 s vícefaktorovým ověřováním (MFA), bude MFA udělen pouze certifikát A, který splňuje jak hodnotu vystavitele, tak OID 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 používající CA vydavatele.
6. Pokud má certifikát jak identifikátor zásad OID, tak pravidla vystavitele odpovídající, identifikátor zásady se vždy kontroluje jako první, a pokud se žádné pravidlo zásad nenajde, pak se zkontrolují vazby vystavitele. OID zásad má vyšší prioritu vazby silného ověřování než vystavující subjekt.
7. Pokud je jedna certifikační autorita propojena s vícefaktorovým ověřováním, všechny uživatelské certifikáty, které vydá, jsou kvalifikovány jako MFA. Stejná logika platí pro jednofaktorové ověřování.
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 autentizační vazbu (to znamená, že certifikát nemůže být propojen jak s jednofaktorovým, tak 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 autentizace CBA, která používají buď identifikátor vystavitele NEBO identifikátor OID zásady, nejsou ovlivněna. Aby mírnili rizika, správci zásad ověřování by měli:

• 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 buď identifikátoru Vystavitel nebo identifikátoru zásad a uložit změny. NEBO
• Odeberte pravidlo zásad ověřování, které aktuálně používá OID vystavitele a zásad, a vytvořte pravidla pouze s použitím OID vystavitele nebo zásad.

Pracujeme na opravě problému.

Porozumění 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 mající vysokou afinitu, pokud jsou založené na identifikátorech, které nemůžete opakovaně použít, jako jsou identifikátory klíče subjektu (SKI) 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 s nízkou afinitou. Microsoft Entra ID implementuje tři přiřazení považovaná za nízkou afinitu na základě opakovaně použitelných identifikátorů. Ostatní jsou považovány za vazby s vysokou afinitou. Další informace najdete v tématu certificateUserIds.

Pole mapování certifikátu	Příklady hodnot v certificateUserIds	Atributy objektu uživatele	Typ
HlavníNázev	X509:<PN>bob@woodgrove.com	uživatelské hlavní jméno onPremisesUserPrincipalName identifikátoryUživatelůCertifikátu	nízká afinita
RFC822Name	X509:<RFC822>user@woodgrove.com	uživatelské hlavní jméno onPremisesUserPrincipalName identifikátoryUživatelůCertifikátu	nízká afinita
VydavatelAPředmět	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	identifikátoryUživatelůCertifikátu	nízká afinita
Předmět	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	identifikátoryUživatelůCertifikátu	nízká afinita
LYŽE	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	identifikátoryUživatelůCertifikátu	vysoká afinita
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR Hodnota SHA1PublicKey (hash SHA1 celého obsahu certifikátu včetně veřejného klíče) se nachází ve vlastnosti kryptografického otisku certifikátu.	identifikátoryUživatelůCertifikátu	vysoká afinita
VydavatelASériovéČíslo	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	identifikátoryUživatelůCertifikátu	vysoká afinita

Důležité

K vyhledání správných hodnot CertificateUserIds pro uživatele z certifikátu koncového uživatele můžete použít modul PowerShellu CertificateBasedAuthentication .

Definování vazby affinity na úrovni tenanta a přepsání pomocí vlastních pravidel

Pomocí této funkce může administrátor zásad ověřování nakonfigurovat, zda může být uživatel ověřen pomocí vazebného mapování uživatelského jména s nízkým, nebo vysokým spřažením. Pro nájemce můžete nastavit povinnou vazbu afinity, 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 identifikátoru zásad nebo na identifikátoru zásad, nebo na vystaviteli.

Jak Microsoft Entra ID řeší pravidla pro přiřazení více zásad uživatelských jmen

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 vysokým spřažením 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ým spřažením.
4. Vyhodnoťte každou vazbu v seznamu, dokud nedojde k úspěšnému ověření.
5. Pokud je pole certifikátu X.509 nakonfigurované vazby na prezentovaném certifikátu, ID Microsoft Entra porovnává hodnotu v poli certifikátu s hodnotou atributu objektu uživatele.
   1. Pokud se najde shoda, ověření uživatele proběhne úspěšně.
   2. Pokud se shoda nenajde, přejděte na další prioritní vazbu.
6. Pokud pole certifikátu X.509 není na předloženém certifikátu, přejděte na další prioritní svázání.
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, je ověřování Microsoft Entra CBA stejně zabezpečené jako vaše vazba s nejnižším zabezpečením, protože CBA ověřuje každou přidruženou vazbu pro autentizaci 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 namapovat jeden certifikát na více účtů, musí správce zásad ověřování zajistit, aby všechny povolené metody nakonfigurované v rámci zásad mapovaly 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 nakonfigurováno více metod připojení, měl by správce politik ověřování zajistit, aby neměl více než jedno připojení s nízkou prioritou.

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 pro cloud U účtů jen pro cloud 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 afinitou, například vazby Issuer + SerialNumber, hodnoty v rámci CertificateUserIds mohou vypadat následovně:

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 U synchronizovaných účtů 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 vysokou afinitou (tj. 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 administrativní účty. Může se jednat také o účty pro vývojáře nebo o dočasné pracovní účty. V tradiční službě AD se k naplnění hodnot certifikátu používá pole altSecurityIdentities a během přihlašování je použit návod k nasměrování AD na požadovaný účet pro ověření přihlášení. U Microsoft Entra CBA je to jiné a není k dispozici žádná nápověda. Home Realm Discovery místo toho identifikuje požadovaný účet ke kontrole 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 pro cloud U cloudových účtů potřebujete 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á připojení s vysokou afinitou (to znamená silné ověřování), například kombinace vydavatel + sériové číslo a SKI, může to vypadat takto:

Vazby uživatelského jména:

• Vystavitel + sériové číslo –> IdentifikátoryUživatelůCertifikátu
• 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í Issuer+SerialNumber a druhý pomocí SKI vazby.

Poznámka:

Počet účtů, které lze tímto způsobem použít, je omezen počtem vazeb uživatelského jména nakonfigurovaných v tenantovi. Pokud organizace používá pouze vazby s vysokou afinitou, počet podporovaných účtů je omezen na 3. Pokud organizace také využívá vazby s nízkou afinitou, počet se zvýší na 7 účtů (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Hybridní synchronizované účty U synchronizovaných účtů 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ždý les 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 developer, pak filtrujeme podle hodnoty 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í ani následná 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. Proveďte synchronizační cyklus k dokončení naplnění dat v Microsoft Entra ID.

Ujistěte se, že je CBA v každém tenantovi nakonfigurovaný s vázáními uživatelského jména odkazujícími na pole certificateUserIds pro typy polí, které jste namapovali ze 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 se nemohl použít 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 odvolaných certifikátů (CRL) pro Microsoft Entra ID, který lze úspěšně stáhnout během interaktivního přihlašování a uložit do mezipaměti, je 20 MB ve veřejném prostředí Microsoft Entra ID a 45 MB v cloudech Azure US Government. Doba potřebná ke stažení tohoto seznamu by neměla přesáhnout 10 sekund. Pokud Microsoft Entra ID nemůže stáhnout CRL, ověřování na základě certifikátů vystavených odpovídající certifikační autoritou selže. Osvědčeným postupem je udržovat soubory seznamu CRL v mezích velikosti, omezit životnost certifikátů v přijatelných mezích a odstraňovat prošlé certifikáty. Další informace najdete v článku Existuje omezení velikosti 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 ověřování CRL, jehož výkon a spolehlivost jsou vyšší. 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. Microsoft Entra ID se pokusí stáhnout CRL při prvním přihlášení libovolného uživatele, který má certifikát od příslušné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 příštího publikování CRL (používané certifikačními autoritami systému Windows Server) v dokumentu 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 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 škodlivý aktér neochromil službu tím, že nahraje řetězec PKI s velkým počtem certifikačních autorit a větší velikostí CRL seznamu. Pokud má řetězec PKI tenanta více než 5 certifikačních autorit a pokud dojde k ohrožení zabezpečení certifikační autority, měli by správci zásad ověřování odebrat ohrožené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, aby v případě odvolání certifikátu byly rovněž zrušeny všechny relace dotčeného uživatele v systému Microsoft Entra ID.

V současné době neexistuje způsob, jak ručně vynutit nebo znovu spustit stažení CRL.

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ý. CRL je pravidelně kontrolován, aby byly zrušeny certifikáty, 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 StsRefreshTokensValidFrom pro tohoto konkrétního uživatele pomocí Windows PowerShellu. Je nutné aktualizovat pole StsRefreshTokensValidFrom 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é stsRefreshTokensValidFrom a zajistit, aby příslušný certifikát byl v seznamu CRL.

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

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

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

Pochopení ověřování CRL

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. Je možné nahrát certifikační autoritu bez koncového bodu seznamu CRL a ověřování na základě certifikátu se neztratí, pokud vydávající certifikační autorita nemá zadaný seznam 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.

Povolit ověřování CRL

Pokud chcete povolit ověření 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 vyberte všechny certifikační autority, které by měly být vyloučeny.

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.

Vyberte certifikační autority a klikněte na Přidat. Pomocí textového pole Hledat můžete filtrovat seznamy certifikačních autorit a vybrat konkrétní certifikační autority.

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

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

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

klíčové výhody

• Omezení využití certifikátů na konkrétní skupiny uživatelů
• Podpora složitých prostředí PKI s několika certifikačními autoritami
• Vylepšená ochrana před zneužitím nebo ohrožením zabezpečení certifikátu
• Přehled o využití certifikační autority prostřednictvím protokolů přihlašování a monitorovacích nástrojů

Určení rozsahu certifikační autority umožňuje správcům definovat pravidla, která přidružují certifikační autoritu (identifikovanou identifikátorem klíče subjektu nebo SKI) ke konkrétní skupině Microsoft Entra. Když se uživatel pokusí ověřit pomocí certifikátu, systém zkontroluje, jestli je vydávající certifikační autorita certifikátu vymezená na skupinu, která uživatele obsahuje. Entra prochází řetězec certifikačních autorit a aplikuje všechna pravidla oboru, dokud se uživatel nenajde v jedné ze skupin v rámci všech pravidel oboru. Pokud uživatel není ve skupině s vymezeným oborem, ověřování selže, i když je certifikát jinak platný.

Postup povolení funkce nastavení rozsahu certifikační autority

1. Přihlaste se do Centra pro správu Microsoft Entra jako alespoň správce zásad ověřování.
2. Přejděte k Entra ID>metodám ověřování>autentizace založená na certifikátech.
3. V části Konfigurovat přejděte do zásady vymezování vystavitele certifikátů.

1. Vyberte Přidat pravidlo

1. Vyberte Filtrovat certifikační autority podle infrastruktury veřejných klíčů. Classic CA zobrazí všechny CAs z klasického úložiště CA a po výběru konkrétního PKI se zobrazí všechny CAs z vybraného PKI. Vyberte PKI.

1. Rozevírací seznam vystavitele certifikátu zobrazí všechny certifikační autority z vybrané infrastruktury veřejných klíčů. Vyberte certifikační autoritu pro vytvoření pravidla oboru.

1. Vybrat Přidat skupinu

1. Výběr skupiny

1. Vyberte Přidat pro uložení pravidla.

1. Vyberte Potvrzení a vyberte Uložit a uložte konfiguraci CBA.

1. Pokud chcete upravit nebo odstranit zásadu oboru certifikační autority, klikněte na "..." na řádku pravidla. Chcete-li pravidlo upravit, vyberte upravit pravidlo a odstranit pravidlo.

Známá omezení

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

Položky protokolu přihlášení

• V protokolu přihlášení se zobrazí úspěch a na kartě Další podrobnosti se zobrazí SKI certifikační autority podle pravidla zásad určení rozsahu.

• Pokud se ověření CBA nezdaří kvůli pravidlu pro rozsah certifikační autority, zobrazí se v protokolu přihlašování na kartě Základní informace chybový kód 500189.

• Koncoví uživatelé uvidí níže uvedenou chybovou zprávu.

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

Zákazníci mohou vytvořit zásadu síly ověřování pro podmíněný přístup, která určuje, že se pro přístup k prostředku použije ověřování na základě certifikátů (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í úroveň ověřování, aby jenom CBA mělo přístup k citlivým prostředkům. Můžete povolit CBA jako jednofaktorový, vícefaktorový, nebo oboje zároveň. Další informace najdete v tématu Síla ověřování podmíněného přístupu.

Úroveň zabezpečení 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. Nyní můžete nakonfigurovat pokročilé možnosti při vytváření vlastní úrovně silného ověřování tak, aby se vyžadovalo, že specifický certifikát musí být použit na základě OID identifikátorů vystavitele a zásad, když uživatelé provádějí CBA při přístupu 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.

Porozumění protokolům 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. Například: Důvod selhání v protokolu přihlášení by zobrazil něco jako "Seznam odvolaných certifikátů (CRL) selhalo 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 tam, kde pravidlo subjektu vystavitele umožňuje jednofaktorové ověření.

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ů	vícefaktorová autentizace
   Typ úrovně ověřování uživatelských certifikátů	Identifikátor politiky To ukazuje, že OID zásady byl použit k určení síly autentizace.
   Identifikátor na úrovni ověřování uživatelských certifikátů	1.2.3.4 Zobrazí hodnotu politiky identifikátoru OID z certifikátu.

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. Při opakování CBA prohlížeč během výzvy protokolu TLS odešle certifikát uložený v mezipaměti, což způsobí selhání přihlášení a chybu při ověřování.

Poznámka:

Prohlížeč Edge ale přidal novou funkci pro resetování výběru certifikátu bez restartování prohlížeče.

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.

Resetování volby certifikátu v prohlížeči Edge

Pokud CBA selže v prohlížeči, 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 a zkusit CBA znovu, protože prohlížeč ukládá certifikát do mezipaměti. Prohlížeč Edge ale přidal nové vylepšení pro resetování výběru certifikátu v prohlížeči.

• Když CBA selže, uživatel se odešle na chybovou stránku.

• Vyberte ikonu zámku vlevo od adresy URL a vyberte Vaše volby certifikátu.

• Vyberte Obnovit výběr certifikátů

• Vyberte Obnovit volby v dialogovém okně

• Klikněte na Další způsoby přihlášení na chybové stránce.

• Ve výběru vyberte Použít certifikát nebo čipovou kartu a pokračujte v ověřování CBA.

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

Jakmile se uživatel úspěšně ověří pomocí CBA, jeho nedávno použitá metoda ověřování (MRU) se nastaví 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.

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

Podpora externí identity

Externí hostující uživatel B2B může použít CBA na domovském tenantovi a pokud je nastavení mezi tenanty pro tenant prostředku nastaveno tak, aby důvěřovalo vícefaktorovému ověřování z domovského tenanta, je respektováno 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 tenantu zdrojů není dosud podporováno.

Další kroky

• Přehled Microsoft Entra CBA
• Jak nakonfigurovat Microsoft Entra CBA
• Microsoft Entra CBA na zařízeních s iOSem
• Microsoft Entra CBA na zařízeních s Androidem
• Přihlášení pomocí chytré karty ve Windows prostřednictvím Microsoft Entra CBA
• ID uživatele certifikátu
• Migrace federovaných uživatelů
• Nejčastější dotazy
• Řešení potíží s Microsoft Entra CBA