Så här implementerar du Windows Hello för företag i en hybriddomän

Om du har fälttekniker eller användare med bärbara datorer och surfplattor De som ständigt sitter fastklistrade vid pekskärmen är oftast trötta på att skriva lösenordet om och om igen. Windows Hello för företag (Windows Hello for Business) skapades just för det ändamålet: att ersätta lösenordet med mer bekväma och säkra inloggningsmetoder, såsom PIN, fingeravtryck eller ansiktsigenkänning, samtidigt som integrationen med din domän och med Microsoft Login ID (tidigare Azure AD) bibehålls.

Problemet är att när man börjar läsa officiell dokumentation, så börjar begrepp som Distributionsmodeller, förtroendetyper, Kerberos i molnet, PKI, AD FS, MFA, nyckelsynkronisering...och det är lätt att bli överväldigad, särskilt om du inte vill krångla för mycket med domänkontrollanter. I den här guiden kommer vi att förklara det lugnt och vad du verkligen behöver för att implementera Windows Hello i en domänmiljö (inklusive hybrid) och vilka delar du kan ignorera beroende på din faktiska situation.

Vad är Windows Hello för företag och hur skiljer det sig från det "vanliga" Windows Hello?

Windows Hello för företag är företagsversionen av Windows Hello som ersätter lösenord med offentliga nyckeluppgifter kopplade till enhetenDen används inte bara för att låsa upp datorn: den används också för att autentisera med Active Directory och/eller Microsoft Access ID.

I praktiken loggar användaren in med hjälp av en PIN-kod, fingeravtryck eller ansiktsigenkänningMen undertill använder Windows ett par asymmetriska nycklar som lagras och skyddas på enheten (helst i TPM) för att autentisera mot identitetsleverantören (IdP): det kan vara bara Microsoft Entra ID, en hybridmiljö eller en rent lokal miljö med AD FS.

Den privata nyckeln lämnar aldrig enheten; Den offentliga nyckeln är registrerad med Microsoft Enter ID eller AD FS under registreringen. Därifrån kan användaren utföra SSO mot molnresurser och/eller lokala resurser beroende på vilken distributionsmodell du väljer.

Windows Hello-distributionsmodeller för företag

Innan man experimenterar med GPO:er eller Intune är det viktigt att vara tydlig med vad implementeringsmodell Det passar din miljö. Windows Hello för företag skiljer mellan tre huvudscenarier, beroende på var identiteter och resurser finns:

Endast i molnetOrganisationer som bara har Microsoft Entra ID-identiteter och inte har åtkomst till lokala resurser. Enheter ansluter till Microsoft Entra (Azure AD-anslutning) eller registrerar sig, och allt som användaren behöver (SharePoint Online, OneDrive, SaaS-appar etc.) finns i molnet. Det finns inga lokala domänkontrollanter eller behov av certifikat för VPN eller andra lokala tjänster.

HybridFöretag som synkroniserar identiteter mellan lokala Active Directory och Microsoft Entra ID har vanligtvis enheter anslutna till en traditionell domän, Azure AD-anslutna enheter eller hybridenheter, och de vill ha SSO till både lokala resurser (filservrar, äldre applikationer) och molnresurser. Detta är det vanligaste och mest intressanta scenariot när du undrar hur du implementerar Windows Hello i en domän utan att något går sönder.

Lokalt (på plats)Organisationer utan molnidentiteter eller Microsoft Entra ID-applikationer. Allt finns i Active Directory och appar är integrerade med AD eller AD FS. Ändå kan de utnyttja Windows Hello för företag för att ha en lösenordsfri upplevelse och SSO inom själva den lokala miljön.

Den modell du väljer avgör vilka tjänster du behöver (till exempel Microsoft Entra Connect, AD FS, PKI, Kerberos i molnet etc.) och vilken typ av förtroende du kommer att använda för att kommunicera med Active Directory.

Typer av förtroende: hur Windows Hello autentiserar mot domänen

