Windows Hello pro firmy, hardwarové klíče a jednotné přihlašování (SSO)

Pokud spravujete identity v prostředích Microsoftu, pravděpodobně jste už slyšeli o Windows Hello, Windows Hello pro firmy, klávesy technické vybavení a jednotné přihlašováníJe ale snadné se ztratit v tolika zkratkách, typech důvěryhodnosti a požadavcích. Navíc v hybridních nasazeních se starší službou Active Directory může být pochopení toho, co WHfB skutečně nabízí ve srovnání s jednoduchým přihlášením pomocí PINu nebo biometrických údajů, rozdílem mezi hladkým průběhem projektu… a neustálou bolestí hlavy.

V tomto článku si podrobně rozebereme, jak to funguje Windows Hello pro firmy (WHfB), jakou roli hrají hardwarové klíče, jak se dosahuje jednotného přihlašování (SSO)? a jak se liší od „běžného“ Windows Hello pro domácí uživatele. Podíváme se na interní fáze (registrace zařízení, zřizování, synchronizace klíčů, certifikáty a ověřování), modely nasazení (pouze cloudové, hybridní a lokální), typy důvěryhodnosti, požadavky PKI, licencování, výzvy při nasazení v reálném světě a jak to vše zapadá do moderních přístupů, jako je FIDO2 a zabezpečení bez hesla.

Windows Hello vs. Windows Hello pro firmy: Co se skutečně mění

Windows Hello (jednoduché a jednoduché) je uživatelské rozhraní pro přihlašování pomocí PINu nebo biometrických údajů. na zařízení s Windows, určeném pro domácí i profesionální prostředí. Windows Hello for Business (WHfB) je naopak podnikové rozšíření, které přidává silné funkce pro identifikaci integrované s Active Directory a Microsoft Entra ID.

S oběma metodami můžete použít Podpora PINu, otisku prstu nebo rozpoznávání obličeje TPM pro přihlášení k počítači. Můžete se dokonce ověřit i u klasické lokální domény. Velký rozdíl spočívá v tom, že WHfB vytváří a spravuje kryptografické přihlašovací údaje na podnikové úrovniPáry klíčů nebo certifikáty propojené s uživatelem a zařízením, spravované politikami a použitelné pro jednotné přihlašování (SSO) na lokálních a cloudových zdrojích.

Zatímco „normální“ Windows Hello je v podstatě omezeno na nahraďte heslo na daném zařízení praktickým gestemWHfB generuje silné přihlašovací údaje, které poskytovatel identity (AD, Microsoft Entra ID nebo AD FS) rozpozná, uloží a použije k vydávání přístupových tokenů a vynucení zabezpečení. Podmíněný přístup, striktní validace KDC, PRT, Kerberos v cloudu a další pokročilé ovládací prvky.

Logická otázka zní: pokud již mám zařízení připojená k doméně, spravovaná pomocí Intune, s TPM a biometrií a SSO do cloudu prostřednictvím synchronizace hash hesel, Co přesně získám přidáním WHfB? Odpověď spočívá v tom, jak jsou klíče sestavovány a ověřovány, jak je zařízení propojeno a ve schopnosti rozšířit toto zabezpečení na celý ekosystém, nejen na lokální přihlášení.

Základní architektura: Fáze Windows Hello pro firmy

WHfB je distribuovaný systém, který se opírá o několik komponent: zařízení, TPM, poskytovatel identity, PKI, synchronizace adresářů a mechanismy SSOAbychom tomu porozuměli, aniž bychom se v tom ztratili, je užitečné rozdělit jeho fungování do pěti chronologických fází implementace.

1. Registrace zařízení

Prvním dílkem skládačky je registrace zařízení u poskytovatele identity (IdP)Tento krok umožňuje přiřadit zařízení k identitě v adresáři a povolit automatické ověření při přihlášení uživatele.

V cloudovém nebo hybridním prostředí, Poskytovatel identity (IdP) je Microsoft Enter ID. a zařízení se zaregistruje u své registrační služby zařízení (připojeno k Microsoft Entra, hybridně připojeno nebo registrované). V čistě lokálních scénářích je IdP obvykle AD FS se službou Enterprise Device Registration Service.

