Azure AD podrobné technické informace o ověřování založeném na certifikátech

Tento článek vysvětluje, jak funguje ověřování pomocí certifikátů (CBA) v Azure Active Directory (Azure AD), a uvádí technické podrobnosti o Azure AD konfiguracích CBA.

Jak funguje ověřování na základě certifikátů Azure AD?

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

Obrázek s postupem, jak funguje Azure AD ověřování pomocí certifikátů

Teď vás provedeme jednotlivými kroky:

  1. Uživatel se pokusí o přístup k aplikaci, například portálu Moje aplikace.

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

  3. Uživatel zadá své uživatelské jméno na přihlašovací stránce Azure AD a potom klikne na Další. Azure AD provádí zjišťování domovské sféry pomocí názvu tenanta a uživatelské jméno se používá k vyhledání uživatele v Azure AD tenantovi.

    Snímek obrazovky s přihlášením k portálu Moje aplikace

  4. Azure AD zkontroluje, jestli je pro tenanta povolený CBA. Pokud je CBA povolený, uživateli se na stránce s heslem zobrazí odkaz Na použití certifikátu nebo čipové karty . Pokud uživatel nevidí přihlašovací odkaz, ujistěte se, že je v tenantovi povolený CBA. Další informace najdete v tématu Návody povolení Azure AD CBA?.

    Poznámka

    Pokud je V tenantovi povolená CBA, zobrazí se všem uživatelům na stránce s heslem odkaz Použít certifikát nebo čipovou kartu . V aplikaci, která jako zprostředkovatele identity používá Azure AD, se ale budou moct úspěšně ověřit jenom uživatelé v oboru CBA.

    Snímek obrazovky s možností Použít certifikát nebo čipovou kartu

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

    Snímek obrazovky s možností Přihlášení, pokud je povolený i FIDO2

  5. Jakmile uživatel vybere ověřování na základě certifikátů, klient se přesměruje na koncový bod certauth, který je https://certauth.login.microsoftonline.com určený pro globální Azure. Pro Azure Government je https://certauth.login.microsoftonline.uskoncový bod certauth .

    Koncový bod provádí vzájemné ověřování TLS a vyžádá si klientský certifikát v rámci metody handshake protokolu TLS. V protokolu přihlášení se zobrazí položka pro tuto žádost.

    Snímek obrazovky s přihlášením Azure AD

    Poznámka

    Správce sítě by měl povolit přístup k přihlašovací stránce uživatele a koncovému bodu certauth pro cloudové prostředí zákazníka. V koncovém bodu certauth zakažte kontrolu protokolu TLS, abyste se ujistili, že žádost o klientský certifikát proběhne úspěšně v rámci metody handshake protokolu TLS.

    Kliknutím na položku protokolu zobrazte podrobnosti o aktivitě a klikněte na Podrobnosti o ověřování. Zobrazí se položka pro certifikát X.509.

    Snímek obrazovky s položkou pro certifikát X.509

  6. Azure AD požádá o klientský certifikát, uživatel vybere klientský certifikát a klikne na OK.

    Poznámka

    Pomocné funkce důvěryhodné certifikační autority nejsou podporované, takže seznam certifikátů není možné dále vymezit. Tuto funkci chceme v budoucnu přidat.

    Snímek obrazovky s výběrem certifikátu

  7. Azure AD ověří seznam odvolaných certifikátů, aby se ujistili, že certifikát není odvolaný a je platný. Azure AD identifikuje uživatele pomocí vazby uživatelského jména nakonfigurované v tenantovi pro mapování hodnoty pole certifikátu na hodnotu atributu uživatele.

  8. Pokud se najde jedinečný uživatel se zásadami podmíněného přístupu, které vyžadují vícefaktorové ověřování (MFA), a pravidlo vazby ověřování certifikátu splňuje vícefaktorové ověřování, Azure AD uživatele okamžitě přihlásit. Pokud je vyžadováno vícefaktorové ověřování, ale certifikát splňuje pouze jeden faktor, ověřování se nezdaří.

  9. Azure AD proces přihlášení dokončí odesláním primárního obnovovacího tokenu zpět, který označuje úspěšné přihlášení.

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

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

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