El typ av förtroende Detta definierar hur Windows Hello för företag-klienter autentiserar mot Active Directory. Det är ett viktigt koncept när du vill att användare ska kunna använda en PIN-kod eller ett fingeravtryck på en domänansluten dator för att komma åt lokala resurser.

Viktigt: Denna typ av förtroende gäller endast när det finns Lokal Active DirectoryFör att autentisera med Microsoft Entra ID använder Windows Hello alltid en nyckel (inte ett certifikat), förutom i specifika smartkortsscenarier i federerade miljöer.

De tre typerna av förtroende du kan välja mellan är:

1. Moln Kerberos-förtroende
I den här modellen får användarna sina Active Directory TGT via Microsoft Entra KerberosMicrosoft Entra ID utfärdar ett ärende som lokala domänkontrollanter accepterar, och dessa fortsätter sedan att utfärda Kerberos-tjänstärenden och utföra auktorisering. Detta är samma mekanism som används för inloggning med FIDO2-säkerhetsnycklar.

De viktigaste fördelarna med Kerberos-förtroende i molnet är:

• Du behöver inte distribuera en PKI inte heller röra din befintliga certifikatinfrastruktur.
• Det finns inget behov av att synkronisera publika nycklar mellan Microsoft Entra ID och Active Directory för att användaren ska kunna komma åt lokala resurser, så att det inte finns någon fördröjning mellan Windows Hello-registreringen och möjligheten att autentisera mot domänen.
• Aktiverar logga in med FIDO2-säkerhetsnycklar med en mycket lätt extra konfiguration.

Kerberos-förtroende i molnet kräver dock att du implementerar Microsoft Entra Kerberos och att du uppfyller minimikraven för versioner av Windows och Windows Server (vi kommer att se detta senare i systemkraven).

2. Viktigt förtroende
I det här fallet autentiserar användare mot den lokala Active Directory med hjälp av en nyckel kopplad till enheten skapades under Windows Hello-registreringen. Klienten begär en Kerberos TGT med den nyckeln. För att detta ska fungera krävs vissa certifikat till domänkontrollanter, eftersom Kerberos kommer att använda certifikatbaserad autentisering till domänkontrollanten.

Den här modellen utfärdar inte slutanvändarcertifikat: användaruppgifterna förblir den asymmetriska nyckeln som skyddas av enheten, men kontrollanterna behöver certifikat för att Windows-datorer ska känna igen dem som betrodda enheter.

3. Certifikatförtroende
Här går de ett steg längre: de sänder autentiseringscertifikat för användareUnder registreringen begär användaren ett certifikat med hjälp av en enhetslänkad nyckel (genererad av Windows Hello). Därefter baseras inloggnings- och Kerberos TGT-förfrågningar på det användarcertifikatet, som backas upp av din företags-PKI.

Denna modell kräver en En välstrukturerad företags-PKI och en certifikatregisterutfärdare (CRA). I ​​federerade distributioner fungerar AD FS vanligtvis som CRA. Dessutom måste enhetsåterskrivning vara aktiverad i Microsoft Entra Connect i hybridmiljöer.

Viktig punkt: ingen av dessa förtroendetyper är i sig säkrare än en annan; valet beror på din nuvarande infrastruktur, om du redan har PKI, om du vill lägga till AD FS och hur villig du är att manipulera domänkontrollanter.

PKI-krav enligt modell och typ av förtroende

En av de vanliga frågorna när man pratar om Windows Hello i en domän är om det är nödvändigt konfigurera en komplett PKI För att det ska fungera beror svaret helt på din implementeringsmodell och vilken typ av förtroende som valts:

Kerberos molnförtroende är det enda hybridalternativet som inte kräver certifikatOm du kan byta till den här modellen slipper du distribuera företagscertifikatutfärdare för domänkontrollanter och användare. Detta gör den särskilt attraktiv för miljöer som inte vill hantera PKI.

Å andra sidan, i hybridmodeller baserade på nyckelförtroende eller certifikatförtroende, liksom i rent lokala modeller, behöver du PKI:

• mycket domänkontrollanter Hybrid- och lokala miljöer behöver ett certifikat så att Windows-klienter kan lita på dem när de validerar certifikatbaserad autentisering.
• Om du använder certifikatförtroendeDu behöver en företags-PKI och en certifikatregisterutfärdare (CRA) för att utfärda användarcertifikat. AD FS fungerar som CRA i många distributioner.
• I vissa hybridmiljöer behöver du utfärda VPN-certifikat till användare, om deras åtkomst till lokala resurser går genom tunnlar som är beroende av certifikat.

Om du tvekar att använda domänkontrollanten och din miljö redan är synkroniserad med Microsoft Entra ID är den mest praktiska lösningen vanligtvis att välja Kerberos i molnetvilket förenklar infrastrukturen avsevärt.

Autentisering med Microsoft-inloggnings-ID

Windows Hello för företag används också för att autentisera användaren i Microsoft Access IDOavsett hur du kommunicerar med Active Directory finns det två huvudsakliga alternativ: federerad autentisering (till exempel med AD FS) eller molnautentisering (PHS/PTA).

Beroende på implementeringsmodell och typ av förtroende ställs vissa krav:

• Endast molnMolnautentisering används som standard. Du kan välja federerad autentisering med en tredjeparts-IdP om du vill, men Windows Hello fungerar sömlöst med standardmolnautentisering.
• Hybrid med Kerberos molnförtroende eller nyckelförtroendeDu kan använda synkronisering av lösenordshash (PHS), direktautentisering (PTA) eller federation (AD FS eller andra IdP:er), beroende på din nuvarande design.
• Certifierad hybridKräver federerad autentisering med AD FS; stöder inte PHS eller PTA. AD FS är centralt för detta.

Om din hyresgäst redan är konfigurerad med PHS eller PTA och du inte vill röra AD FS, Kerberos-tillit i molnet Key Trust-modellen passar bättre. Men om du redan använder federation med AD FS för allting kan certifikatförtroende vara ett naturligt val.

Enhetsregistrering enligt modell

Ett annat nyckelblock är enhetsregistreringsom avgör vem som kontrollerar utrustningen för att utfärda tokens och aktivera SSO.

En lokala miljöerServern med AD FS-rollen ansvarar för enhetsregistrering. Den hanterar förtroendeförhållandet med enheterna och utfärdar de tokens som krävs för att Windows Hello för företag ska fungera inom den lokala domänen.

I miljöer hybrid eller endast molnbaseradEnheter måste vara registrerade med ett Microsoft Entra ID, antingen som:

• Microsoft Azure AD anslöt.
• Microsoft ansluter sig till hybrider (hybrid AD-anslutning).
• Microsoft-inloggning för registrerade användare (vanligt i BYOD).

Typen av anslutning avgör vilka funktioner du har: till exempel tillåter hybridenheter SSO till både molnet och lokalt utan att användaren behöver jonglera med olika inloggningsuppgifter.

Flerfaktorsautentisering (MFA) vid provisionering

Ett av huvudmålen med Windows Hello för företag är håll dig borta från lösenord traditionella metoder, vilket ger en stark autentiseringsuppgift som backas upp av säkra enheter. För att uppnå detta kräver provisioneringsprocessen tvåfaktorsautentisering.

Tanken är att svaga inloggningsuppgifter (användarnamn och lösenord) endast används som den första faktorn, medan den andra faktorn tillhandahålls av en MFA-lösningWindows genererar inte Windows Hello för företag-autentiseringsuppgifterna förrän användaren har slutfört MFA:n.

I hybrid- och molnbaserade miljöer kan du använda:

• Microsoft går in i MFA integrerade.
• Tredjeparts MFA-lösningar, antingen som en extern autentiseringsmetod i Microsoft Enter ID eller via en federerad IdP.

I lokala miljöer utan ett Microsoft Entra-ID behöver du ett MFA-alternativ som integreras som AD FS MFA-adapterMicrosoft och andra tillverkare erbjuder specifika adaptrar för detta.

