Windows Hello för företag, hårdvarunycklar och SSO

Om du hanterar identiteter i Microsoft-miljöer har du förmodligen hört talas om Windows Hello, Windows Hello för företag, nycklar hårdvara och SSOMen det är lätt att gå vilse bland så många akronymer, förtroendetyper och krav. Dessutom, i hybriddistributioner med äldre Active Directory, kan förståelsen för vad WHfB verkligen erbjuder jämfört med en enkel PIN-kod eller biometrisk inloggning vara skillnaden mellan ett smidigt projekt ... eller en konstant huvudvärk.

I den här artikeln kommer vi att gå igenom i detalj hur det fungerar Windows Hello för företag (WHfB), vilken roll spelar hårdvarunycklar, hur uppnås enkel inloggning (SSO)? och hur det skiljer sig från det "vanliga" Windows Hello för hemanvändare. Vi ska titta på de interna faserna (enhetsregistrering, provisionering, nyckelsynkronisering, certifikat och autentisering), distributionsmodeller (endast moln, hybrid och lokalt), förtroendetyper, PKI-krav, licensiering, verkliga distributionsutmaningar och hur allt detta passar in i moderna metoder som FIDO2 och lösenordsfri säkerhet.

Windows Hello vs Windows Hello för företag: Vad som verkligen förändras

Windows Hello (enkelt och enkelt) är användarupplevelsen för inloggning med PIN-kod eller biometri. på en Windows-enhet, utformad för både hem- och professionella miljöer. Windows Hello for Business (WHfB) är å andra sidan företagstillägget som lägger till starka identitetsfunktioner integrerade med Active Directory och Microsoft Entra ID.

Med båda metoderna kan du använda PIN-kod, fingeravtryck eller ansiktsigenkänning som stöds av TPM för att logga in på datorn. Du kan till och med autentisera mot en klassisk lokal domän. Den stora skillnaden är att WHfB skapar och hanterar kryptografiska autentiseringsuppgifter på företagsnivåNyckelpar eller certifikat länkade till användaren och enheten, hanterade av policyer och användbara för SSO på lokala och molnbaserade resurser.

Medan det "normala" Windows Hello i huvudsak är begränsat till ersätt lösenordet med en bekväm gest på den enhetenWHfB genererar en stark autentiseringsuppgift som identitetsleverantören (AD, Microsoft Entra ID eller AD FS) känner igen, lagrar och använder för att utfärda åtkomsttokens och upprätthålla säkerhet. Villkorlig åtkomst, strikt KDC-validering, PRT, Kerberos i molnet och andra avancerade kontroller.

Den logiska frågan är: om jag redan har domänanslutna enheter, hanterade med Intune, med TPM och biometri, och SSO till molnet via lösenordshashsynkronisering, Vad exakt vinner jag genom att tillsätta WHfB? Svaret ligger i hur nycklarna är byggda och validerade, hur enheten är länkad och i möjligheten att utöka den säkerheten till hela ekosystemet, inte bara den lokala inloggningen.

Grundläggande arkitektur: Windows Hello för företag-faser

WHfB är ett distribuerat system som bygger på flera komponenter: enhet, TPM, identitetsleverantör, PKI, katalogsynkronisering och SSO-mekanismerFör att förstå det utan att gå vilse är det bra att dela upp dess funktion i fem kronologiska implementeringsfaser.

1. Enhetsregistrering

Den första pusselbiten är enhetsregistrering hos identitetsleverantören (IdP)Det här steget låter dig associera enheten med en identitet i katalogen och aktivera den för automatisk autentisering när en användare loggar in.

I molnbaserade eller hybridmiljöer, IdP:n är Microsoft Enter ID och enheten registrerar sig hos dess enhetsregistreringstjänst (ansluten till Microsoft Entra, hybridansluten eller registrerad). I rent lokala scenarier är IdP:n vanligtvis AD FS med sin Enterprise Device Registration Service.

När denna registrering är klar tilldelar IdP teamet en unik identitet som kommer att användas för att upprätta förtroende mellan enhetskataloger i successiva autentiseringar. Denna post klassificeras efter "enhetsanslutningstyp", vilket avgör om enheten är ansluten till en lokal domän, till Entra ID, hybrid eller helt enkelt registrerad som personlig.

2. Provisionering: skapa Windows Hello-behållaren

När enheten är registrerad börjar fasen Provisionering av Windows Hello-inloggningsuppgifter för företagDet är här den så kallade Windows Hello-containern skapas, som logiskt grupperar allt användarens kryptografiska material på den datorn.