Silné stránky certifikátu

Správce může určit, jestli jsou certifikáty jednofaktorové nebo vícefaktorové. Další informace najdete v dokumentaci, která mapuje úrovně záruky ověřování NIST na Azure AD metody ověřování, která vychází z NIST 800-63B SP 800-63B, Pokyny pro digitální identitu: Ověřování a správa životního cyklu.

Jednofaktorové ověřování certifikátem

Pokud má uživatel jednofaktorový certifikát, nemůže provádět vícefaktorové ověřování. Druhý faktor není podporován, pokud je prvním faktorem jednofaktorový certifikát. Pracujeme na přidání podpory pro druhé faktory.

Snímek obrazovky s nepovolenou vícefaktorové ověřování pro jednofaktorový certifikát

Vícefaktorové ověřování pomocí certifikátu

Pokud má uživatel vícefaktorový certifikát, může provádět vícefaktorové ověřování pouze pomocí certifikátů. Správce tenanta by ale měl zajistit, aby certifikáty byly chráněné kódem PIN nebo hardwarovým modulem, aby byly považovány za vícefaktorové.

Jak Azure AD vyřešit několik pravidel vazeb zásad ověřování

Vzhledem k tomu, že lze vytvořit více pravidel zásad vazby ověřování s různými poli certifikátu, existuje několik pravidel, která určují úroveň ochrany ověřování. Jsou to tyto:

  1. Přesná shoda se používá pro silné ověřování pomocí identifikátoru zásad. Pokud máte certifikát A se zásadou OID 1.2.3.4.5 a odvozenými přihlašovacími údaji B založenými na tom, že má OID zásady 1.2.3.4.5.6, a vlastní pravidlo je definované jako identifikátor zásad s hodnotou 1.2.3.4.5 s vícefaktorovým ověřováním, MFA bude vyhovovat jenom certifikátu A a přihlašovací údaje B budou vyhovovat jenom jednofaktorovému ověřování. Pokud uživatel použil při přihlašování odvozené přihlašovací údaje a byl nakonfigurovaný tak, aby používal vícefaktorové ověřování, bude uživatel požádán o druhý faktor pro úspěšné ověření.
  2. Pravidla identifikátorů zásad budou mít přednost před pravidly vystavitele certifikátů. Pokud má certifikát identifikátor OID zásady i vystavitele, nejdřív se vždy zkontroluje identifikátor OID zásady, a pokud se nenajde žádné pravidlo zásad, zkontrolují se vazby předmětu vystavitele. Identifikátor zásad má vyšší prioritu silné ověřovací vazby než vystavitel.
  3. Pokud jedna certifikační autorita vytvoří vazbu na vícefaktorové ověřování, všechny uživatelské certifikáty, které certifikační autorita vydá, se považují za vícefaktorové ověřování. Stejná logika platí pro jednofaktorové ověřování.
  4. Pokud se jeden identifikátor OID zásad váže na MFA, všechny uživatelské certifikáty, které obsahují tento identifikátor zásad jako jeden z identifikátorů OID (certifikát uživatele může mít více OID zásad), se kvalifikují jako MFA.
  5. Pokud dojde ke konfliktu mezi více identifikátory OID zásad (například když má certifikát dvě OID zásad, kdy se jeden váže na jednofaktorové ověřování a druhý váže na MFA), považujte certifikát za jednofaktorové ověřování.
  6. Jeden certifikát může mít pouze jednu platnou vazbu silného ověřování (to znamená, že certifikát nemůže vytvořit vazbu na jednofaktorové ověřování i vícefaktorové ověřování).

