Sdílet prostřednictvím

Konfigurace podpory služby AD FS pro ověřování uživatelských certifikátů

Tento článek popisuje, jak povolit ověřování uživatelských certifikátů ve službě Active Directory Federation Services (AD FS). Poskytuje také informace o řešení běžných problémů s tímto typem ověřování.

Existují dva hlavní případy použití ověřování uživatelských certifikátů:

  • Uživatelé používají čipové karty k přihlášení do systému AD FS.
  • Uživatelé používají certifikáty zřízené pro mobilní zařízení.

Prerequisites

  • Pomocí jednoho z režimů popsaných v podpoře služby AD FS pro alternativní vazbu názvu hostitele pro ověřování certifikátů určete režim ověřování uživatelských certifikátů služby AD FS, který chcete povolit.
  • Ujistěte se, že je řetězec důvěry uživatelského certifikátu nainstalovaný a důvěryhodný na všech serverech AD FS a Web Application Proxy (WAP), včetně všech zprostředkujících certifikačních autorit. Obvykle to uděláte prostřednictvím objektu zásad skupiny (GPO) na serverech AD FS a WAP.
  • Ujistěte se, že kořenový certifikát řetězu důvěryhodnosti pro vaše uživatelské certifikáty je v úložišti NTAuth ve službě Active Directory.
  • Pokud používáte službu AD FS v alternativním režimu ověřování certifikátů, ujistěte se, že vaše servery AD FS a WAP mají certifikáty SSL (Secure Sockets Layer), které obsahují název hostitele služby AD FS s předponou "certauth". Příkladem je certauth.fs.contoso.com. Také se ujistěte, že provoz do tohoto hostitelského jména je povolený bránou firewall.
  • Pokud používáte ověřování pomocí certifikátu z extranetu, ujistěte se, že v seznamu uvedeném v certifikátech je z internetu přístupný alespoň jeden bod pro přístup k informacím o autoritě (AIA) a alespoň jeden distribuční bod seznamu CRL (CDP) nebo Online Certificate Status Protocol (OCSP).
  • Pokud konfigurujete službu AD FS pro ověřování certifikátů Microsoft Entra, ujistěte se, že jste nakonfigurovali nastavení Microsoft Entra a pravidla deklarací identity služby AD FS požadovaná pro vystavitele certifikátu a sériové číslo.
  • Pokud pro klienty Exchange ActiveSync používáte ověřování pomocí certifikátu Microsoft Entra, musí mít klientský certifikát směrovatelnou e-mailovou adresu uživatele v Exchangi Online v hodnotě hlavního názvu nebo v poli Alternativnínázev subjektu . Microsoft Entra ID mapuje hodnotu RFC822 na atribut adresy proxy v adresáři.

Note

AD FS nepodporuje náznaky uživatelského jména při ověřování čipovou kartou nebo certifikátem.

Povolení ověřování uživatelských certifikátů

Povolte ověřování uživatelským certifikátem jako metodu ověřování na intranetu nebo extranetu v AD FS pomocí konzoly pro správu AD FS nebo příkazu PowerShellu Set-AdfsGlobalAuthenticationPolicy.

Mezi volitelné aspekty patří:

  • Pokud chcete používat deklarace identity založené na polích certifikátu a rozšířeních kromě typu deklarace identity EKU, https://schemas.microsoft.com/2012/12/certificatecontext/extension/ekunakonfigurujte další pravidla předávání deklarací identity pro vztah důvěryhodnosti zprostředkovatele deklarací služby Active Directory. Úplný seznam dostupných nároků na certifikát najdete dále v tomto článku.

  • Pokud potřebujete omezit přístup na základě typu certifikátu, můžete pro aplikaci použít další vlastnosti certifikátu v autorizačních pravidlech vystavování služby AD FS. Mezi běžné scénáře patří povolení jenom certifikátů zřízených poskytovatelem správy mobilních zařízení (MDM) nebo povolení pouze certifikátů čipových karet.

    Important

    Zákazníci, kteří používají tok kódu zařízení pro ověřování a k ověřování zařízení využívají jiného poskytovatele identity než Microsoft Entra ID (například AD FS), nemohou vynutit přístup k prostředkům Microsoft Entra založený na zařízení. Nemůžou například povolit jenom spravovaná zařízení pomocí služby MDM třetí strany.

    Chcete-li chránit přístup k podnikovým prostředkům v MICROSOFT Entra ID a zabránit úniku dat, nakonfigurujte podmíněný přístup založený na zařízeních společnosti Microsoft Entra. Pokud chcete například udělit kontrolu v rámci podmíněného přístupu Microsoft Entra, použijte možnost Vyžadovat, aby zařízení bylo označeno jako stížnost .

    Nakonfigurujte povolené vydávající certifikační autority pro klientské certifikáty pomocí pokynů v části Správa důvěryhodných vystavitelů pro ověřování klientů v technickém přehledu zprostředkovatele zabezpečení Schannel.

  • Zvažte úpravu přihlašovacích stránek tak, aby vyhovovaly potřebám uživatelů při ověřování certifikátů. Běžným případem je změna přihlášení pomocí certifikátu X509 na něco uživatelsky přívětivějšího.