Po dokončení této registrace IdP přidělí tým jedinečná identita, která bude použita k navázání důvěryhodnosti mezi adresářem zařízení v následných ověřováních. Tento záznam je klasifikován podle „typu připojení zařízení“, který určuje, zda je zařízení připojeno k lokální doméně, k Entra ID, hybridní nebo jednoduše registrované jako osobní.

2. Zřizování: vytvoření kontejneru Windows Hello

Jakmile je zařízení zaregistrováno, začíná fáze Zřizování přihlašovacích údajů Windows Hello pro firmyZde se vytváří tzv. kontejner Windows Hello, který logicky seskupuje veškerý kryptografický materiál uživatele na daném počítači.

Typický proces zadávání veřejných zakázek se řídí těmito hlavními kroky, vždy po počáteční ověření se slabými přihlašovacími údaji (uživatelské jméno a heslo):

• Uživatel se ověřuje pomocí MFA u IdP. (Microsoft Enter MFA nebo jiná kompatibilní metoda, případně adaptér MFA v AD FS v místním prostředí).
• Po překonání tohoto druhého faktoru budete požádáni o konfiguraci PIN a, pokud je k dispozici kompatibilní hardware, biometrické gesto (otisk nohy, obličej, duhovka).
• Po potvrzení PIN kódu systém Windows vygeneruje Kontejner Windows Hello pro ten účet v tom týmu.
• Uvnitř této nádoby, a pár kryptografických klíčů (veřejný a soukromý), propojen s TPM, pokud existuje, nebo, pokud neexistuje, chráněn softwarově.
• La Soukromý klíč zůstává v zařízení a nelze jej exportovat., přičemž zůstávají chráněny modulem TPM a chrániči PIN/biometrickými prvky.
• La veřejný klíč je registrován v IdP a je propojen s objektem uživatele: v ID přihlášení k Microsoftu je zapsán uživateli a ve federovaných lokálních scénářích jej služba AD FS přenese do služby Active Directory.

Součástí kontejneru je také administrativní klíčTo je užitečné pro scénáře, jako je reset PINu; na zařízeních s TPM je také uložen blok dat obsahující certifikáty TPM. Veškerý materiál se odemkne pouze tehdy, když uživatel provede gesto (PIN nebo biometrii), a tato počáteční kombinace MFA navazuje důvěru mezi uživatelem, zařízením a IdP.

3. Klíče v kontejneru: ověřování a identifikátor uživatele

V kontejneru Windows Hello najdeme několik typů kláves s různými rolemi, všechny šifrované pomocí PIN kódu nebo biometrické ochrany:

• Ověřovací klíčDvojice asymetrických klíčů generovaných během registrace, které musí být vždy odemčeny PINem nebo biometrickým gestem. Je to základ, na kterém se recyklují další materiály při změně PINu.
• Klíče identifikátoru uživateleKlíče identity mohou být symetrické nebo asymetrické v závislosti na poskytovateli identity (IdP) a modelu (klíč nebo certifikát). Používají se k podepisování nebo šifrování požadavků a tokenů směřujících k poskytovateli identity. V podnikových prostředích se obvykle generují jako asymetrické páry klíčů, přičemž veřejný klíč je registrován u IdP.

Tyto klíče identifikace uživatele lze získat dvěma hlavními způsoby: spojené s podnikovou PKI pro vydávání certifikátů (například pro VPN, RDP nebo ověřování Kerberos na základě certifikátů) nebo generované přímo poskytovatelem identity (IdP) ve scénářích bez PKI (model čistého klíče).

Stejná infrastruktura umožňuje použití Windows Hello jako ověřovač FIDO2/WebAuthn v kompatibilních aplikacích a na webových stránkách. Webové stránky mohou v kontejneru Windows Hello vytvořit přihlašovací údaje FIDO; při následných návštěvách se uživatel ověřuje pomocí PIN kódu nebo biometrických údajů, aniž by musel odhalovat hesla.