Principy zásad vazby uživatelských jmen

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 alternativního názvu subjektu (SAN) v certifikátu mapuje na atribut UserPrincipalName objektu uživatele, který určuje uživatele.

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

Existují čtyři podporované metody. Obecně platí, že typy mapování se považují za vysoce spřažení, pokud jsou založené na identifikátorech, které nelze opakovaně použít (například identifikátory klíčů subjektu nebo veřejný klíč SHA1). Tyto identifikátory poskytují vyšší jistotu, že k ověření příslušného uživatele lze použít pouze jeden certifikát. Proto se všechny typy mapování založené na uživatelských jménech a e-mailových adresách považují za s nízkým spřažením. Proto Azure AD implementuje dvě mapování považovaná za nízkou spřažení (na základě opakovaně použitelných identifikátorů) a další dvě se považují 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 (Hlavní název uživatele)
onPremisesUserPrincipalName
identifikátory certificateUserIds
nízká spřažení
Název RFC822 "X509:<RFC822>user@woodgrove.com" userPrincipalName (Hlavní název uživatele)
onPremisesUserPrincipalName
identifikátory certificateUserIds
nízká spřažení
X509SKI "X509:<SKI>123456789abcdef" identifikátory certificateUserIds vysoká spřažení
X509SHA1PublicKey "X509:<SHA1-PUKEY>123456789abcdef" identifikátory certificateUserIds vysoká spřažení

Jak Azure AD vyřešit několik pravidel vazby zásad uživatelského jména

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

  1. Vyhledejte objekt uživatele pomocí uživatelského jména nebo hlavního názvu uživatele.
  2. Pokud je pole certifikátu X.509 na předloženém certifikátu, Azure AD bude odpovídat hodnotě v poli certifikátu hodnotě 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 s prioritou.
  3. Pokud pole certifikátu X.509 není na předloženém certifikátu, přejděte na další vazbu s prioritou.
  4. Ověřte všechny nakonfigurované vazby uživatelského jména, dokud jedna z nich nebude shodná a ověření uživatele bude úspěšné.
  5. Pokud se u žádné z nakonfigurovaných vazeb uživatelských jmen nenajde shoda, ověření uživatele se nezdaří.

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

Každý z atributů Azure AD (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds), které jsou k dispozici pro vytvoření vazby certifikátů k Azure AD uživatelským účtům, má jedinečné omezení, které zajišťuje, že certifikát odpovídá pouze jednomu Azure AD uživatelskému účtu. Azure AD ale CBA podporuje konfiguraci více metod vazby v zásadách vazby uživatelských jmen. To umožňuje správci pojmout více konfigurací certifikátů. Kombinace některých metod ale může potenciálně umožnit, aby jeden certifikát odpovídal více Azure AD uživatelským účtům.

Důležité

Při použití více vazeb je ověřování CBA Azure AD jen tak zabezpečené jako vaše vazba s nízkým spřažením, Azure AD CBA ověří každou vazbu a ověří uživatele. Aby se vyloučil scénář, kdy jeden certifikát odpovídá více účtům Azure AD, měl by správce tenanta:

  • V zásadách vazby uživatelského jména nakonfigurujte metodu jedné vazby.
  • Pokud má tenant nakonfigurovaných více metod vazby a nechce povolit jeden certifikát více účtům, musí správce tenanta zajistit, aby všechny povolené metody nakonfigurované v mapování zásad na stejný Azure AD účet, tj. 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, správce by se měl ujistit, že nemá více než jednu vazbu s nízkou spřažením.

Pokud má například správce tenanta dvě uživatelské vazby na PrincipalName namapované na hlavní název uživatele (UPN) Azure AD a SubjectKeyIdentifier (SKI) na certificateUserIds a chce, aby se certifikát používal pouze pro jeden účet Azure AD Account, musí správce zajistit, aby tento účet měl hlavní název uživatele (UPN), který je v certifikátu, a implementoval mapování SKI ve stejném atributu certificateUserId účtu.