Det typiska upphandlingsflödet följer dessa huvudsteg, alltid efter en initial autentisering med svaga inloggningsuppgifter (användarnamn och lösenord):

• Användaren autentiserar sig med MFA på IdP:n (Microsoft Enter MFA eller en annan kompatibel metod, eller en MFA-adapter i AD FS i lokala miljöer).
• Efter att ha övervunnit den andra faktorn blir du ombedd att konfigurera en PIN-kod och, om kompatibel hårdvara finns tillgänglig, en biometrisk gest (fotavtryck, ansikte, iris).
• När PIN-koden har bekräftats genererar Windows Windows Hello-behållare för det kontot i det laget.
• Inuti den behållaren, en kryptografiskt nyckelpar (offentligt och privat), länkad till TPM när en sådan finns eller, om så inte är fallet, skyddad av programvara.
• La Den privata nyckeln finns kvar på enheten och kan inte exporteras, förblir skyddad av TPM och av PIN-/biometriska skydd.
• La den offentliga nyckeln är registrerad i IdP:n och den är länkad till användarobjektet: i Microsofts inloggnings-ID skrivs den till användaren, och i federerade lokala scenarier överför AD FS den till Active Directory.

Behållaren innehåller även en administrativ nyckelDetta är användbart för scenarier som PIN-återställning; på enheter med TPM lagras även ett datablock som innehåller TPM-certifikat. Allt material låses upp endast när användaren utför gesten (PIN eller biometri), och denna initiala MFA-kombination skapar förtroende mellan användaren, enheten och IdP.

3. Nycklar i behållaren: autentisering och användaridentifierare

Inom Windows Hello-behållaren hittar vi flera typer av nycklar, med olika roller, alla krypterad med PIN-baserat eller biometriskt skydd:

• AutentiseringsnyckelEtt par asymmetriska nycklar som genereras under registreringen och som alltid måste låsas upp med en PIN-kod eller biometrisk gest. Det är grunden för återvinning av annat material när PIN-koden ändras.
• AnvändaridentifieringsnycklarIdentitetsnycklar kan vara symmetriska eller asymmetriska beroende på identitetsleverantören (IdP) och modellen (nyckel eller certifikat). De används för att signera eller kryptera förfrågningar och tokens som riktas till identitetsleverantören. I företagsmiljöer genereras de vanligtvis som asymmetriska nyckelpar, med den publika nyckeln registrerad hos IdP:n.

Dessa användaridentifieringsnycklar kan erhållas på två huvudsakliga sätt: kopplad till företagets PKI för att utfärda certifikat (till exempel för VPN, RDP eller certifikatbaserad Kerberos-autentisering) eller genereras direkt av IdP:n i scenarier utan PKI (ren nyckelmodell).

Samma infrastruktur möjliggör användning av Windows Hello som en FIDO2/WebAuthn-autentiserare i kompatibla appar och webbplatser. Webbplatser kan skapa en FIDO-autentiseringsuppgift i Windows Hello-behållaren; vid efterföljande besök autentiserar användaren sig med sin PIN-kod eller biometri utan att avslöja lösenord.

4. Nyckelsynkronisering i hybridmiljöer

I hybridarkitekturer där samexisterar Microsoft-inloggnings-ID och Active DirectoryAtt bara registrera nyckeln i molnet räcker inte. Efter etableringen måste WHfB:s publika nyckel synkroniseras med den lokala katalogen för att aktivera autentisering och SSO mot lokala resurser.

I dessa scenarier tar Microsoft Entra Connect Sync hand om kopiera den publika nyckeln till attributet msDS-KeyCredentialLink för användarobjektet i Active Directory. Denna synkronisering är nyckeln så att domänkontrollanten kan validera signaturerna som genereras av enheten med den privata nyckeln som lagras i TPM:n.

5. Registrering av certifikat (endast vid behov)