4. Synchronizace klíčů v hybridních prostředích

V hybridních architekturách, kde koexistují Přihlašovací ID Microsoftu a služba Active DirectoryPouhá registrace klíče v cloudu nestačí. Po zřízení je nutné veřejný klíč WHfB synchronizovat s lokálním adresářem, aby mohl fungovat. ověřování a jednotné přihlašování (SSO) pro místní zdroje.

V těchto scénářích se o to postará Microsoft Entra Connect Sync. zkopírujte veřejný klíč do atributu msDS-KeyCredentialLink objektu uživatele v Active Directory. Tato synchronizace je klíčová, aby řadič domény mohl ověřit podpisy generované zařízením pomocí privátního klíče uloženého v modulu TPM.

5. Registrace certifikátů (pouze v případě potřeby)

U některých modelů (jako např. důvěryhodnost certifikátuKromě klíčů musí organizace vydávat uživatelům ověřovací certifikáty. V takovém případě se aktivuje další fáze. registrace certifikátů.

Po registraci veřejného klíče klient vygeneruje žádost o certifikát který odešle požadavek autoritě registru certifikátů, obvykle integrované do služby AD FS ve federovaných nasazeních. Tato CRA ověří požadavek pomocí podnikové PKI a Vydá certifikát, který je uložen v kontejneru Hello., opakovaně použitelné pro ověřování na lokálních zdrojích, které stále spoléhají na certifikáty.

Autentizace, soukromý klíč a SSO: jak to všechno do sebe zapadá

Jakmile jsou fáze registrace a zřizování dokončeny, každodenní život uživatele se zredukuje na něco velmi jednoduchého: gesto (PIN nebo biometrické údaje), které „uvolní“ soukromý klíč na zařízeníZajímavé je, co se děje v zákulisí.

Když uživatel odemkne počítač, systém Windows použije soukromou část přihlašovacích údajů WHfB k kryptograficky podepisovat data odeslaná poskytovateli identity (IdP)Tím se ověřuje podpis pomocí veřejného klíče uloženého v objektu uživatele. Protože PIN nikdy neopouští zařízení, stejně jako soukromý klíč, je proces odolný vůči phishingu a tradiční krádeži přihlašovacích údajů.

V scenárech Microsoft Enter ID má dokončení tohoto ověřování za následek Primární obnovovací token (PRT)Webový token JSON obsahující informace o uživateli a zařízení. Je základem jednotného přihlašování (SSO) ke cloudovým aplikacím a v kombinaci s Microsoft Kerberos nebo synchronizací klíčů také k lokálním zdrojům.

Bez PRT, i když má uživatel platné pověření WHfB, Přišel bych o jednotné přihlašování. a byl by nucen se v každé aplikaci průběžně ověřovat. Proto zásady podmíněného přístupu, ať už založené na zařízení nebo na riziku, obvykle berou v úvahu přítomnost a platnost daného PRT.

V případě služby Active Directory při použití důvěryhodnosti klíčů nebo certifikátů funguje WHfB jako virtuální čipová kartaUživatel podepíše nonce nebo výzvu z KDC, řadič domény ověří certifikát nebo klíč a vydá tiket Kerberos TGT, čímž umožní jednotné přihlašování (SSO) k lokálním službám integrovaným s Kerberos.

Vnitřní zabezpečení: biometrie, TPM a ochrana před útoky

Jedním z pilířů WHfB je, že Biometrická data nikdy neopouštějí zařízeníŠablony generované senzory jsou uloženy lokálně v databází zašifrované (například v cestě C:\WINDOWS\System32\WinBioDatabase) s použitím unikátních klíčů pro každou databázi, chráněné algoritmem AES v režimu CBC a hašovací funkcí SHA-256.

To znamená, že i kdyby útočník získal přístup k těmto souborům, Nedokázal jsem rekonstruovat obraz obličeje ani otisk prstu uživatele.ani je nelze použít na jiném zařízení. Každý senzor si navíc uchovává vlastní úložiště, což snižuje možnost krádeže biometrických šablon z jediného centrálního bodu.

PIN kód pro Windows Hello pro firmy je také lépe chráněn než tradiční heslo. Nepřenáší se po síti, je ověřován lokálně a TPM vynucuje bezpečnostní opatření. bloky kvůli příliš velkému počtu nesprávných pokusůDíky tomu jsou útoky hrubou silou nebo slovníkové útoky zbytečné. A pokud někdo ukradne PIN, bude to fungovat pouze na daném konkrétním zařízení, protože přihlašovací údaje jsou vázány na hardware.

Tváří v tvář moderním hrozbám (Jak zjistit, zda je e-mail phishingový(opětovné použití hesla, hromadná krádež přihlašovacích údajů), WHfB se spoléhá na Kryptografie s veřejným klíčem propojeným se zařízenímTím se záměrně zabrání odhalení sdílených tajemství. To je v dokonalém souladu se standardy a doporučeními předpisů, jako je NIST 800-63B, a s bezpečnostními modely s nulovou důvěrou.

Modely nasazení: cloudové, hybridní a on-premise

WHfB je flexibilní z hlediska topologie, ale tato flexibilita s sebou nese určitou složitost. Obecně řečeno, můžeme hovořit o třech modelech nasazení, které se kombinují různými způsoby. Microsoft Entra ID, Active Directory, PKI a federace.

Model pouze pro cloud

V organizacích, které žijí téměř ze 100 % Microsoft 365 a dalších SaaS služeb, bez relevantní lokální infrastruktury, nejjednodušším modelem je model Pouze cloud se zařízeními připojenými k Microsoftu. Přihlásit seV tomto scénáři:

• Všichni uživatelé a zařízení se nacházejí v ID Microsoft Entra.
• Registrace zařízení a klíčů probíhá přímo v cloudu.
• Není potřeba žádná podniková PKI ani certifikáty řadiče domény.
• Jednotné přihlašování (SSO) je založeno na tokenech PRT a Microsoft Entra pro aplikace.

Je to nejpřímější možnost pro společnosti, které primárně využívají cloud. nízké náklady na infrastrukturu a relativně jednoduché nasazení, ideální, když místní zdroje nejsou k dispozici nebo jsou minimální.

Hybridní model: nejběžnější případ

Velká většina firem se nachází někde mezi: Historické služby Active Directory v kombinaci se synchronizovaným přihlašovacím ID MicrosoftuWHfB zde vyniká, ale je to také místo, kde se nejčastěji vyskytují problémy s konfigurací, pokud nejsou dobře naplánovány.

V hybridním prostředí jsou identity synchronizovány s nástrojem Microsoft Entra Connect Sync a existuje několik možných kombinací model nasazení (hybridní) a typ důvěryhodnosti (cloudový Kerberos, klíč nebo certifikát)Cílem je obvykle nabídnout:

• Jednotlivé přihlašování (SSO) ke cloudovým službám (SharePoint Online, Teams, aplikace OIDC/SAML).
• Transparentní přístup k místním zdrojům (akcie, aplikace Kerberos, VPN, RDP).
• Postupný únik hesel při zachování starších aplikací.

Hlavní typy důvěry v hybridních scénářích jsou:

• Kerberos v clouduMicrosoft Entra Kerberos vydává TGT pro Active Directory bez nutnosti další infrastruktury veřejných klíčů (PKI). Jedná se o nejmodernější a nejjednodušší hybridní model, protože využívá stávající infrastrukturu FIDO2 a nevyžaduje synchronizaci veřejných klíčů s Active Directory.
• Klíčová důvěraUživatelé se ověřují v Active Directory pomocí klíče vázaného na zařízení; řadiče domény vyžadují specifické certifikáty. PKI je vyžadována pro řadiče domény, ale ne pro uživatelské certifikáty.
• Důvěra certifikátuCertifikáty pro ověřování uživatelů se vydávají a používají k získání certifikátů Kerberos TGT. To vyžaduje plnou infrastrukturu PKI, AD FS jako CRA a náročnější konfiguraci.

Výběr správného typu důvěry je zásadní: žádný není ze své podstaty „bezpečnější“Liší se však v ceně, složitosti a požadavcích na infrastrukturu. Spoléhání se na Kerberos v cloudu je často nejlepší volbou pro nová nasazení, za předpokladu, že klientské i serverové verze Windows splňují minimální požadavky.

Čistě lokální model

Organizace se silnými regulačními omezeními nebo s malým či žádným zaváděním cloudu se mohou rozhodnout pro nasazení WHfB. 100% lokální, podporováno službou Active Directory a AD FSV tomto modelu:

• Registrace zařízení je spravována AD FS.
• Ověřování může být založeno na klíči nebo certifikátu, ale vždy je podpořeno podniková PKI.
• Možnosti MFA zahrnují adaptéry pro AD FS nebo řešení, jako je Azure MFA Server (již starší) integrovaný v místní síti.

Tento přístup poskytuje plná kontrola nad ověřovacími údajiVyžaduje to však značné úsilí na údržbu (PKI, AD FS, publikování seznamů CRL přístupných z počítačů nepřipojených k doméně atd.), což nejsou všechny organizace ochotny dlouhodobě nést.

Přístupná PKI, certifikáty řadiče domény a seznamy CRL

V modelech, které se spoléhají na certifikáty (ať už pro uživatele, řadiče domény nebo obojí), se PKI stává srdcem důvěry. WHfB vyžaduje přísná validace KDC když se zařízení připojené k Microsoft Enter ověřuje v místní doméně.

V praxi to znamená, že certifikát řadiče domény musí splňovat řadu technických podmínek: vydané důvěryhodnou kořenovou certifikační autoritou pro zařízení, na základě šablony ověřování Kerberos, s EKU „KDC authentication“, správným názvem DNS, RSA 2048 a SHA-256 jako podpisovým algoritmemmimo jiné požadavky.

Dále je nezbytné, aby zařízení mohlo zkontrolovat zneplatnění certifikátůZde spočívá klasický problém s CRL: zařízení připojené pouze k Microsoft Entra nemůže číst cesty LDAP v Active Directory, pokud ještě nebylo ověřeno, takže je nutné publikovat distribuční bod CRL v HTTP URL přístupná bez ověřování.

To zahrnuje přípravu webového serveru (například IIS), vytvoření virtuálního adresáře (cdp) a úpravu oprávnění. NTFS a ze sdílených zdrojů zakažte skladování V offline ukládání do mezipaměti nakonfigurujte certifikační autoritu (CA) tak, aby publikovala seznam CRL na daném sdíleném prostředku a zpřístupnila jej prostřednictvím HTTP. Po dokončení je třeba Obnovení certifikátů řadiče domény zahrnout nový CDP a zajistit, aby byl kořenový certifikát podniku nasazen na zařízení připojená k Microsoft Entra (např. s Intune a profilem „důvěryhodného certifikátu“).

Synchronizace adresářů, MFA a konfigurace zařízení

Zkušenosti koncového uživatele s Windows Hello pro firmy do značné míry závisí na Jak je integrována synchronizace adresářů, MFA a konfigurace zásad.

V hybridních nasazeních Microsoft Entra Connect Sync nejen synchronizuje účty, ale také dokáže synchronizovat kritické atributy, jako je msDS-KeyCredentialLinkkterý obsahuje veřejný klíč WHfB potřebný pro ověřování v Active Directory. V místních prostředích se serverem Azure MFA se synchronizace používá k importu uživatelů na server MFA, který poté odešle dotaz cloudové službě k ověření.

Pokud jde o vícefaktorové ověřování, organizace mají několik možností: Microsoft Entra MFA pro cloudové nebo hybridní scénářeExterní metody integrované prostřednictvím externího ověřování v Entra ID nebo prostřednictvím federace a adaptéry MFA třetích stran pro AD FS v místních prostředích. Příznak FederatedIdpMfaBehavior ve federovaných doménách určuje, zda Entra ID přijímá, vyžaduje nebo ignoruje MFA prováděné federovaným IdP, což může být zásadní pro správné fungování zřizování WHfB.

Konfiguraci WHfB na zařízení lze provést pomocí skupinové zásady (GPO) nebo CSP prostřednictvím MDM (například Intune). V moderních organizacích je běžné povolit automatickou registraci WHfB, vynutit vícefaktorovou ověření při prvním přihlášení, definovat zásady pro složitost PINu a kontrolovat, které biometrické metody jsou akceptovány (pouze certifikované senzory, infračervené kamery atd.).

Souběžně je nezbytné zvážit zkušenosti s rekonvalescencí: samoobslužné resetování PINu, alternativní metody, jako jsou klíče FIDO2, a Šifrování BitLocker pro ochranu uložených dat v případě ztráty nebo krádeže zařízení.

Licence, systémové požadavky a praktická omezení

Jedním z běžných mýtů je, že WHfB je nutné používat vždy. Microsoft Enter ID P1 nebo P2Ve skutečnosti je základní funkce WHfB k dispozici s bezplatnou úrovní Entra ID a vícefaktorové ověřování vyžadované pro zřizování bez hesla lze povolit i bez prémiových licencí, ačkoli funkce jako automatická registrace MDM, pokročilý podmíněný přístup nebo odložený zápis zařízení vyžadují vyšší úrovně.

Pokud jde o operační systém, prakticky všechny moderní klientské verze Windows podporují WHfB, ale Důvěra v Kerberos v cloudu vyžaduje konkrétní minimální požadavky. (například Windows 10 21H2 s určitými záplatami nebo specifickými verzemi Windows 11Na straně serveru může jako řadič domény obecně fungovat jakákoli podporovaná verze systému Windows Server, ačkoli část Kerberos v cloudu vyžaduje specifické verze a aktualizace na řadičích domény.

Kromě technických aspektů existují i ​​velmi praktické výzvy: sdílené vybavení, kde WHfB, vzhledem k specifickému uspořádání zařízení a uživatele, pravidelně sedí; hardware bez TPM 2.0 nebo biometrických senzorů; nebo prostředí, kde náklady na obnovu starých vozových parků, nasazení PKI a modernizaci řadičů domény z roku 2012 činí plné přijetí WHfB v krátkodobém horizontu neatraktivním.

V případech rozumná cesta zahrnuje kombinujte WHfB s dalšími faktory bez hesla (klíče FIDO2, čipové karty, ověřování telefonem) pro pokrytí sdílených pracovních stanic, platforem jiných než Windows nebo vysoce mobilních uživatelů, čímž se WHfB stane primárním ověřovatelem v notebooky korporace propojené s Entrou nebo hybridní společnosti.

Celkově vzato nabízí Windows Hello pro firmy mnohem víc než jen „příjemný PIN“: zavádí hardwarově vázané asymetrické přihlašovací údaje, přísné ověřování KDC, hluboká integrace s Microsoft Entra ID a Active Directory a robustní framework pro zabezpečené jednotné přihlašování (SSO). jak v cloudu, tak i v místních prostředích. Jeho skutečná hodnota ve srovnání se základním Windows Hello však závisí na vašem výchozím bodě: v moderním cloudovém nebo hybridním prostředí s aktualizovanou PKI a DC skok v zabezpečení a správě jasně převažuje nad úsilím; ve velmi starých doménách s malou připravenou infrastrukturou a bez modernizačních plánů může být smysluplnější nejprve pokročit v hardwaru, PKI a řízení přístupu, než se plně využije potenciál WHfB.

Související článek:

Jak zjistit, které aplikace mají přístup k vaší kameře, mikrofonu nebo poloze ve Windows 11

Isaac

Vášnivý spisovatel o světě bytů a technologií obecně. Rád sdílím své znalosti prostřednictvím psaní, a to je to, co budu dělat v tomto blogu, ukážu vám všechny nejzajímavější věci o gadgetech, softwaru, hardwaru, technologických trendech a dalších. Mým cílem je pomoci vám orientovat se v digitálním světě jednoduchým a zábavným způsobem.