Tady je příklad potenciálních hodnot pro hlavní název uživatele (UPN) a identifikátory certificateUserID:

Azure AD hlavní název uživatele =Bob.Smith@Contoso.com
certificateUserIDs = [x509:<SKI>89b0f468c1abea65ec22f0a882b8fda6fdd6750p]

Když jsou hodnoty PrincipalName i SKI z certifikátu uživatele namapované na stejný účet, zajistí se, že i když zásady tenanta umožňují mapování PrincipalName na Azure AD hodnoty UPN & SKI v certificateUserIds, může se tento certifikát shodovat pouze s jedním účtem Azure AD. S jedinečným omezením na userPrincipalName i certificateUserIds nemůže mít žádný jiný uživatelský účet stejné hodnoty a nemůže se úspěšně ověřit pomocí stejného certifikátu.

Principy procesu odvolání certifikátu

Proces odvolání certifikátu umožňuje správci odvolat dříve vydaný certifikát, aby se použil k budoucímu ověřování. Odvolání certifikátu neodvolá již vydané tokeny uživatele. Postupujte podle pokynů k ručnímu odvolání tokenů v tématu Konfigurace odvolání.

Azure AD stáhne seznam odvolaných certifikátů (CRL) zákazníka a ukládá ho do mezipaměti od certifikační autority, aby se zkontrolovalo, jestli se certifikáty během ověřování uživatele neodvolají.

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

Důležité

Maximální velikost seznamu CRL pro Azure AD úspěšně stáhnout při interaktivním přihlašování a ukládání do mezipaměti je 20 MB v globálním Azure a 45 MB v cloudech Azure US Government a doba potřebná ke stažení seznamu CRL nesmí překročit 10 sekund. Pokud Azure AD nemůže stáhnout CRL, ověřování pomocí certifikátů vystavených odpovídající certifikační autoritou selže. Osvědčeným postupem je udržovat soubory CRL v mezích velikosti, udržovat životnost certifikátů v přiměřených mezích a vyčistit certifikáty, jejichž platnost vypršela. Další informace najdete v tématu Existuje omezení velikosti seznamu CRL?.

Když uživatel provede interaktivní přihlášení pomocí certifikátu a počet odvolaných certifikátů překročí interaktivní limit pro cloud, jeho počáteční přihlášení selže s následující chybou:

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

Po chybě se Azure AD pokusí stáhnout CRL v souladu s limity na straně služby (45 MB v globálním Azure a 150 MB v cloudech Azure US Government).

Důležité

Pokud správce konfiguraci seznamu CRL přeskočí, Azure AD během ověřování uživatele pomocí certifikátů neprovedou žádné kontroly seznamu CRL. To může být užitečné při počátečním řešení potíží, ale nemělo by se to brát v úvahu pro použití v produkčním prostředí.

V současné chvíli 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 Azure AD stáhne soubor jednou při prvním přihlášení a uloží ho do mezipaměti, čímž se zlepší výkon a spolehlivost ověřování seznamu CRL. Také indexujeme mezipaměť, takže vyhledávání je pokaždé mnohem rychlejší. Zákazníci musí publikovat seznamy CRL pro odvolání certifikátů.

Následující kroky jsou typickým postupem kontroly seznamu CRL:

  1. Azure AD 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. Azure AD uloží do mezipaměti a znovu použije CRL pro jakékoli další použití. Bude respektovat datum další aktualizace a datum publikování dalšího seznamu CRL (používané certifikačními autoritami Windows Serveru) v dokumentu seznamu CRL (pokud je k dispozici).
  3. Ověřování pomocí uživatelských certifikátů selže v následujících případech:
    • Pro důvěryhodného vystavitele se nakonfiguroval CRL a Azure AD ho kvůli omezením dostupnosti, velikosti nebo latence nemůže stáhnout.

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

      Snímek obrazovky s odvolaný certifikát uživatele v seznamu CRL

    • Azure AD se pokusí stáhnout nový CRL z distribučního bodu, pokud vypršela platnost dokumentu CRL uloženého v mezipaměti.