I vissa modeller (som t.ex. certifikatförtroendeUtöver nycklarna behöver organisationen utfärda autentiseringscertifikat till användarna. I så fall aktiveras ytterligare en fas. registrering av certifikat.

Efter att den publika nyckeln registrerats genererar klienten en certifikatbegäran som skickar begäran till certifikatregistreringsmyndigheten, vanligtvis integrerad i AD FS i federerade distributioner. Den CRA:n validerar begäran med hjälp av företagets PKI och Den utfärdar ett certifikat som lagras i Hello-containern., återanvändbar för autentisering på lokala resurser som fortfarande är beroende av certifikat.

Autentisering, privat nyckel och SSO: hur allt hänger ihop

När registrerings- och etableringsfaserna är slutförda reduceras användarens vardag till något mycket enkelt: en gest (PIN-kod eller biometri) som "släpper" den privata nyckeln på enhetenDet intressanta är vad som händer bakom kulisserna.

När användaren låser upp datorn använder Windows den privata delen av WHfB-autentiseringsuppgifterna för att kryptografiskt signera data som skickas till IdP:nDetta verifierar signaturen med den publika nyckeln som lagras i användarobjektet. Eftersom PIN-koden aldrig lämnar enheten och inte heller den privata nyckeln, är processen motståndskraftig mot nätfiske och traditionell stöld av autentiseringsuppgifter.

I Microsoft Enter ID-scenarier resulterar slutförandet av den autentiseringen i en Primär uppdateringstoken (PRT)En JSON-webbtoken som innehåller användar- och enhetsinformation. Den är grunden för SSO till molnapplikationer och, i kombination med Microsoft Kerberos eller nyckelsynkronisering, även till lokala resurser.

Utan PRT, även om användaren har en giltig WHfB-autentiseringsuppgifter, Jag skulle förlora enkel inloggning. och skulle tvingas autentisera kontinuerligt i varje app. Det är därför som villkorsstyrda åtkomstpolicyer, oavsett om de är enhetsbaserade eller riskbaserade, vanligtvis tar hänsyn till förekomsten och giltigheten av den PRT:n.

För Active Directory, när nyckel- eller certifikatförtroende används, fungerar WHfB som en virtuellt smartkortAnvändaren signerar en nonce eller utmaning från KDC:n, domänkontrollanten validerar certifikatet eller nyckeln och utfärdar en Kerberos TGT-biljett, vilket möjliggör SSO till lokala tjänster integrerade med Kerberos.

Intern säkerhet: biometri, TPM och skydd mot attacker

En av grundpelarna i WHfB är att Biometrisk data lämnar aldrig enhetenMallarna som genereras av sensorerna lagras lokalt i databaser krypterad (till exempel i sökvägen C:\WINDOWS\System32\WinBioDatabase) med unika nycklar per databas, skyddad med AES i CBC-läge och SHA-256 som hashfunktion.

Det betyder att även om en angripare skulle få tillgång till dessa filer, Jag kunde inte rekonstruera bilden av användarens ansikte eller fingeravtryck.De kan inte heller användas på en annan enhet. Dessutom har varje sensor sin egen lagringsplats, vilket minskar risken för att en enda central punkt stjäl biometriska mallar.

PIN-koden för Windows Hello för företag är också bättre skyddad än ett traditionellt lösenord. Den överförs inte över nätverket, den valideras lokalt och TPM upprätthåller säkerhetsåtgärderna. blockeringar på grund av för många felaktiga försökDetta gör brute force- eller ordboksattacker värdelösa. Och om någon stjäl PIN-koden fungerar den bara på den specifika enheten, eftersom inloggningsuppgifterna är knutna till hårdvaran.

Att möta moderna hot (Hur man avgör om ett e-postmeddelande är nätfiske(återanvändning av lösenord, massstöld av autentiseringsuppgifter), WHfB förlitar sig på Enhetslänkade offentliga nyckelkryptografiDetta undviker, genom sin design, exponering av delade hemligheter. Detta överensstämmer perfekt med standarder och rekommendationer i regelverk som NIST 800-63B och med nollförtroende-säkerhetsmodeller.

Implementeringsmodeller: moln, hybrid och lokalt

WHfB är flexibelt topologiskt, men den flexibiliteten medför en viss komplexitet. Generellt sett kan vi tala om tre distributionsmodeller som kombineras på olika sätt. Microsoft Entra ID, Active Directory, PKI och federation.

Molnbaserad modell

I organisationer som lever nästan 100 % i Microsoft 365 och andra SaaS-tjänster, utan relevant lokal infrastruktur, är den enklaste modellen den av Endast moln med enheter anslutna till Microsoft. Logga inI det här scenariot:

• Alla användare och enheter finns i Microsoft Access ID.
• Enhets- och nyckelregistrering görs direkt i molnet.
• Ingen företags-PKI behövs inte heller domänkontrollantcertifikat.
• SSO är baserat på PRT- och Microsoft Entra-tokens för applikationer.

Det är det mest direkta alternativet för molnbaserade företag, med låg infrastrukturkostnad och relativt enkel implementering, perfekt när lokala resurser inte är tillgängliga eller är minimala.

Hybridmodell: det vanligaste fallet

De allra flesta företagen befinner sig någonstans mittemellan: Historisk Active Directory kombinerad med Microsoft Login ID synkroniseradWHfB lyser här, men det är också där konfigurationsproblem är vanligast om de inte planeras väl.

I en hybridmiljö synkroniseras identiteter med Microsoft Entra Connect Sync, och det finns flera möjliga kombinationer av distributionsmodell (hybrid) och typ av förtroende (moln Kerberos, nyckel eller certifikat)Målet är vanligtvis att erbjuda:

• SSO till molntjänster (Sharepoint Online, Teams, OIDC/SAML-applikationer).
• Transparent tillgång till lokala resurser (aktier, appar Kerberos, VPN, RDP).
• En stegvis utgångsväg för lösenord, samtidigt som äldre applikationer bibehålls.

De viktigaste typerna av förtroende i hybridscenarier är:

• Kerberos i molnetMicrosoft Entra Kerberos utfärdar TGT:er för Active Directory utan att kräva ytterligare Public Key Infrastructure (PKI). Detta är den modernaste och enklaste hybridmodellen, eftersom den utnyttjar befintlig FIDO2-infrastruktur och inte kräver synkronisering av publika nycklar med Active Directory.
• Viktigt förtroendeAnvändare autentiserar sig mot Active Directory med en enhetsbunden nyckel; domänkontrollanter kräver specifika certifikat. PKI krävs för domänkontrollanter, men inte för användarcertifikat.
• CertifikatsäkerhetAnvändarautentiseringscertifikat utfärdas och används för att hämta Kerberos TGT:er. Detta kräver fullständig PKI, AD FS som ett CRA och mer intensiv konfiguration.

Att välja rätt typ av förtroende är avgörande: ingen är i sig "säkrare"De varierar dock i kostnad, komplexitet och infrastrukturkrav. Att förlita sig på Kerberos i molnet är ofta det bästa alternativet för nya implementeringar, förutsatt att klient- och serverversionerna av Windows uppfyller minimikraven.

Ren lokal modell

Organisationer med starka regulatoriska begränsningar, eller med liten eller ingen molnanvändning, kan välja en WHfB-distribution. 100 % lokalt, med stöd av Active Directory och AD FSI den här modellen:

• Enhetsregistrering hanteras AD FS.
• Autentisering kan vara nyckelbaserad eller certifikatbaserad, men den backas alltid upp av en företags-PKI.
• MFA-alternativ inkluderar adaptrar för AD FS eller lösningar som Azure MFA Server (redan äldre) integrerade lokalt.

Denna metod ger en full kontroll över autentiseringsdataDet kräver dock en avsevärd underhållsinsats (PKI, AD FS, publicering av CRL:er som är tillgängliga för datorer som inte är domänanslutna, etc.), något som inte alla organisationer är villiga att anta på lång sikt.

Tillgänglig PKI, domänkontrollantcertifikat och CRL:er

I modeller som förlitar sig på certifikat (oavsett om det gäller användare, domänkontrollanter eller båda) blir PKI kärnan i förtroendet. WHfB kräver strikt validering av KDC:er när en enhet som är ansluten till Microsoft Enter autentiseras mot en lokal domän.

I praktiken innebär detta att domänkontrollantcertifikatet måste uppfylla ett antal tekniska villkor: utfärdad av en betrodd rot-CA för enheten, baserat på Kerberos-autentiseringsmallen, med "KDC-autentisering" EKU, korrekt DNS-namn, RSA 2048 och SHA-256 som signaturalgoritmbland andra krav.

Dessutom är det viktigt att enheten kan kontrollera återkallelsen av certifikatenHär ligger det klassiska problemet med CRL:er: en enhet som endast är ansluten till Microsoft Entra kan inte läsa LDAP-sökvägar i Active Directory om den inte ännu har autentiserats, så det är nödvändigt att publicera CRL-distributionspunkten i en HTTP-URL som är tillgänglig utan autentisering.

Detta innebär att förbereda en webbserver (till exempel IIS), skapa en virtuell katalog (cdp) och justera behörigheter. NTFS och från delade resurser, inaktivera lagring Vid offline-cachning, konfigurera CA:n att publicera CRL:n på den delade resursen och exponera den via HTTP. När du är klar måste du Förnya domänkontrollantcertifikat för att inkludera den nya CDP:n och säkerställa att företagets rotcertifikat distribueras till enheter som är anslutna till Microsoft Entra (t.ex. med Intune och en profil för "betrott certifikat").

Katalogsynkronisering, MFA och enhetskonfiguration

Slutanvändarens upplevelse med Windows Hello för företag beror till stor del på Hur katalogsynkronisering, MFA och policykonfiguration är integrerade.

I hybriddistributioner synkroniserar Microsoft Entra Connect Sync inte bara konton; det kan också synkronisera kritiska attribut som msDS-KeyCredentialLinksom innehåller den offentliga WHfB-nyckel som krävs för autentisering i AD. I lokala miljöer med Azure MFA Server används synkronisering för att importera användare till MFA-servern, som sedan frågar molntjänsten för verifiering.

När det gäller flerfaktorsautentisering har organisationer flera alternativ: Microsoft Entra MFA för moln- eller hybridscenarierExterna metoder integrerade genom extern autentisering i Entra ID eller via federation, och MFA-adaptrar från tredje part för AD FS i lokala miljöer. Flaggan FederatedIdpMfaBehavior i federerade domäner avgör om Entra ID accepterar, kräver eller ignorerar MFA som utförs av den federerade IdP:n, vilket kan vara avgörande för att WHfB-provisionering ska fungera korrekt.

WHfB-konfiguration på utrustningen kan göras med gruppolicy (GPO) eller CSP via MDM (till exempel Intune). I moderna organisationer är det vanligt att aktivera automatisk WHfB-registrering, tvinga fram MFA vid första inloggningen, definiera principer för PIN-komplexitet och kontrollera vilka biometriska metoder som accepteras (endast certifierade sensorer, IR-kameror etc.).

Parallellt är det viktigt att beakta återhämtningsupplevelsen: självbetjäningsåterställning av PIN-koden, alternativa metoder som FIDO2-nycklar och BitLocker-kryptering för att skydda vilande data om enheten förloras eller blir stulen.

Licenser, systemkrav och praktiska begränsningar

En av de vanliga myterna är att man alltid behöver använda WHfB Microsoft Ange ID P1 eller P2I verkligheten är WHfBs kärnfunktionalitet tillgänglig med den kostnadsfria Entra ID-nivån, och den flerfaktorsautentisering som krävs för lösenordsfri provisionering kan också aktiveras utan premiumlicenser, även om funktioner som automatisk MDM-registrering, avancerad villkorlig åtkomst eller uppskjuten enhetsgenomskrivning kräver högre nivåer.

När det gäller operativsystem stöder praktiskt taget alla moderna klientversioner av Windows WHfB, men Förtroende för Kerberos i molnet kräver konkreta minimikrav (till exempel Windows 10 21H2 med vissa patchar eller specifika versioner av Windows 11På serversidan kan alla versioner av Windows Server som stöds generellt fungera som en domänkontrollant, även om Kerberos-delen i molnet kräver specifika versioner och uppdateringar på domänkontrollanterna.

Utöver de tekniska aspekterna finns det mycket praktiska utmaningar: delad utrustning där WHfB, eftersom det är enhets- och användarspecifikt, passar regelbundet; hårdvara utan TPM 2.0 eller utan biometriska sensorer; eller miljöer där kostnaden för att förnya gamla maskinparker, driftsätta PKI och uppgradera 2012 års DC:er gör fullständig WHfB-implementering oattraktiv på kort sikt.

I de fall där den rimliga vägen innebär kombinera WHfB med andra lösenordsfria faktorer (FIDO2-nycklar, smartkort, telefonautentisering) för att täcka delade arbetsstationer, icke-Windows-plattformar eller mycket mobila användare, vilket lämnar WHfB som den primära autentiseraren i portabel företag kopplade till Entra eller hybrider.

Sett över hela bilden erbjuder Windows Hello för företag mycket mer än "en bra PIN-kod": det introducerar hårdvarubundna asymmetriska autentiseringsuppgifter, strikt KDC-verifiering, djup integration med Microsoft Entra ID och Active Directory, och ett robust ramverk för säker SSO både i molnet och lokalt. Dess verkliga värde jämfört med grundläggande Windows Hello beror dock på din utgångspunkt: i moderna molnbaserade eller hybridmiljöer med uppdaterad PKI och DC överväger språnget inom säkerhet och hantering tydligt ansträngningen; i mycket gamla domäner, med lite förberedd infrastruktur och inga moderniseringsplaner, kan det vara mer meningsfullt att först avancera inom hårdvara, PKI och åtkomstkontroll innan man utnyttjar WHfB:s fulla potential.

Relaterad artikel:

Så här tar du reda på vilka appar som har åtkomst till din kamera, mikrofon eller plats i Windows 11

Isaac

Passionerad författare om bytesvärlden och tekniken i allmänhet. Jag älskar att dela med mig av min kunskap genom att skriva, och det är vad jag kommer att göra i den här bloggen, visa dig alla de mest intressanta sakerna om prylar, mjukvara, hårdvara, tekniska trender och mer. Mitt mål är att hjälpa dig att navigera i den digitala världen på ett enkelt och underhållande sätt.