Konfigurace bezproblémového ověřování certifikátů pro prohlížeč Chrome na počítačích s Windows

Pokud má počítač více uživatelských certifikátů (například Wi-Fi certifikátů), které vyhovují účelům ověřování klientů, prohlížeč Chrome na počítačích s Windows vyzve uživatele, aby vybrali správný certifikát. Tato výzva může být pro uživatele matoucí. Pokud chcete toto prostředí optimalizovat, můžete pro Chrome nastavit zásady, které automaticky vyberou správný certifikát.

Tuto zásadu můžete nastavit ručně provedením změny registru, nebo ji můžete nakonfigurovat automaticky pomocí GPO (pro nastavení klíčů registru). To vyžaduje, aby vaše uživatelské klientské certifikáty pro ověřování ve službě AD FS měly odlišné vystavitele z jiných případů použití.

Další informace o konfiguraci ověřování certifikátů pro Chrome najdete v seznamu zásad Chrome Enterprise.

Řešení potíží s ověřováním certifikátů

Při řešení běžných problémů při konfiguraci služby AD FS pro ověřování certifikátů pro uživatele použijte následující informace.

Zkontrolujte, jestli jsou důvěryhodní vystavitelé certifikátů správně nakonfigurovaní na všech serverech AD FS a WAP.

Pokud nejsou důvěryhodní vystaviteé certifikátu správně nakonfigurovaní, běžným příznakem je chyba HTTP 204: "Žádný obsah z https://certauth.adfs.contoso.com."

Služba AD FS používá základní operační systém Windows k prokázání vlastnictví uživatelského certifikátu a zajištění, že odpovídá důvěryhodnému vystaviteli ověřením řetězu důvěryhodnosti certifikátů. Abyste splnili požadavky důvěryhodného vystavitele, musíte zajistit, aby byly všechny kořenové a zprostředkující autority nakonfigurované jako důvěryhodní vystavitelé v místním úložišti pro certifikátové autority počítače.

K automatickému ověření použijte nástroj Analyzátor diagnostiky služby AD FS. Nástroj se dotazuje na všechny servery a zajišťuje správné zřizování správných certifikátů.

  1. Stáhněte a spusťte nástroj.
  2. Nahrajte výsledky a zkontrolujte případné chyby.

Kontrola, jestli je v zásadách ověřování AD FS povolené ověřování certifikátu

Služba AD FS ve výchozím nastavení provádí ověřování uživatelských certifikátů na portu 49443 se stejným názvem hostitele jako služba AD FS (například: adfs.contoso.com). Službu AD FS můžete také nakonfigurovat tak, aby používala port 443 (výchozí port HTTPS) pomocí alternativní vazby SSL. Adresa URL použitá v této konfiguraci je certauth.<adfs-farm-name> (například: certauth.contoso.com). Další informace najdete v tématu Podpora alternativní vazby názvu hostitele pro ověřování certifikátů ve službě AD FS.

Note

Ve službě AD FS ve Windows Serveru 2016 se teď podporují dva režimy. První režim používá hostitele adfs.contoso.com s porty 443 a 49443. Druhý režim používá hostitele adfs.contoso.com a certauth.adfs.contoso.com s portem 443. K podpoře certauth.\<adfs-service-name> jako alternativního názvu subjektu potřebujete certifikát SSL. Můžete to udělat v době vytvoření farmy nebo později prostřednictvím PowerShellu.

Nejběžnějším případem problémů s připojením k síti je, že brána firewall je nesprávně nakonfigurovaná a blokuje provoz pro ověřování uživatelských certifikátů. Obvykle se při výskytu tohoto problému zobrazí prázdná obrazovka nebo chyba serveru 500. Aby bylo možné to opravit:

  1. Poznamenejte si název hostitele a port, který jste nakonfigurovali ve službě AD FS.
  2. Ujistěte se, že je každá brána firewall před službou AD FS nebo WAP nakonfigurovaná tak, aby umožňovala hostname:port kombinaci pro vaši farmu AD FS. Tento krok musí provést váš síťový inženýr.

Kontrola připojení ke CRL

Seznamy odvolaných certifikátů (CRL) jsou koncové body, které jsou kódovány do uživatelského certifikátu pro provádění kontrol odvolání za běhu. Pokud je například odcizeno zařízení, které obsahuje certifikát, může správce přidat certifikát do seznamu odvolaných certifikátů. Ověření se nyní nezdaří u každého koncového bodu, který dříve přijal tento certifikát.

