Windows Hello Vállalatoknak, hardverkulcsok és egyszeri bejelentkezés

Ha Microsoft-környezetekben kezel identitásokat, valószínűleg hallott már a következőről: Windows Hello, Windows Hello Vállalati verzió, kulcsok hardver és egyszeri bejelentkezésDe könnyű elveszni a sok betűszó, bizalmi típus és követelmény között. Továbbá, a hagyományos Active Directoryt használó hibrid telepítéseknél a WHfB valódi kínálatának megértése egy egyszerű PIN-kódos vagy biometrikus bejelentkezéshez képest jelentheti a különbséget a zökkenőmentes projekt... és az állandó fejfájás között.

Ebben a cikkben részletesen bemutatjuk, hogyan működik Windows Hello for Business (WHfB), mi a szerepe a hardverkulcsoknak, hogyan valósul meg az egyszeri bejelentkezés (SSO)? és miben különbözik az otthoni felhasználók számára készült „normál” Windows Hello-tól. Megvizsgáljuk a belső fázisokat (eszközregisztráció, kiépítés, kulcsszinkronizálás, tanúsítványok és hitelesítés), a telepítési modelleket (csak felhőalapú, hibrid és helyszíni), a megbízhatósági típusokat, a PKI-követelményeket, a licencelést, a valós telepítési kihívásokat, és azt, hogy mindez hogyan illeszkedik a modern megközelítésekhez, mint például a FIDO2 és a jelszó nélküli biztonság.

Windows Hello vs. Windows Hello for Business: Mi változik igazán?

A Windows Hello (egyszerűen fogalmazva) a PIN-kóddal vagy biometrikus adatokkal történő bejelentkezés felhasználói felülete. Windowsos eszközön, otthoni és professzionális környezetbe egyaránt tervezve. A Windows Hello for Business (WHfB) ezzel szemben egy vállalati szintű kiterjesztés, amely erős identitáskezelési képességeket biztosít az Active Directory és a Microsoft Entra ID integrálásával.

Mindkét módszerrel használhatod PIN-kód, ujjlenyomat vagy arcfelismerés támogatása TPM a számítógépre való bejelentkezéshez. Akár egy klasszikus helyi domainhez is hitelesítheti magát. A nagy különbség az, hogy a WHfB létrehozza és kezeli a vállalati szintű kriptográfiai hitelesítő adatokA felhasználóhoz és az eszközhöz kapcsolt kulcspárok vagy tanúsítványok, amelyeket szabályzatok kezelnek, és amelyek helyi és felhőalapú erőforrásokon egyszeri bejelentkezéshez használhatók.

Míg a „normál” Windows Hello lényegében a következőkre korlátozódik: cserélje ki a jelszót egy kényelmes gesztussal az adott eszközönA WHfB egy erős hitelesítő adatot generál, amelyet az identitásszolgáltató (AD, Microsoft Entra ID vagy AD FS) felismer, tárol és hozzáférési tokenek kibocsátására és a biztonság érvényesítésére használ. Feltételes hozzáférés, szigorú KDC-érvényesítés, PRT, Kerberos a felhőben és egyéb speciális vezérlők.

A logikus kérdés a következő: ha már vannak tartományhoz csatlakoztatott eszközeim, amelyeket Intune-nal kezelek, TPM-mel és biometrikus azonosítással, valamint egyszeri bejelentkezéssel a felhőbe jelszó-hash szinkronizáláson keresztül, Pontosan mit nyerek a WHfB hozzáadásával? A válasz abban rejlik, hogyan épülnek fel és érvényesítik a kulcsokat, hogyan van összekapcsolva az eszköz, és abban, hogy ezt a biztonságot ki lehessen terjeszteni az egész ökoszisztémára, ne csak a helyi bejelentkezésre.

Alaparchitektúra: Windows Hello for Business fázisok

A WHfB egy elosztott rendszer, amely több komponensre támaszkodik: eszköz, TPM, identitásszolgáltató, PKI, címtár-szinkronizálás és SSO mechanizmusokAhhoz, hogy megértsük anélkül, hogy eltévednénk, hasznos a működését öt kronológiai megvalósítási szakaszra osztani.