Poznámka

Azure AD zkontroluje CRL vydávající certifikační autority a dalších certifikačních autorit v řetězu vztahů důvěryhodnosti infrastruktury veřejných klíčů až po kořenovou certifikační autoritu. Pro ověření seznamu CRL v řetězu PKI máme limit až 5 certifikačních autorit z listového klientského certifikátu. Omezení spočívá v tom, aby se zajistilo, že chybný aktér službu neodloží tím, že nahraje řetězec infrastruktury veřejných klíčů s velkým počtem certifikačních autorit s větší velikostí seznamu CRL. Pokud má řetězec infrastruktury veřejných klíčů tenanta více než 5 certifikačních autorit a v případě ohrožení zabezpečení certifikační autority by správce měl z konfigurace tenanta Azure AD odebrat napadeného důvěryhodného vystavitele.

Důležité

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

V současné chvíli správce nemůže stahování seznamu CRL ručně vynutit ani znovu aktivovat.

Postup konfigurace odvolání

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

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

Chcete-li zajistit, aby odvolání přetrvávalo, je nutné nastavit datum účinnosti seznamu CRL na datum za hodnotou nastavenou hodnotou StsRefreshTokenValidFrom 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 StsRefreshTokenValidFrom .

  1. Připojte se pomocí přihlašovacích údajů správce ke službě MSOL:

            $msolcred = get-credential
             connect-msolservice -credential $msolcred
    
  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 budoucnosti. Pokud datum není v budoucnosti, StsRefreshTokensValidFrom vlastnost není nastavena. Pokud je datum v budoucnosti, StsRefreshTokensValidFrom je nastaven na aktuální čas (nikoli datum určené příkazem Set-MsolUser).

Principy protokolů přihlašování

Protokoly přihlašování poskytují informace o přihlášeních a o tom, jak uživatelé používají vaše prostředky. Další informace o protokolech přihlašování najdete v tématu Protokoly přihlašování v Azure Active Directory.

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

V testovacích scénářích vyberte uživatele se zásadami podmíněného přístupu, které vyžadují vícefaktorové ověřování. Nakonfigurujte zásady uživatelských vazeb namapováním hlavního názvu sítě SAN na UserPrincipalName.

Uživatelský certifikát by měl být nakonfigurovaný takto:

Snímek obrazovky s uživatelským certifikátem

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í.

Snímek obrazovky s konfigurací zásad ověřování zobrazující požadované jednofaktorové ověřování

  1. Přihlaste se k webu Azure Portal jako testovací uživatel pomocí CBA. Zásady ověřování se nastaví tam, kde pravidlo subjektu vystavitele splňuje jednofaktorové ověřování.

  2. Po úspěšném přihlášení klikněte naProtokoly přihlášeník Azure Active Directory>.

    Podívejme se blíže na některé položky, které najdete v protokolech přihlášení.

    První položka si od uživatele vyžádá certifikát X.509. Stav Přerušeno znamená, že Služba Azure AD ověřila, že je v tenantovi povolený CBA a že se pro ověření požaduje certifikát.

    Snímek obrazovky s položkou jednofaktorového ověřování v protokolech přihlašování

    Podrobnosti o aktivitě ukazují, že se jedná pouze o část očekávaného toku přihlášení, kdy uživatel vybere certifikát.

    Snímek obrazovky s podrobnostmi o aktivitě v protokolech přihlašování

    V části Další podrobnosti se zobrazí informace o certifikátu.

    Snímek obrazovky s vícefaktorovým dalšími podrobnostmi v protokolech přihlašování

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

    Snímek obrazovky s položkou obnovovacího tokenu v protokolech přihlášení

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í.