Dessutom kan du justera varumärket i federerade domäner FederatedIdpMfaBehaviorDetta anger för Microsoft Entra ID om MFA:n från den federerade IdP:n ska accepteras, krävas eller avvisas. Denna inställning granskas och ändras med PowerShell-kommandon som Get-MgDomainFederationConfiguration y Update-MgDomainFederationConfiguration.

Policykonfiguration: GPO vs CSP

För att användare ska kunna använda Windows Hello för företag på sina enheter behöver du konfigurera lämpliga policyerDet finns två huvudmekanismer:

• Konfigurationstjänstleverantör (CSP)Idealisk för enheter som hanteras via MDM, till exempel Microsoft Intune. Den låter dig pusha Windows Hello-policyer med hjälp av konfigurationsprofiler och till och med med provisioneringspaket.
• Gruppolicy (GPO)används för domänanslutna datorer som inte hanteras av MDM eller där du föredrar att fortsätta med traditionell lokal hantering.

I alla modeller (endast molnbaserade, hybridbaserade eller lokala) kan du använda CSP, GPO eller en kombination, beroende på hur du hanterar dina enheter. Du kan till exempel hantera domänanslutna bärbara datorer med hjälp av Intune (hybrid) och samtidigt tillämpa en viss baslinjekonfiguration via GPO eller på annat sätt. Säker fjärradministration.

I en klassisk GPO-distribution finns det en Obligatorisk nyckeldirektiv för att aktivera Windows Hello för företag i en nyckelförtroendemodell, och en annan starkt rekommenderad policy:

• Lagrutt: Datorkonfiguration → Administrativa mallar → Windows-komponenter → Windows Hello för företag → Använd Windows Hello för företag (aktiverad).
• Användarsökväg: Användarkonfiguration → Administrativa mallar → Windows-komponenter → Windows Hello för företag → Använd Windows Hello för företag (aktiverat om du vill tvinga fram det per användare).
• Ytterligare: Använd en hårdvarusäkerhetsenhet, för att upprätthålla användningen av TPM och förbättra nyckelskyddet.

Om du tillämpar konfigurationen på Team-noden, alla användare Användare som loggar in på dessa enheter kommer att tvingas försöka registrera sig i Windows Hello för företag. Om du använder det på noden Användare kommer endast de avsedda användarna att se registreringsupplevelsen. Vid konflikt har användarpolicyer företräde framför datorpolicyer.

Grupprincipobjekt (GPO:er) kan länkas till domänen eller specifika organisationsenheter (OU:er), filtreras efter säkerhetsgrupper eller till och med med WMI-filter för att exakt segmentera vilka maskiner som ingår i distributionen. Och utöver dessa grundläggande alternativ finns det ett antal andra funktioner. detaljerade Windows Hello-riktlinjer (till exempel PIN-kodens komplexitet, låsningstid, användning av biometri) som du kan justera enligt ditt företags säkerhetspolicy.

Registreringsprocess och användarupplevelse

Ur användarens synvinkel är installationsprocessen för Windows Hello för företag ganska guidad. Provisioneringen börjar direkt efter att användarprofilen har laddats och innan du ser skrivbordet, förutsatt att alla infrastrukturkrav och policyer är uppfyllda.

Om du vill kontrollera om förhandskontrollerna har godkänts kan du granska användarens enhetsadministratörslogg I Loggboken: Program- och tjänstloggar → Microsoft → Windows. Ett annat alternativ är att använda dsregcmd.exe /status på en konsol för att visa enhetens registreringsstatus och dess relation till Microsoft Enter ID.

Stegen som användaren följer under registreringen är vanligtvis:

1. Om enheten stöder biometrisk autentisering (fingeravtrycksläsare, kompatibel kamera) kommer Windows att uppmana användaren att konfigurera en biometrisk gestDen här gesten låser upp enheten och autentiserar användare med resurser som accepterar Windows Hello för företag. Användaren kan hoppa över det här steget om de föredrar att bara använda en PIN-kod.
2. Windows informerar dig om att det kommer att använda Windows Hello med företagskontot och användaren måste acceptera.
3. Fasen börjar multifaktorautentiseringWindows informerar användaren om att de försöker nå dem via den konfigurerade MFA-metoden (till exempel mobilapp, samtal eller SMS). Etableringen fortsätter inte förrän MFA:n har slutförts, misslyckas eller upphör att gälla. Om MFA:n misslyckas eller upphör att gälla får användaren ett felmeddelande och uppmanas att försöka igen.
4. Efter en lyckad MFA uppmanar systemet användaren att Skapa och validera en PIN-kodDenna PIN-kod måste följa de konfigurerade komplexitetsdirektiven (minimilängd, begränsning av upprepade siffror etc.).
5. Slutligen begär Windows en asymmetriskt nyckelpar För användaren, helst genererad och skyddad inom TPM (eller obligatorisk om det anges i policyn). När nycklarna har genererats registrerar Windows den offentliga nyckeln med IdP:n (Microsoft Entra ID eller AD FS, beroende på modell). När nyckelregistreringen är klar informerar guiden användaren om att de nu kan använda sin PIN-kod eller biometri för att logga in, och användaren stänger provisioneringsappen och öppnar skrivbordet.

Officiell dokumentation innehåller vanligtvis sekvensdiagram och videor som illustrerar dessa steg, inklusive exempel med anpassade MFA-adaptrar för AD FS. Dessa är användbara för att förstå anropen mellan klienten, IdP:n, domänkontrollanterna och MFA-tjänsten.

Nyckelloggning och katalogsynkronisering

Kärnan i Windows Hello för företag är skapande och registrering av det asymmetriska nyckelparetProvisionering genererar en privat nyckel länkad till enheten (vanligtvis lagrad i TPM) och registrerar den offentliga nyckeln hos lämplig identitetsleverantör:

• Molnbaserade modellerDen offentliga nyckeln är registrerad i Microsofts inloggnings-ID.
• HybridmodellerDen registreras också med Microsoft Entra ID; sedan tar Microsoft Entra Connect Sync hand om att synkronisera den publika nyckeln med Active Directory.
• Lokala modellerDen offentliga nyckeln registreras i AD FS, som fungerar som identitetsleverantör för den lokala miljön.

I hybridmodeller synkroniserar Microsoft Entra Connect inte bara användare och enheter, utan även Offentliga Windows Hello-inloggningsuppgiftervilket gör det möjligt för användaren att få SSO mot lokala resurser med hjälp av den starka autentiseringsuppgiften, utan att behöva använda lösenordet igen.

I rent lokala modeller som använder Azure MFA som en flerfaktorlösning kan katalogsynkronisering användas för att importera användare från Active Directory till Azure MFA-servern, som i sin tur kommunicerar med MFA-molntjänsten för att validera den andra faktorn.

operativsystemskrav

När det gäller Windows-versioner kan alla klientversioner som officiellt stöds av Microsoft använda Windows Hello för företagKerberos-förtroende i molnet har dock specifika minimikrav:

• Windows 10 21H2 med uppdatering KB5010415 eller senare.
• Windows 11 21H2 med uppdatering KB5010414 eller senare.

För andra typer av förtroende (nyckel och certifikat) i hybrid- eller lokala modeller, alla klientversioner av Windows som stöds De är giltiga, förutsatt att de får säkerhetsuppdateringar.

När det gäller domänkontrollanter fungerar Windows Hello för företag med alla versioner av Windows Server som fortfarande stöds, men Kerberos-tillit i molnet Den har återigen minimikrav:

• Windows Server 2016 med KB4534307 eller senare.
• Windows Server 2019 med KB4534321 eller senare.
• Windows Server 2022.
• Windows Server 2025.

I vilket fall som helst måste den lägsta funktionella nivån för skog och domän vara Windows Server 2008 R2 Detta gäller alla distributionsmodeller. Om du fortfarande har domäner med äldre funktionsnivåer måste du uppdatera dem innan du överväger en seriös Windows Hello för företag-distribution.

Licens- och molntjänstkrav

När det gäller licenser kräver Windows Hello för företag i sig inte direkt Microsoft Ange ID P1 eller P2Vissa relaterade funktioner (som automatisk MDM-registrering, vissa principer för villkorlig åtkomst eller återskrivning av enheter) kan dock kräva P1/P2-nivåer.