1. Eszközregisztráció

A kirakós első darabja a eszközregisztráció az identitásszolgáltatónál (IdP)Ez a lépés lehetővé teszi az eszköz társítását egy identitással a címtárban, és az automatikus hitelesítés engedélyezését, amikor egy felhasználó bejelentkezik.

Kizárólag felhőalapú vagy hibrid környezetekben Az IdP a Microsoft Enter ID. és az eszköz regisztrálja magát az eszközregisztrációs szolgáltatásával (csatlakozva a Microsoft Entra-hoz, hibrid csatlakozással vagy regisztrálva). Tisztán helyi forgatókönyvek esetén az IdP jellemzően AD FS a vállalati eszközregisztrációs szolgáltatásával.

A regisztráció befejezését követően az IdP hozzárendeli a csapatot a következőhöz: egy egyedi azonosító, amelyet az eszköz-könyvtár bizalom létrehozásához fognak használni egymást követő hitelesítések során. Ez a rekord az „eszközcsatlakozás típusa” szerint van besorolva, amely meghatározza, hogy az eszköz helyi tartományhoz, Entra ID-hez, hibridhez vagy egyszerűen személyesként van-e regisztrálva.

2. Kiépítés: a Windows Hello konténer létrehozása

Miután az eszköz regisztrálva lett, megkezdődik a fázis Windows Hello hitelesítő adatok kiépítése vállalkozások számáraItt jön létre az úgynevezett Windows Hello konténer, amely logikailag csoportosítja a felhasználó összes kriptográfiai anyagát az adott számítógépen.

A tipikus beszerzési folyamat a következő fő lépéseket követi, mindig egy kezdeti hitelesítés gyenge hitelesítő adatokkal (felhasználónév és jelszó):

• A felhasználó MFA-val hitelesíti magát az IdP-nél. (Microsoft Enter MFA vagy más kompatibilis módszer, vagy egy MFA-adapter az AD FS-ben helyi környezetekben).
• Miután leküzdötted ezt a második tényezőt, a rendszer felkér egy konfigurálására. PIN-kód és ha kompatibilis hardver áll rendelkezésre, biometrikus gesztus (lábnyom, arc, írisz).
• A PIN-kód megerősítése után a Windows létrehozza a Windows Hello konténer az adott fiókhoz abban a csapatban.
• A tartályon belül egy kriptográfiai kulcspár (nyilvános és privát), amennyiben létezik TPM, ahhoz kapcsolódik, vagy ennek hiányában szoftveresen védett.
• La A privát kulcs az eszközön marad, és nem exportálható., továbbra is védve a TPM és a PIN/biometrikus védőeszközök által.
• La a nyilvános kulcs regisztrálva van az IdP-ben és a felhasználói objektumhoz van csatolva: a Microsoft bejelentkezési azonosítóban a felhasználóhoz kerül, összevont helyi forgatókönyvekben pedig az AD FS átviszi az Active Directoryba.

A tartály tartalmaz még egy adminisztrátori kulcsEz olyan esetekben hasznos, mint például a PIN-kód visszaállítása; a TPM-mel rendelkező eszközökön a TPM-tanúsítványokat tartalmazó adatblokk is tárolásra kerül. Az összes anyag csak akkor oldódik fel, amikor a felhasználó végrehajtja a gesztust (PIN-kód vagy biometrikus adatok), és ez a kezdeti MFA-kombináció bizalmi kapcsolatot létesít a felhasználó, az eszköz és az IdP között.

3. A konténeren belüli kulcsok: hitelesítés és felhasználói azonosító

A Windows Hello konténerben többféle kulcsot találunk, különböző szerepekkel, mindegyik PIN-kódos vagy biometrikus védelemmel titkosítva:

• Hitelesítési kulcsA regisztráció során generált aszimmetrikus kulcspár, amelyet mindig PIN-kóddal vagy biometrikus gesztussal kell feloldani. Ez az alapja annak, hogy más anyagokat újrahasznosítanak a PIN-kód módosításakor.
• Felhasználói azonosító kulcsokAz azonosítókulcsok lehetnek szimmetrikusak vagy aszimmetrikusak az identitásszolgáltatótól (IdP) és a modelltől (kulcs vagy tanúsítvány) függően. Ezeket az identitásszolgáltatónak címzett kérések és tokenek aláírására vagy titkosítására használják. Vállalati környezetekben jellemzően aszimmetrikus kulcspárokként generálják őket, a nyilvános kulcsot pedig az IdP regisztrálja.

Ezek a felhasználói azonosító kulcsok két fő módon szerezhetők be: a vállalati PKI-hoz kapcsolódó tanúsítványok kiadása (például azért, mert VPN, RDP vagy tanúsítványalapú Kerberos hitelesítés), vagy közvetlenül az IdP által generálva PKI nélküli forgatókönyvekben (tiszta kulcsmodell).

Ugyanez az infrastruktúra lehetővé teszi a következők használatát: Windows Hello FIDO2/WebAuthn hitelesítőként kompatibilis alkalmazásokban és webhelyeken. A webhelyek létrehozhatnak FIDO hitelesítő adatokat a Windows Hello konténeren belül; a későbbi látogatások során a felhasználó PIN-kódjával vagy biometrikus adataival hitelesíti magát jelszavai felfedése nélkül.

4. Kulcsszinkronizálás hibrid környezetekben

Hibrid architektúrákban, ahol együtt léteznek Microsoft bejelentkezési azonosító és Active DirectoryA kulcs felhőben történő egyszerű regisztrálása nem elég. A kiépítés után a WHfB nyilvános kulcsot szinkronizálni kell a helyi könyvtárral a működés engedélyezéséhez. hitelesítés és egyszeri bejelentkezés helyszíni erőforrásokon.

Ezekben az esetekben a Microsoft Entra Connect Sync gondoskodik a következőkről: másolja a nyilvános kulcsot az msDS-KeyCredentialLink attribútumba a felhasználói objektum Active Directory-ban. Ez a szinkronizálás kulcsfontosságú ahhoz, hogy a tartományvezérlő érvényesíteni tudja az eszköz által generált aláírásokat a TPM-ben tárolt privát kulccsal.

5. Tanúsítványok regisztrációja (csak szükség esetén)