Snímek obrazovky s konfigurací zásad ověřování zobrazující požadované vícefaktorové ověřování

  1. Přihlaste se k webu Azure Portal pomocí CBA. Vzhledem k tomu, že zásady byly nastaveny tak, aby splňovaly vícefaktorové ověřování, přihlášení uživatele proběhne úspěšně bez druhého faktoru.

  2. Klikněte naPřihlášeník Azure Active Directory>.

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

    Snímek obrazovky s několika položkami v protokolech přihlášení

    Podrobnosti o aktivitě ukazují, že se jedná pouze o část očekávaného toku přihlášení, kdy uživatel vybere certifikát.

    Snímek obrazovky s podrobnostmi o přihlášení druhého faktoru v protokolech přihlášení

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

    Snímek obrazovky s podrobnostmi o přerušení pokusu v protokolech přihlášení

    Následující tabulka obsahuje popis jednotlivých polí.

    Pole Description
    Název subjektu certifikátu uživatele Odkazuje na pole názvu subjektu v certifikátu.
    Vazba certifikátu uživatele Certifikát: Hlavní název; Atribut uživatele: userPrincipalName; Pořadí: 1
    Zobrazí se pole certifikátu SAN PrincipalName namapované na atribut uživatele userPrincipalName s prioritou 1.
    Úroveň ověřování uživatelským certifikátem multiFactorAuthentication
    Typ úrovně ověřování uživatelským certifikátem PolicyId
    To ukazuje, že identifikátor zásady byl použit k určení síly ověřování.
    Identifikátor úrovně ověřování uživatelským certifikátem 1.2.3.4
    Zobrazí se hodnota identifikátoru OID zásad identifikátoru z certifikátu.

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

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

Snímek obrazovky s chybou ověření certifikátu

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, abyste CBA zkusili znovu. Vyžaduje se nová relace, protože prohlížeče certifikát ukládají do mezipaměti. Při opakovaném pokusu o CBA prohlížeč odešle certifikát uložený v mezipaměti během výzvy TLS, což způsobí selhání přihlášení a chybu ověření.

Kliknutím na Další podrobnosti získáte informace o protokolování, které je možné odeslat správci, který pak může získat další informace z protokolů přihlášení.

Snímek obrazovky s podrobnostmi o chybě

Klikněte na Jiné způsoby přihlášení a vyzkoušejte další metody, které jsou uživateli k dispozici pro přihlášení.

Poznámka

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

Snímek obrazovky s novým pokusem o přihlášení

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

Po úspěšném ověření uživatele pomocí CBA se metoda ověřování MostRecentlyUsed (MRU) uživatele nastaví na CBA. Když příště uživatel zadá hlavní název uživatele (UPN) a klikne na Další, přejde přímo do metody CBA a nebude muset vybrat možnost Použít certifikát nebo čipovou kartu.

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

Podpora externích identit

Externí identita nemůže v tenantovi prostředků provádět vícefaktorové ověřování (MFA) pomocí Azure AD CBA. Místo toho požádejte uživatele, aby provedl vícefaktorové ověřování pomocí CBA v domovském tenantovi a nastavil pro tenanta prostředků nastavení mezi tenanty tak, aby důvěřoval vícefaktorovému ověřování z domovského tenanta.

Další informace o tom, jak povolit vícefaktorové ověřování důvěryhodnosti z tenantů Azure AD, najdete v tématu Konfigurace přístupu ke spolupráci B2B mezi tenanty.

Známé problémy

  • V klientech iOS je v rámci toku Azure AD CBA problém s dvojitou výzvou, kdy uživatel musí dvakrát kliknout na Použít certifikát nebo čipovou kartu . O tomto problému s uživatelským prostředím víme a pracujeme na jeho řešení, abychom mohli uživatelské prostředí bezproblémově vyřešit.

Další kroky