Några viktiga punkter för licensering är:

• Du kan driftsätta Windows Hello för företag med fri nivå Microsofts inloggnings-ID. Alla gratiskonton kan använda Microsofts inloggnings-MFA för lösenordsfria Windows-funktioner.
• Enheter som hanteras via MDM (Intune eller andra) kräver inte P1/P2 bara för att de använder Windows Hello. Utan P1/P2 är dock MDM-registreringen eventuellt inte automatisk och användare måste då registrera manuellt i MDM-lösningen.
• Om du använder modellen för certifikatförtroende I hybrid behöver du minst Microsoft Enter ID P1 för att aktivera funktioner som enhetsåterskrivning och certifikatregistrering via AD FS-registerutfärdaren.
• Om du i lokala miljöer väljer att använda Azure MFA som en multifaktorlösning måste du ha motsvarande Azure MFA-licenser eller paket som inkluderar den.

Sammanfattningsvis: för många implementeringar av denna typ hybrid med Kerberos i molnet eller Key Trust Att ha P1/P2 är inte obligatoriskt, men om du vill dra full nytta av modern hantering, avancerad villkorlig åtkomst och återskrivning av enheter blir dessa prenumerationer relevanta.

Hur passar allt detta in i ett verkligt scenario: hybriduppkopplade surfplattor

I en typisk fältteknikermiljö med hybriduppkopplade Windows-surfplattor är följande vanligtvis fallet:

• Apparaterna är ansluten till domänen och registrerad med Microsofts inloggnings-ID (hybrid AD-koppling).
• Konfigurationen hanteras med Intune, GPO eller en blandning av båda.
• Du vill aktivera Logga in med fingeravtryck eller PIN-kod för att undvika att skriva lösenord på en pekskärm.

I detta sammanhang är det oftast mer lämpligt att välja Kerberos i molnet än för modeller som kräver en fullständig PKI. Du behöver inte "förstöra" något på domänkontrollanterna utöver att installera nödvändiga patchar och konfigurera Microsoft Entra Kerberos, och du undviker att fastna i användarcertifikat och CRA.

Om du redan har skapat en konfigurationsprofil i Intune för att aktivera Windows Hello och du ser att systemet erbjuder att konfigurera en PIN-kod eller biometri, men sedan visas felet "Deras referenser kunde inte verifieras" När du försöker använda Windows Hello kommer du troligtvis att:

• Har inte Betrodd backend slutförd (Kerberos i molnet/nyckel/certifikat) för att kommunicera med domänen.
• Eller så fungerar inte konfigurationen korrekt hybrid implementeringsmodell enligt de officiella riktlinjerna (till exempel den specifika guiden för Kerberos-förtroende i hybridmoln).

Den globala inställningen från ”Registrera enheter → Windows-registrering” i Intune aktiverar Windows Hello på klientnivå, men ersätter inte De underliggande infrastrukturkraven (förtroendetyp, Microsoft Entra Kerberos, katalogsynkronisering etc.) är också en faktor. Detta förklarar varför du ser guiden på klientsidan, men serversidan misslyckas vid validering av autentiseringsuppgifter.

Det kloka att göra i dessa fall är att steg för steg granska dokumentationen för Windows Hello för företagsdistribution och dess hybridisering med Kerberos i molnet, och se till att enheterna verkar korrekt registrerade (via dsregcmd /status), att Microsoft Entra Kerberos har konfigurerats i rätt skog och att principerna (CSP/GPO) tillämpas på rätt användare och datorer.

Med alla dessa delar korrekt sammanställda – en tydlig distributionsmodell, rätt förtroendetyp, fungerande MFA, korrekt enhets- och nyckelregistrering och väl tillämpade policyer – slutar Windows Hello för företag att vara ett "krångel att konfigurera" och blir ett ganska bekvämt sätt för dina användare att logga in på domänen. PIN-kod, fingeravtryck eller ansikte istället för att lida med oändliga lösenord på pekskärmstangentbord.