Néhány modellben (mint például a tanúsítvány bizalmaA kulcsok mellett a szervezetnek hitelesítési tanúsítványokat is ki kell adnia a felhasználóknak. Ebben az esetben egy további fázis aktiválódik. tanúsítványok regisztrációja.

A nyilvános kulcs regisztrálása után a kliens létrehoz egy tanúsítványkérés amely elküldi a kérést a tanúsítvány-nyilvántartó hatóságnak, amely jellemzően az AD FS-be van integrálva az összevont telepítésekben. Ez a tanúsítvány-nyilvántartó hatóság a vállalati PKI és a tanúsítvány-nyilvántartó hatóság segítségével érvényesíti a kérést. Kibocsát egy tanúsítványt, amely a Hello konténerben tárolódik., újrafelhasználható hitelesítéshez helyi erőforrásokon, amelyek továbbra is tanúsítványokra támaszkodnak.

Hitelesítés, privát kulcs és egyszeri bejelentkezés: hogyan illeszkednek egymáshoz

Miután a regisztráció és a kiépítési fázisok befejeződtek, a felhasználó mindennapi élete valami nagyon egyszerűre redukálódik: egy gesztus (PIN-kód vagy biometrikus azonosítás), amely „felszabadítja” az eszközön lévő privát kulcsotAz érdekes az, ami a színfalak mögött történik.

Amikor a felhasználó feloldja a számítógép zárolását, a Windows a WHfB hitelesítő adatok privát részét használja a következőhöz: kriptográfiailag aláírja az IdP-nek küldött adatokatEz a felhasználói objektumban tárolt nyilvános kulcs segítségével ellenőrzi az aláírást. Mivel a PIN-kód és a privát kulcs sem hagyja el az eszközt, a folyamat ellenáll az adathalászatnak és a hagyományos hitelesítőadat-lopásnak.

Microsoft Enter ID esetén a hitelesítés elvégzése a következőt eredményezi: Elsődleges frissítési token (PRT)Egy JSON webes token, amely felhasználói és eszközadatokat tartalmaz. Ez az alapja az egyszeri bejelentkezésnek a felhőalkalmazások felé, és – a Microsoft Kerberosszal vagy kulcsszinkronizációval kombinálva – a helyi erőforrások felé is.

PRT nélkül, még akkor is, ha a felhasználó rendelkezik érvényes WHfB hitelesítő adatokkal, Elveszíteném az egyszeri bejelentkezést. és minden alkalmazásban folyamatosan hitelesíteni kellene magát. Ezért a feltételes hozzáférési szabályzatok, legyenek azok eszközalapúak vagy kockázatalapúak, általában figyelembe veszik az adott PRT meglétét és érvényességét.

Az Active Directory esetében, kulcs- vagy tanúsítványbizalom használatakor a WHfB a következőképpen működik: virtuális intelligens kártyaA felhasználó aláír egy nonce-t vagy kihívást a KDC-től, a tartományvezérlő érvényesíti a tanúsítványt vagy kulcsot, és kiad egy Kerberos TGT jegyet, így lehetővé téve az egyszeri bejelentkezést a Kerberossal integrált helyi szolgáltatásokhoz.

Belső biztonság: biometria, TPM és támadások elleni védelem

A WhfB egyik pillére az, hogy a A biometrikus adatok sosem hagyják el az eszköztA szenzorok által generált sablonok helyben tárolódnak a adatbázisok titkosítva (például a C:\WINDOWS\System32\WinBioDatabase elérési úton) adatbázisonként egyedi kulcsokkal, CBC módú AES titkosítással és SHA-256 hash függvényként védve.

Ez azt jelenti, hogy még ha egy támadó hozzáférne is ezekhez a fájlokhoz, Nem tudtam rekonstruálni a felhasználó arcának vagy ujjlenyomatának képét.és nem is használhatók más eszközön. Továbbá minden érzékelő saját tárolóhellyel rendelkezik, ami csökkenti a biometrikus sablonok egyetlen központi lopási pontról történő ellopásának lehetőségét.

A Windows Hello for Business PIN-kódja jobban védett, mint egy hagyományos jelszó. Nem utazik a hálózaton, helyben érvényesül, és a TPM érvényesíti a biztonsági intézkedéseket. túl sok helytelen kísérlet miatti blokkolásEzáltal a nyers erővel vagy szótáras támadások hatástalanok. És ha valaki ellopja a PIN-kódot, az csak az adott eszközön fog működni, mivel a hitelesítő adat a hardverhez van kötve.

A modern fenyegetésekkel szembenézve (Hogyan állapítható meg, hogy egy e-mail adathalász-e(jelszó-újrafelhasználás, tömeges hitelesítő adatok ellopása), a WHfB a következőkre támaszkodik Eszközhöz kötött nyilvános kulcsú titkosításEz tervezésileg elkerüli a megosztott titkok felfedését. Ez tökéletesen összhangban van az olyan szabályozások szabványaival és ajánlásaival, mint például a NIST 800-63B, valamint a zéró bizalomú biztonsági modellekkel.

Telepítési modellek: felhő, hibrid és helyszíni

A WHfB topológia szempontjából rugalmas, de ez a rugalmasság bizonyos bonyolultsággal jár. Általánosságban elmondható, hogy három telepítési modellről beszélhetünk, amelyek különböző módon kombinálódnak. Microsoft Entra ID, Active Directory, PKI és összevonás.

Csak felhőalapú modell

Azokban a szervezetekben, amelyek szinte 100%-ban élnek Microsoft 365 és más SaaS szolgáltatások, releváns helyi infrastruktúra nélkül, a legegyszerűbb modell a következő: Csak felhőalapú, a Microsofthoz csatlakoztatott eszközökkel. BejelentkezésEbben a forgatókönyvben:

• Minden felhasználó és eszköz a következő helyen található: Microsoft Access ID.
• Az eszköz és a kulcs regisztrációja közvetlenül a felhőben történik.
• Nincs szükség vállalati PKI-ra sem tartományvezérlői tanúsítványok.
• Az SSO a PRT és a Microsoft Entra alkalmazásokhoz használt tokeneken alapul.

Ez a legközvetlenebb megoldás a felhőalapú megoldásokat kínáló vállalatok számára, alacsony infrastrukturális költség és viszonylag egyszerű telepítés, ideális, ha a helyszíni erőforrások nem állnak rendelkezésre, vagy minimálisak.

Hibrid modell: a leggyakoribb eset

A vállalatok túlnyomó többsége valahol a kettő között helyezkedik el: A korábbi Active Directory és a Microsoft bejelentkezési azonosító szinkronizálvaA WHfB itt ragyog, de itt a leggyakoribbak a konfigurációs problémák is, ha nem jól tervezik meg.

Hibrid környezetben az identitások szinkronizálása a Microsoft Entra Connect Sync segítségével történik, és ennek számos lehetséges kombinációja létezik. telepítési modell (hibrid) és a bizalom típusa (felhőalapú Kerberos, kulcs vagy tanúsítvány)A cél általában a következők felajánlása:

• Egyszeri bejelentkezés felhőszolgáltatásokba (SharePoint Online, Teams, OIDC/SAML alkalmazások).
• Átlátható hozzáférés a helyi erőforrásokhoz (részvények, alkalmazások Kerberos, VPN, RDP).
• Jelszavak fokozatos kilépési útvonala, a régi alkalmazások megőrzése mellett.

A hibrid forgatókönyvekben a bizalom főbb típusai a következők:

• Kerberos a felhőbenA Microsoft Entra Kerberos TGT-ket bocsát ki az Active Directory számára további nyilvános kulcsú infrastruktúra (PKI) igénylése nélkül. Ez a legmodernebb és legegyszerűbb hibrid modell, mivel kihasználja a meglévő FIDO2 infrastruktúrát, és nem igényli a nyilvános kulcsok szinkronizálását az Active Directoryval.
• Kulcsfontosságú bizalomA felhasználók eszközhöz kötött kulccsal hitelesítik magukat az Active Directoryban; a tartományvezérlőkhöz speciális tanúsítványokra van szükség. A PKI a tartományvezérlőkhöz szükséges, de a felhasználói tanúsítványokhoz nem.
• Tanúsítvány megbízhatóságaA felhasználói hitelesítési tanúsítványok kibocsátása és használata Kerberos TGT-k beszerzésére szolgál. Ehhez teljes PKI, AD FS CRA-ként és intenzívebb konfiguráció szükséges.

A megfelelő bizalomtípus kiválasztása kulcsfontosságú: egyik sem eredendően „biztonságosabb”Azonban költségükben, összetettségükben és infrastrukturális követelményeikben különböznek. Az új telepítésekhez gyakran a Kerberos használata a felhőben a legjobb megoldás, feltéve, hogy a kliens és a szerver Windows verziói megfelelnek a minimális követelményeknek.

Tisztán lokális modell

Az erős szabályozási korlátozásokkal rendelkező, vagy kevés vagy semmilyen felhőalapú megoldást nem alkalmazó szervezetek választhatják a WHfB telepítést. 100%-ban helyi, az Active Directory és az AD FS támogatásávalEbben a modellben:

• Az eszközregisztráció kezelése AD FS.
• A hitelesítés lehet kulcs- vagy tanúsítványalapú, de mindig mögötte áll egy vállalati PKI.
• Az MFA-lehetőségek közé tartoznak az AD FS adapterei vagy olyan megoldások, mint az Azure MFA Server (már örökölt), a helyszíni környezetbe integrálva.

Ez a megközelítés egy teljes ellenőrzés a hitelesítési adatok felettEz azonban jelentős karbantartási erőfeszítést igényel (PKI, AD FS, a nem tartományhoz csatlakoztatott számítógépek által elérhető CRL-ek közzététele stb.), amit nem minden szervezet hajlandó hosszú távon vállalni.

Hozzáférhető PKI, tartományvezérlői tanúsítványok és CRL-ek

A tanúsítványokra támaszkodó modellekben (legyen szó felhasználókról, tartományvezérlőkről vagy mindkettőről) a PKI válik a bizalom középpontjává. A WHfB megköveteli a KDC-k szigorú validálása amikor egy Microsoft Enterhez csatlakoztatott eszköz helyi tartományon keresztül hitelesíti magát.

A gyakorlatban ez azt jelenti, hogy a tartományvezérlő tanúsítványának számos technikai feltételnek kell megfelelnie: egy megbízható legfelső szintű hitelesítésszolgáltató által kiállított hitelesítési tanúsítvány az eszközhöz, Kerberos hitelesítési sablon alapján, „KDC hitelesítés” EKU-val, helyes DNS-névvel, RSA 2048 és SHA-256 aláírási algoritmussaltöbbek között a követelményeket.

Továbbá elengedhetetlen, hogy a készülék képes legyen ellenőrizze a tanúsítványok visszavonásátItt rejlik a CRL-ek klasszikus problémája: egy csak a Microsoft Entrához csatlakoztatott eszköz nem tudja olvasni az Active Directory LDAP-útvonalait, ha még nem hitelesítették, ezért közzé kell tenni a CRL terjesztési pontját a egy hitelesítés nélkül elérhető HTTP URL.

Ez magában foglalja egy webkiszolgáló (például IIS) előkészítését, egy virtuális könyvtár (cdp) létrehozását és az engedélyek módosítását. NTFS és a megosztott erőforrásokból tiltsa le a tárolás Offline gyorsítótárazáshoz konfigurálja a hitelesítésszolgáltatót úgy, hogy közzétegye a CRL-t az adott megosztott erőforráson, és HTTP-n keresztül elérhetővé tegye. Ha ezzel elkészült, a következőket kell tennie: Tartományvezérlői tanúsítványok megújítása az új CDP belefoglalása és annak biztosítása, hogy a vállalati főtanúsítvány telepítve legyen a Microsoft Entrához csatlakoztatott eszközökre (például Intune-nal és egy „megbízható tanúsítvány” profillal).

Címtár-szinkronizálás, MFA és eszközkonfiguráció

A Windows Hello for Business végfelhasználói élménye nagymértékben függ a következőktől: A címtár-szinkronizálás, az MFA és a házirend-konfiguráció integrálása.

Hibrid telepítésekben a Microsoft Entra Connect Sync nemcsak a fiókokat szinkronizálja, hanem a következőket is képes szinkronizálni: kritikus attribútumok, mint például az msDS-KeyCredentialLinkamely tartalmazza az AD-ben történő hitelesítéshez szükséges WHfB nyilvános kulcsot. Helyszíni környezetekben az Azure MFA-kiszolgálóval a szinkronizálás segítségével importálhatók a felhasználók az MFA-kiszolgálóra, amely ezután lekérdezi a felhőszolgáltatást ellenőrzés céljából.

A többtényezős hitelesítéssel kapcsolatban a szervezeteknek számos lehetőségük van: Microsoft Entra MFA felhőalapú vagy hibrid forgatókönyvekhezKülső hitelesítésen keresztül integrált külső metódusok az Entra ID-ben vagy összevonáson keresztül, valamint harmadik féltől származó MFA-adapterek az AD FS-hez helyszíni környezetekben. A FederatedIdpMfaBehavior jelző az összevont tartományokban meghatározza, hogy az Entra ID elfogadja, megköveteli vagy figyelmen kívül hagyja-e az összevont IdP által végrehajtott MFA-t, ami kritikus fontosságú lehet a WHfB-kiépítés megfelelő működéséhez.

A WHfB konfiguráció a berendezésen a következőképpen végezhető el: csoportházirend (GPO) vagy CSP MDM-en keresztül (például Intune). A modern szervezetekben gyakori, hogy engedélyezik az automatikus WHfB regisztrációt, kikényszerítik az MFA-t az első bejelentkezéskor, meghatározzák a PIN-kód bonyolultsági szabályzatait, és szabályozzák, hogy mely biometrikus módszerek legyenek elfogadottak (csak tanúsított érzékelők, IR-kamerák stb.).

Ezzel párhuzamosan elengedhetetlen a felépülési tapasztalatok figyelembevétele: önkiszolgáló PIN-kód-visszaállítás, alternatív módszerek, például FIDO2-kulcsok, és BitLocker titkosítás az inaktív adatok védelme érdekében, ha az eszköz elveszik vagy ellopják.

Licencek, rendszerkövetelmények és gyakorlati korlátok

Az egyik gyakori tévhit, hogy mindig WhfB-t kell használni. Microsoft Enter ID P1 vagy P2A valóságban a WHfB alapvető funkciói elérhetők az ingyenes Entra ID szinttel, és a jelszó nélküli kiépítéshez szükséges többtényezős hitelesítés prémium licencek nélkül is engedélyezhető, bár az olyan funkciók, mint az automatikus MDM-regisztráció, a fejlett feltételes hozzáférés vagy a halasztott eszközátírás magasabb szinteket igényelnek.

Operációs rendszer tekintetében gyakorlatilag az összes modern Windows kliens verzió támogatja a WHfB-t, de a A felhőben a Kerberosba vetett bizalomhoz konkrét minimumok szükségesek. (például a Windows 10 21H2 bizonyos javításokkal vagy a Windows 10 21H2 bizonyos verzióival) A windows 11A szerveroldalon a Windows Server bármely támogatott verziója általában tartományvezérlőként működhet, bár a felhőben lévő Kerberos részhez meghatározott verziók és frissítések szükségesek a tartományvezérlőkön.

A technikai szempontokon túl nagyon gyakorlati kihívások is vannak: közös felszerelés, ahol Mivel a WHfB eszköz- és felhasználóspecifikus, rendszeresen illeszkedik.; TPM 2.0 vagy biometrikus érzékelők nélküli hardverek; vagy olyan környezetek, ahol a régi flották megújításának, a PKI telepítésének és a 2012-es tartományvezérlők frissítésének költségei rövid távon nem teszik vonzóvá a teljes WHfB-elterjedést.

Bizonyos esetekben az ésszerű út magában foglalja kombinálja a WHfB-t más jelszó nélküli tényezőkkel (FIDO2 kulcsok, intelligens kártyák, telefonos hitelesítés) a megosztott munkaállomások, a nem Windows platformok vagy a nagy mobilitású felhasználók lefedésére, így a WHfB marad az elsődleges hitelesítő hordozható az Entrához vagy hibridekhez kapcsolódó vállalatok.

Összességében a Windows Hello üzleti verziója sokkal többet kínál, mint egy „szép PIN-kódot”: bemutatja a következőket: hardverhez kötött aszimmetrikus hitelesítő adatok, szigorú KDC-ellenőrzés, mély integráció a Microsoft Entra ID-vel és az Active Directory-val, valamint egy robusztus keretrendszer a biztonságos egyszeri bejelentkezéshez mind a felhőben, mind a helyszínen. Az alapvető Windows Hello-hoz képest azonban a valódi értéke a kiindulóponttól függ: a modern, felhőalapú vagy hibrid környezetekben, frissített PKI-val és DC-vel, a biztonság és a felügyelet terén elért ugrás egyértelműen meghaladja az erőfeszítést; a nagyon régi területeken, kevés előkészített infrastruktúrával és modernizációs tervek nélkül, ésszerűbb lehet először a hardver, a PKI és a hozzáférés-vezérlés terén előrelépni, mielőtt a WHfB teljes potenciálját kiaknáznánk.

Kapcsolódó cikk:

Hogyan tudhatod, hogy mely alkalmazások férhetnek hozzá a kamerádhoz, mikrofonodhoz vagy tartózkodási helyedhez a Windows 11 rendszerben?

Izsák

Szenvedélyes író a bájtok és általában a technológia világáról. Szeretem megosztani tudásomat írásban, és ezt fogom tenni ebben a blogban, megmutatom a legérdekesebb dolgokat a kütyükről, szoftverekről, hardverekről, technológiai trendekről stb. Célom, hogy egyszerű és szórakoztató módon segítsek eligazodni a digitális világban.