Každý server AD FS a WAP musí oslovit koncový bod seznamu CRL, aby ověřil, jestli je certifikát, který mu byl předložen, stále platný a nebyl zrušen. Ověření seznamu CRL může probíhat přes protokoly HTTPS, HTTP, LDAP nebo OCSP. Pokud se servery AD FS a WAP nedostanou ke koncovému bodu, ověřování se nezdaří. Při řešení potíží použijte následující postup:

  1. S pracovníkem infrastruktury veřejných klíčů (PKI) zjistěte, které koncové body seznamu CRL se používají k odvolání uživatelských certifikátů ze systému PKI.
  2. Na každém serveru AD FS a WAP se ujistěte, že koncové body seznamu CRL jsou dostupné přes použitý protokol (obvykle HTTPS nebo HTTP).
  3. Pro pokročilé ověřování povolte protokolování událostí CAPI2 na každém serveru AD FS a WAP.
  4. V provozních protokolech CAPI2 zkontrolujte ID události 41 (ověřit odvolání).
  5. Zkontrolujte <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Tip

Pro snadnější řešení potíží můžete cílit na jeden server AD FS nebo WAP tak, že nakonfigurujete DNS záznam (soubor hosts ve Windows) tak, aby odkazoval na konkrétní server. Tato technika umožňuje povolit trasování cílením na server.

Kontrola problémů se SNI

Služba AD FS vyžaduje, aby klientská zařízení (nebo prohlížeče) a nástroje pro vyrovnávání zatížení podporovaly indikaci názvu serveru (SNI). Některá klientská zařízení (například starší verze Androidu) nemusí podporovat SNI. Nástroje pro vyrovnávání zatížení navíc nemusí podporovat SNI nebo nemusí být nakonfigurované pro SNI. V těchto případech pravděpodobně dojde k selhání certifikace uživatelů.

Pokud chcete tento problém vyřešit, obraťte se na síťového inženýra a ujistěte se, že nástroj pro vyrovnávání zatížení pro službu AD FS a WAP podporuje SNI. Pokud SNI nejde podporovat, použijte ve službě AD FS následující alternativní řešení:

  1. Na primárním serveru SLUŽBY AD FS otevřete okno příkazového řádku se zvýšenými oprávněními.
  2. Zadejte Netsh http show sslcert.
  3. Zkopírujte identifikátor GUID aplikace a hodnotu hash certifikátu federační služby.
  4. Zadejte netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}.

Zkontrolujte, jestli je klientské zařízení správně zřízené pomocí certifikátu.

Můžete si všimnout, že některá zařízení fungují správně, ale jiná zařízení ne. Ve většině případů to znamená, že uživatelský certifikát nebyl na některých klientských zařízeních správně zřízený. Postupujte takto:

  1. Pokud je problém specifický pro zařízení s Androidem, nejběžnější příčinou je, že řetěz certifikátů není na zařízení plně důvěryhodný. Obraťte se na dodavatele MDM a ujistěte se, že je certifikát správně zřízený a celý řetěz je na zařízení s Androidem plně důvěryhodný.

    Pokud je problém specifický pro zařízení s Windows, zkontrolujte, jestli je certifikát správně zřízený, kontrolou úložiště certifikátů systému Windows pro přihlášeného uživatele (ne systému nebo počítače).

  2. Exportujte klientský uživatelský certifikát do souboru .cer a spusťte příkaz certutil -f -urlfetch -verify certificatefilename.cer.

Zkontrolujte, jestli je verze protokolu TLS kompatibilní mezi servery AD FS nebo WAP a klientským zařízením.

Ve výjimečných případech se klientské zařízení aktualizuje tak, aby podporovalo pouze vyšší verzi protokolu TLS (například 1.3). Nebo může dojít k opačnému problému, kdy se servery AD FS a WAP aktualizovaly tak, aby používaly pouze vyšší verzi protokolu TLS, kterou klientské zařízení nepodporuje.

Pomocí online nástrojů SSL můžete zkontrolovat servery AD FS a WAP a zjistit, jestli jsou kompatibilní se zařízením. Další informace o tom, jak řídit verze protokolu TLS, naleznete v tématu Správa protokolů SSL/TLS a šifrovacích sad pro SLUŽBU AD FS.

Zkontrolujte, jestli je v nastavení federované domény správně nakonfigurovaný Microsoft Entra PromptLoginBehavior.

Mnoho aplikací Office 365 odesílá prompt=login do Microsoft Entra ID. Microsoft Entra ID ve výchozím nastavení převede to na nové přihlášení heslem pro AD FS. V důsledku toho se uživatelům zobrazí jenom přihlášení pomocí hesla, i když jste v AD FS nakonfigurovali ověřování certifikátů. Tento problém vyřešíte takto:

  1. Pomocí rutiny Get-MgDomainFederationConfiguration získejte nastavení federované domény.
  2. Ujistěte se, že parametr PromptLoginBehavior je nastaven buď na Disabled, nebo na NativeSupport.

Další informace naleznete v tématu AD FS podpora parametru prompt=login.

Další řešení potíží

Ve výjimečných případech může při pokusu o stažení dojít k vypršení časového limitu, pokud jsou seznamy CRL velmi dlouhé. V tomto případě musíte aktualizovat MaxFieldLength a MaxRequestByte jak je popsáno v nastavení registruHttp.sys pro Windows.

Referenční informace: Úplný seznam typů deklarací identity uživatelských certifikátů a ukázkových hodnot

Typ deklarace identity Příklad hodnoty
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4
  • Last updated on