Windows Hello for Business (WHfB) se stal klíčovou součástí strategie firemní identity společnosti Microsoft: sbohem tradičním heslům a vítejte v modelu ověřování založeném na kryptografických klíčích, biometrii, PINech a důvěryhodných zařízeních. V kombinaci s Microsoft Entra ID a jednotným přihlašováním (SSO) umožňuje uživatelům přístup ke cloudovým a místním zdrojům jediným gestem a zároveň zachovává bezpečnostní kontroly na podnikové úrovni.
V tomto článku si klidně, ale jasně rozebereme, jak funguje ověřování Windows Hello pro firmy, když se jedná o hardwarové klíče, zařízení s podporou TPM a scénáře SSO, ve srovnání s Microsoft Entra ID a Active Directory. Podíváme se na interní fáze (registrace zařízení, zřizování, synchronizace klíčů, certifikáty a ověřování), roli PRT v SSO, jak se integruje s Kerberos v hybridních prostředích a jaké jsou požadavky na infrastrukturu potřebné pro hladký chod všeho.
Obecná architektura Windows Hello pro firmy a jeho model bez hesla
Windows Hello pro firmy není jen o zadávání PINu nebo přihlašování ; je to distribuovaný systém, který kombinuje identitu uživatele, identitu zařízení a hardwarově chráněné kryptografické klíče. Ověřování se opírá o pár veřejného/soukromého klíče nebo certifikáty, které jsou vázány na zařízení (TPM) a odemykatelné něčím, co uživatel zná (PIN) nebo něčím, čím je (biometrické údaje).
Klíčový rozdíl oproti tradičním heslům spočívá v tom, že již neexistuje „sdílený tajný klíč“, který by se přenášel po síti nebo byl centrálně uložen: server (Microsoft Entra ID nebo Active Directory) ukládá pouze veřejnou část klíče, zatímco soukromá část nikdy neopouští zařízení. Když se uživatel chce ověřit, systém Windows podepíše výzvu (nonce) soukromým klíčem a poskytovatel identity tento podpis ověří registrovaným veřejným klíčem.
Díky tomuto přístupu je WHfB odolný vůči phishingu : i kdyby útočník uživatele oklamal k zadání uživatelského jména na škodlivém webu, nemohl by replikovat ověření bez soukromého klíče propojeného s TPM počítače. Výsledkem je systém dvoufaktorového ověřování (klíč + PIN/biometrie), který splňuje přísná kritéria MFA, ale zároveň nabízí mnohem plynulejší uživatelský zážitek a zabezpečení systému Windows 11.
WHfB se nativně integruje s Microsoft Entra ID a Active Directory , což umožňuje různé modely nasazení: pouze cloudové, hybridní nebo plně lokální. Navíc může koexistovat s čipovými kartami a klíči FIDO2 a dokonce znovu použít stávající PKI organizace, pokud se rozhodne pro modely založené na certifikátech.
Fáze provozu Windows Hello pro firmy
Abychom plně pochopili, co se děje „pod kapotou “, nejpraktičtějším přístupem je rozdělit životní cyklus Windows Hello pro firmy do několika vzájemně propojených fází: registrace zařízení, zřizování, synchronizace klíčů (v hybridním režimu), zápis certifikátu (pokud se používá) a nakonec ověřování a jednotné přihlašování (SSO).
1. Registrace zařízení
Než lze uživateli vydat přihlašovací údaje WHfB, musí mít zařízení vlastní identitu . Tento proces se nazývá registrace zařízení a přiřazuje zařízení k poskytovateli identity (IdP) organizace.
V závislosti na typu nasazení se IdP a registrační služba mění :
- Cloudové nebo hybridní implementace: IdP je Microsoft Enter ID. Zařízení se zaregistruje u Služba registrace zařízení Entra ID a stává se „zařízením připojeným k Microsoft Entra“ nebo „hybridním zařízením připojeným k Microsoft Entra“.
- Čistě lokální implementace: Poskytovatel identity (IdP) je AD FS a zařízení je registrováno v služba registrace podnikových zařízení který zpřístupňuje AD FS.
V důsledku registrace udělí IdP zařízení vlastní identitu , která bude použita při následných výměnách ověřování uživatelů a získávání tokenů. Existují různé „typy připojení“ nebo stavy připojení (pouze přihlášení, hybridní, klasické připojení k doméně + registrované atd.), které určují, jak se zařízení chová ve smíšených prostředích.
2. Zřizování Windows Hello pro firmy
Fáze zřizování nastává, když se na zařízení skutečně vytvoří přihlašovací údaje Hello pro konkrétního uživatele . Zde vstupuje do hry klíčový koncept: kontejner Windows Hello , což je logická struktura, kde je uložen veškerý „klíčový materiál“ spojený s identitou uživatele na daném zařízení.
Typický proces zadávání veřejných zakázek zahrnuje několik propojených kroků :
- Uživatel se přihlásí pomocí svých tradičních přihlašovacích údajů (obvykle uživatelského jména a hesla) a systém spustí nastavení WHfB, přičemž od poskytovatele identity (Microsoft Entra ID nebo AD FS) vyžádá vícefaktorové ověřování.
- Po úspěšném dokončení magisterského studia výtvarných umění, Uživatel je požádán o definování PINu a, pokud to hardware umožňuje, o registraci biometrických údajů. (otisk nohy, obličej, duhovka).
- Jakmile je PIN kód potvrzen, systém Windows v zařízení vytvoří kontejner Windows Hello.
- Vytváří a pár veřejného a soukromého ověřovacího klíče, propojen s TPM (pokud existuje) nebo, pokud to není možné, chráněn softwarově.
- Soukromý klíč je uložen lokálně a je zapečetěn k TPM, nelze jej exportovat.
- Veřejný klíč je registrován v IdP a propojen s uživatelským účtem:
- V cloudových nebo hybridních scénářích služba registrace zařízení zapíše data do objektu uživatele Microsoft Entra ID.
- V lokálních scénářích s AD FS je uložen v Active Directory.
V rámci kontejneru si každý „ochranný prvek“ (PIN, biometrické gesto atd.) uchovává svou vlastní šifrovanou kopii ověřovacího klíče . Pokud je přítomen TPM, PIN se používá jako entropie při operaci pečetění; v opačném případě se k zašifrování materiálu odvodí symetrický klíč. To umožňuje uživateli odemknout stejný pár klíčů různými gesty, aniž by bylo ohroženo zabezpečení.
Kromě primárního ověřovacího klíče může kontejner obsahovat další prvky , jako například administrativní klíč pro scénáře resetování PINu, objekty blob s certifikáty TPM a především různé typy klíčů identifikátoru uživatele používaných pro specifické protokoly (WebAuthn/FIDO2, Entra ID, uživatelské certifikáty pro VPN nebo RDP atd.).
Podrobnosti o ověřovacích klíčích a identifikátoru uživatele
Ověřovací klíč Windows Hello je vždy asymetrický (veřejný/soukromý) pár klíčů generovaný během registrace. Pokaždé, když je potřeba jej použít, je nutné jej odemknout pomocí PIN kódu nebo biometrických údajů. Pokud uživatel resetuje svůj PIN kód, vygeneruje se nový pár ověřovacích klíčů a všechna data chráněná předchozím párem jsou znovu zašifrována.
Klíče identifikátoru uživatele mohou být symetrické nebo asymetrické v závislosti na poskytovateli identity a scénáři. V moderních podnikových prostředích (Microsoft Entra ID, Active Directory, osobní účty Microsoft) se obvykle jedná o asymetrické páry klíčů, generované a uložené v zařízení, přičemž veřejná část je registrována u poskytovatele identity.
V organizacích existují dva hlavní způsoby generování klíčů identifikátorů uživatelů :
- Spojte je s Firemní PKItakže klíč je propojen s certifikátem vydaným certifikační autoritou společnosti. To usnadňuje přechod z infrastruktur založených na certifikátech (VPN, RDP s uživatelskými certifikáty atd.) na WHfB.
- Nechte to být přímo IdP (Entra ID nebo AD FS) – ten, který spravuje pár klíčů spojené s identitou, čímž se snižuje složitost PKI, když to není nezbytné.
Tyto klíče se používají k prokázání vlastnictví podepisováním jednorázových čísel nebo ověřovacích tokenů, a to jak pro řadiče domény (Kerberos), tak pro webové služby, které používají WebAuthn (FIDO2). Jedno zařízení může hostovat více přihlašovacích údajů FIDO přidružených k různým webovým stránkám nebo aplikacím, všechny spravované v kontejneru Windows Hello.
Lokální ukládání biometrických údajů
Jedním z bodů, který často znepokojuje mnoho uživatelů a auditorů, je to, co se děje s jejich biometrickými údaji . Ve Windows Hello pro firmy jsou biometrické šablony uloženy pouze v zařízení , v lokální databázi, ke které Microsoft nemá přístup ani ji nesynchronizuje s cloudem.
Každý biometrický senzor si uchovává vlastní databázi šablon (například v C:\WINDOWS\System32\WinBioDatabase), šifrované unikátním náhodným klíčem pro každou databázi, chráněné algoritmem AES v režimu CBC a hashováním SHA-256. I kdyby se útočníkovi podařilo tuto databázi získat, nebyl by schopen rekonstruovat „surové“ snímky obličeje nebo otisku prstu; jedná se o nevratná šablonová data.
3. Synchronizace klíčů v hybridních prostředích
V hybridních nasazeních musí veřejný klíč registrovaný v Microsoft Entra ID dosáhnout také služby Active Directory , aby se uživatel mohl ověřit bez hesla jak u cloudových služeb, tak u místních zdrojů.
Tento proces spravuje společnost Microsoft. Zadejte Connect Sync., který synchronizuje veřejný klíč uživatele z atributu Enter ID do atributu msDS-KeyCredentialLink objektu uživatele v Active Directory. Tímto způsobem mohou řadiče domény ověřovat ověřování na základě klíčů (scénář důvěryhodnosti klíčů) nebo používat související informace pro cloudové modely důvěryhodnosti Kerberos.
4. Registrace certifikátu (při použití modelu založeného na certifikátech)
Pokud vaše organizace již má nasazenou PKI a chce ji využít s WHfB , můžete zvolit model důvěryhodnosti založený na certifikátech. V tomto případě klient po registraci klíče u IdP vygeneruje žádost o certifikát a odešle ji certifikační autoritě (CRA), která je obvykle hostována na serveru AD FS.
CRA ověří požadavek a směruje jej k podnikové certifikační autoritě , která vydá uživatelský certifikát. Tento certifikát je uložen v kontejneru Windows Hello a bude použit k ověřování u lokálních zdrojů, které vyžadují klientské certifikáty (například ověřování Kerberos s certifikáty nebo IPsec VPN).
5. Fáze ověřování: jak je klíč „uvolněn“
Jakmile jsou počáteční fáze nastavení dokončeny, je každodenní zážitek uživatele velmi jednoduchý : k přihlášení nebo odemčení zařízení použije svůj PIN nebo biometrické údaje. Technicky vzato tato akce „odemkne“ přístup k soukromé části přihlašovacích údajů WHfB uložených v TPM.
Ani PIN, ani soukromý klíč neopouští zařízení ani nejsou odeslány poskytovateli identity (IdP) . PIN funguje jako entropie pro operace podepisování se soukromým klíčem; jinými slovy, jedná se o lokální spouštěč, který autorizuje použití klíče. Když se aplikace nebo samotný systém potřebuje ověřit pomocí IdP, systém Windows podepíše blok dat soukromým klíčem a odešle podpis na server, který ověří jeho platnost oproti registrovanému veřejnému klíči.
Tento vzorec se opakuje jak pro přímé ověřování proti Entra ID (pomocí webových protokolů a poskytovatele cloudového přístupového bodu) , tak pro ověřování Kerberos proti Active Directory (buď pomocí klíče, certifikátu, nebo důvěryhodnosti Kerberos v cloudu).
Primární obnovovací token (PRT) a jednotné přihlašování (SSO)
Moderní SSO v prostředích Microsoftu se točí kolem Master Refresh Tokenu neboli PRT . Zatímco v klasickém Kerberosu je „master tokenem“ TGT, ve scénářích Entra ID je PRT token JWT, který obsahuje informace o uživateli a zařízení, což umožňuje získání přístupových tokenů pro různé aplikace, aniž by se uživatel musel explicitně znovu ověřit.
PRT se obvykle vydává během přihlášení nebo odemčení zařízení , když se uživatel ověřuje pomocí WHfB na počítači připojeném k platformě Microsoft Entra nebo hybridnímu počítači připojeném k platformě Entra. Na registrovaných osobních zařízeních se PRT získá přidáním pracovního nebo školního účtu do systému Windows.
Bez PRT neexistuje skutečné SSO k aplikacím chráněným Entra ID nebo AD FS . Pokud zařízení z jakéhokoli důvodu nemá platný PRT, uživatelé uvidí opakované výzvy k zadání přihlašovacích údajů a zásady podmíněného přístupu, které vyžadují informace o zařízení (například „pouze zařízení označená jako kompatibilní“), selžou.
Ve scénářích vzdáleného přístupu s využitím VPN a SAML SSO , když se uživatel již v operačním systému ověřil pomocí WHfB, PRT umožňuje společnosti Entra ID „zapamatovat si“, že vícefaktorová autentizace odolná proti phishingu již byla splněna. Během přihlašování k VPN přes SAML proto může společnost Entra ID označit relaci jako kompatibilní s vícefaktorovou autentizací, aniž by vyžadovala další druhý faktor, což často vyvolává debaty s pojišťovnami a auditory.
Proces ověřování zařízení připojeného k Microsoftu: Zadejte ID pomocí klávesy Enter.
Na zařízení připojeném k Entra je řetězec událostí během přihlášení k WHfB zjednodušeně následující:
- Uživatel zavře zamykací obrazovku a zadá svůj PIN nebo biometrické údaje do poskytovatele přihlašovacích údajů WHfB.
- Winlogon předává tyto přihlašovací údaje službě LSASS, která je následně doručí poskytovateli zabezpečení cloudového ověřování (Cloud AP).
- Cloudový přístupový bod vyžaduje nuncius Microsoft Enter ID; Enter ID odpoví touto hodnotou.
- Klient podepíše nonce soukromým klíčem uživatele a výsledek odešle společnosti Entra ID.
- Entra ID ověří podpis s dříve registrovaným veřejným klíčem a pokud je vše v pořádku, vygeneruje PRT, zašifrovaný transportním klíčem zařízení.
- Cloudový přístupový bod dešifruje klíč relace PRT pomocí soukromého transportního klíče (chráněného modulem TPM) a ukládá PRT do chráněné mezipaměti.
- LSASS informuje Winlogon, že ověření proběhlo úspěšně a je vytvořena uživatelská relace.
Od tohoto okamžiku bude PRT sloužit k získávání přístupových a aktualizačních tokenů pro různé aplikace (Microsoft 365, SaaS třetích stran, aplikace SAML atd.), aniž by uživatel musel cokoli znovu zadávat, vždy v souladu s nakonfigurovanými zásadami podmíněného přístupu.
Ověřování ve Windows Hello pro firmy vs. Active Directory
Pokud je zařízení pouze „připojeno k Entra“, ale potřebuje přístup k lokálním zdrojům , vstupuje do hry integrace s Active Directory prostřednictvím různých modelů: důvěryhodnost Kerberos v cloudu, důvěryhodnost klíčů a důvěryhodnost certifikátů. Všechny tyto modely umožňují generování Kerberos tiketů s přihlašovacími údaji WHfB bez nutnosti zadávání hesel.
Důvěřujte Kerberosu v cloudu s Microsoftem. Začněte.
V modelu důvěryhodnosti cloudového protokolu Kerberos vydává Microsoft Entra ID částečný TGT přidružený k identitě uživatele a podepsaný cloudovou službou Kerberos. Když zařízení potřebuje plný TGT z místního řadiče domény, odešle tento částečný TGT do místního KDC, které jej ověří a vydá uživateli „skutečný“ TGT.
Tento přístup výrazně zjednodušuje infrastrukturu , protože deleguje část ověřovací logiky na Entra ID, ale vyžaduje, aby řadiče domény byly aktuální a správně nakonfigurované tak, aby rozpoznávaly a ověřovaly tyto částečné TGT přicházející z cloudu.
Model klíčové důvěryhodnosti
V modelu důvěryhodnosti klíčů řadič domény přímo ověřuje podpis vytvořený pomocí soukromého klíče uživatele registrovaného v Active Directory. Postup na vysoké úrovni je následující:
- Poskytovatel Kerberos na straně klienta podepisuje data předběžného ověřování soukromým klíčem a odesílá podpis spolu s veřejným klíčem (v certifikátu s vlastním podpisem) do KDC.
- KDC ověří, zda je certifikát podepsaný sám sebou, a vyhledá tento veřejný klíč v atributu
msDS-KeyCredentialLinkod uživatele a ověří podpis. - Pokud se vše shoduje (UPN, klíče, podpis), KDC vrátí klientovi TGT.
Dále klient ověří certifikát KDC (řetězec ke kořeni důvěryhodnosti, EKU pro ověřování KDC, alternativní název pro porovnávání domén, zabezpečené algoritmy, jako je SHA-256 a RSA 2048 atd.), než tento TGT přijme a uloží ho do mezipaměti pro budoucí požadavky na servisní lístky.
Důvěra certifikátu
V modelu založeném na certifikátech uživatel předloží KDC klientský certifikát vydaný certifikační autoritou organizace. Kerberos používá informace o certifikátu (DN subjektu nebo UPN v síti SAN) jako vodítko k nalezení účtu v Active Directory.
Řadič domény ověří řetězec certifikátů až po kořen důvěryhodnosti , zkontroluje, zda je certifikát v platnosti a zda nebyl odvolán, a pomocí veřejného klíče certifikátu ověří podepsaná data předběžného ověřování. Pokud je vše v pořádku, vydá certifikát TGT, který klient po ověření certifikátu KDC přijme.
Požadavky na infrastrukturu pro bezpečná hybridní prostředí
Úspěšné ověření zařízení připojeného k službě Microsoft Entra v Active Directory vyžaduje věnování velké pozornosti konfiguraci podnikové PKI, distribučním bodům CRL a důvěryhodnosti certifikátů řadiče domény.
Distribuční body seznamu odvolaných plateb (CDP/CRL)
Velmi častou chybou je ponechání CDP pouze v LDAP v rámci domény . Zařízení připojená k Entra ID, která nejsou součástí domény, nemohou před ověřením číst tuto cestu LDAP, což vytváří smyčku: pro ověření potřebují ověřit certifikát DC, ale bez ověření nemohou číst CRL.
Doporučeným řešením je publikovat CRL v místě přístupném přes HTTP bez ověřování , obvykle na interním webu, a přidat tuto URL adresu jako CDP do certifikátů certifikační autority a řadičů domény. Proces zahrnuje:
- Nakonfigurujte webový server (IIS) s virtuálním adresářem (například
cdp) a povolit procházení adresářů. - Upravte oprávnění NTFS a sdílení tak, aby certifikační autorita mohla automaticky publikovat soubory CRL do daného adresáře.
- Aktualizujte konfiguraci certifikační autority tak, aby zahrnovala novou adresu URL HTTP jako CDP a jako umístění publikování CRL a delta CRL.
- Znovu vydejte certifikáty řadiče domény tak, aby zahrnovaly nový HTTP CDP.
Po provedení těchto kroků mohou zařízení připojená k Entra ověřit certifikát řadiče domény bez nutnosti ověřování , čímž se eliminuje problém s cyklickým zacyklením a umožňuje se správné fungování ověřování na základě certifikátu nebo klíče.
Požadavky na certifikát řadiče domény
Aby systém Windows Hello pro firmy vynucoval „přísné ověření KDC“ při ověřování ze zařízení připojeného přes Entra, musí certifikáty řadiče domény splňovat několik kritérií:
- Vydávající kořenová certifikační autorita musí být ve skladu důvěryhodné kořenové certifikační autority zařízení.
- Certifikát musí být založen na Šablona ověřování Kerberos odpovídající
- Musí obsahovat EKU Ověřování KDC.
- Alternativní název subjektu (SAN) musí obsahovat název DNS, který odpovídá doméně.
- Algoritmus podpisu musí být SHA-256 a veřejný klíč musí být RSA s délkou alespoň 2048 bitů.
Pokud se některý z těchto kroků nezdaří, zařízení připojená k Entra mohou certifikát řadiče domény odmítnout a ověřování WHfB do služby Active Directory nebude fungovat, i když se zdá, že s klasickými hesly vše funguje dobře.
Distribuce kořenového certifikátu certifikační autority na zařízeních připojených k Entra
Aby byly certifikáty řadiče domény důvěryhodné , musí mít zařízení připojená k Microsoft Entra nainstalovaný kořenový certifikát podnikové certifikační autority. Tento certifikát se obvykle exportuje z řadiče domény a nasazují se do počítačů používajících Microsoft Intune se zásadou „důvěryhodný certifikát“.
Zásada by měla cílit na úložiště certifikátů počítače (kořen důvěryhodnosti) a být přiřazena příslušným skupinám uživatelů nebo zařízení. Po aplikaci budou počítače vidět certifikáty vydané danou certifikační autoritou, včetně certifikátů KDC, jako „důvěryhodné“ a striktní ověření bude možné úspěšně dokončit.
Modely nasazení, výzvy a osvědčené postupy
Windows Hello pro firmy podporuje cloudové, hybridní nebo plně lokální nasazení a každý model má jiné praktické důsledky, pokud jde o složitost, kompatibilitu a náklady.
V organizacích zaměřených primárně na cloud bez místní služby Active Directory je nejjednodušším řešením cloudový model, kde veškeré klíčové řízení a ověřování jsou zpracovávány pomocí Microsoft Entra ID, bez nutnosti lokální PKI nebo AD FS. Uživatelé přistupují k aplikacím Microsoft 365 a SaaS prostřednictvím jednotného přihlašování (SSO) s WHfB jako ověřovatelem bez hesla.
Ve většině středních a velkých podniků zůstává nejrealističtějším scénářem hybridní scénář : kritické zdroje zůstávají v místních podnicích, existují čisté aplikace Kerberos a cloudové služby jsou využívány současně. V tomto případě je třeba rozhodovat mezi důvěrou Kerberos do cloudu, důvěrou klíčů a důvěrou certifikátů; je třeba posoudit kompatibilitu se staršími aplikacemi; a v mnoha případech je nutné po určitou dobu pokračovat v metodách založených na heslech nebo čipových kartách.
Ve vysoce regulovaných odvětvích nebo v odvětvích s přísnými požadavky na datovou suverenitu (vláda, některé finanční nebo zdravotnické instituce) může dávat smysl plně lokální model s vlastním AD FS a PKI, kde se WHfB používá jako náhrada hesla, ale bez závislosti na cloudu. To je však za cenu větší provozní a údržbové složitosti.
Ve všech případech existují společné výzvy: kompatibilní hardware, sdílené pracovní stanice, odpor uživatelů ke změnám a zdůvodňování pojišťovnám a auditorům, že WHfB skutečně splňuje podmínky pro MFA . Klíčem je kombinovat WHfB se zásadami podmíněného přístupu, které vyžadují autentizátory odolné proti phishingu, umožnit opětovné ověřování nebo posílit MFA tam, kde je to vhodné (například u vysoce citlivých operací nebo kritických VPN připojení) a důkladně zdokumentovat model hrozby.
V kombinaci s řádným školením, jasnými zásadami pro PIN, monitorováním přihlašování a postupným zaváděním s podporou Intune nebo GPO umožňuje Windows Hello pro firmy organizacím výrazně přejít k modelu identity bez hesla, čímž se snižuje plocha pro útok, zlepšuje dodržování předpisů a uživatelům se poskytuje mnohem přirozenější a rychlejší přihlašovací proces.
