Kako implementirati Windows Hello za poslovanje u hibridnom domenu

Ako imate terenske tehničare ili korisnike s laptopima i tabletima koji stalno koriste ekrane osjetljive na dodir, vjerovatno su umorni od stalnog kucanja lozinki. Windows Hello for Business je kreiran upravo u tu svrhu: da zamijeni lozinke praktičnijim i sigurnijim metodama prijave, kao što su PIN-ovi, otisci prstiju ili prepoznavanje lica, uz održavanje integracije s vašom domenom i Microsoft Entra ID-om (ranije Azure AD).

Problem je što kada počnete čitati službenu dokumentaciju, pojavljuju se koncepti poput modela implementacije, tipova povjerenja, Kerberosa u oblaku, PKI-a, AD FS-a, MFA-a, sinhronizacije ključeva i tako dalje , te je lako postati preopterećen, posebno ako se ne želite previše petljati s kontrolerima domena. U ovom vodiču ćemo sve to smireno razložiti, objašnjavajući šta vam je zaista potrebno za implementaciju Windows Hello-a u okruženju domena (uključujući hibridno) i koje dijelove možete zanemariti ovisno o vašem stvarnom scenariju.

Šta je Windows Hello za preduzeća i po čemu se razlikuje od "normalnog" Windows Hello-a?

Windows Hello za tvrtke je poslovna verzija sustava Windows Hello koja zamjenjuje lozinke javnim ključem za prijavu povezanim s uređajem . Ne služi samo za otključavanje računala: koristi se i za autentifikaciju pomoću Active Directoryja i/ili Microsoft Entra ID-a.

U praksi, korisnik se prijavljuje pomoću PIN-a, otiska prsta ili prepoznavanja lica , ali ispod, Windows koristi par asimetričnih ključeva pohranjenih i zaštićenih na uređaju (po mogućnosti u TPM-u) za autentifikaciju kod provajdera identiteta (IdP): to može biti samo Microsoft Entra ID, hibridno okruženje ili čisto lokalno okruženje s AD FS-om.

Privatni ključ nikada ne napušta računar; javni ključ se registruje sa Microsoft Entra ID-om ili AD FS-om tokom registracije. Odatle, korisnik može izvršiti SSO na resursima u oblaku i/ili lokalnim resursima, ovisno o modelu implementacije koji odaberete.

Modeli implementacije Windows Hello-a za preduzeća

Prije izmjene GPO-a ili Intune-a, važno je razumjeti koji model implementacije najbolje odgovara vašem okruženju. Windows Hello for Business razlikuje tri glavna scenarija, ovisno o tome gdje se nalaze identiteti i resursi:

Samo u oblaku : Organizacije koje imaju samo Microsoft Entra ID identitete i ne pristupaju lokalnim resursima. Uređaji se pridružuju Microsoft Entri (pridruživanje Azure AD-u) ili registruju, a sve što korisniku treba (SharePoint Online, OneDrive, SaaS aplikacije itd.) nalazi se u oblaku. Nema lokalnih kontrolera domena niti potrebe za certifikatima za VPN-ove ili druge lokalne usluge.

Hibridno : Kompanije koje sinhronizuju identitete između lokalnog Active Directoryja i Microsoft Entra ID-a. Obično imaju uređaje povezane s tradicionalnom domenom, uređaje povezane s Azure AD-om ili hibridne uređaje, i žele SSO i za lokalne resurse (datotečne servere, naslijeđene aplikacije) i za resurse u oblaku. Ovo je najčešći i najzanimljiviji scenario kada se pitate kako implementirati Windows Hello u domenu bez ikakvog oštećenja.

Lokalno : Organizacije bez cloud identiteta ili Microsoft Entra ID aplikacija. Sve se nalazi u Active Directoryju, a aplikacije su integrirane s AD-om ili AD FS-om. Međutim, mogu iskoristiti Windows Hello for Business za iskustvo jedinstvene prijave (SSO) bez lozinke unutar svog lokalnog okruženja.

Model koji odaberete određuje koje usluge su vam potrebne (na primjer, Microsoft Entra Connect, AD FS, PKI, Kerberos u oblaku itd.) i koju vrstu povjerenja ćete koristiti za komunikaciju s Active Directoryjem.

Vrste povjerenja: kako Windows Hello vrši autentifikaciju na domeni

Vrsta povjerenja definira kako se klijenti Windows Hello for Business autentificiraju u Active Directory. To je ključni koncept kada želite da korisnici mogu koristiti PIN ili otisak prsta na računaru pridruženom domeni za pristup lokalnim resursima.

Važno: Ova vrsta povjerenja primjenjuje se samo kada postoji lokalni Active Directory . Za autentifikaciju pomoću Microsoft Entra ID-a, Windows Hello uvijek koristi ključ (ne certifikat), osim u određenim scenarijima pametnih kartica u federiranim okruženjima.

Tri vrste trustova koje možete odabrati su:

1. Povjerenje u Cloud Kerberos
U ovom modelu, korisnici dobijaju svoj Active Directory TGT putem Microsoft uvodi KerberosMicrosoft Entra ID izdaje kartu koju prihvataju lokalni kontroleri domene, a oni zatim nastavljaju izdavati Kerberos servisne karte i vršiti autorizaciju. Ovo je isti mehanizam koji se koristi za prijavu sa FIDO2 sigurnosnim ključevima.

Ključne prednosti Kerberos povjerenja u oblaku su:

• Ne morate implementirati PKI niti dirati vašu postojeću infrastrukturu certifikata.
• Nema potrebe za sinhronizacijom javnih ključeva između Microsoft Entra ID-a i Active Directoryja kako bi korisnik mogao pristupiti lokalnim resursima, tako da nema kašnjenja između registracije za Windows Hello i mogućnosti autentifikacije na domeni.
• Omogućava prijava sa FIDO2 sigurnosnim ključevima sa vrlo laganom dodatnom konfiguracijom.

Međutim, Kerberos cloud trust zahtijeva da implementirate Microsoft Enter Kerberos i ispunite minimalne verzije Windowsa i Windows Servera (ovo ćemo vidjeti kasnije u sistemskim zahtjevima).

2. Ključno povjerenje
U ovom slučaju, korisnici se autentificiraju u lokalnom Active Directoryju koristeći ključ povezan s uređajem kreirano tokom registracije za Windows Hello. Klijent zahtijeva Kerberos TGT koristeći taj ključ. Da bi ovo funkcionisalo, određeni certifikati za kontrolere domena, budući da će Kerberos koristiti autentifikaciju zasnovanu na certifikatu za kontroler domena.

Ovaj model ne izdaje certifikate krajnjeg korisnika: korisnički akreditiv ostaje asimetrični ključ zaštićen uređajem, ali kontrolerima domena potrebni su certifikati za Windows računare kako bi ih prepoznali kao pouzdane entitete.

3. Pouzdanost certifikata
Ovdje idu korak dalje: emitiraju certifikati za autentifikaciju korisnikaTokom registracije, korisnik zahtijeva certifikat koristeći ključ povezan s uređajem (generiran od strane Windows Hello-a). Nakon toga, zahtjevi za prijavu i Kerberos TGT se zasnivaju na tom korisničkom certifikatu, uz podršku vaše korporativne PKI infrastrukture.

Ovaj model zahtijeva dobro konfiguriranu PKI infrastrukturu za preduzeća i certifikacijsko tijelo (CRA). U federiranim implementacijama, AD FS obično djeluje kao CRA. Osim toga, u hibridnim okruženjima, povratno pisanje uređaja mora biti omogućeno u Microsoft Entra Connectu.

Važna napomena: nijedan od ovih tipova povjerenja nije inherentno sigurniji od drugog; izbor zavisi od vaše trenutne infrastrukture, od toga da li već imate PKI, da li želite da dodate AD FS i koliko ste spremni da manipulišete kontrolerima domena.

PKI zahtjevi prema modelu i vrsti povjerenja

Jedno od tipičnih pitanja kada se raspravlja o Windows Hello-u u domenu je da li je za njegov rad potreban potpuni PKI . Odgovor u potpunosti zavisi od vašeg modela implementacije i odabrane vrste povjerenja.

Kerberos povjerenje u oblaku je jedina hibridna opcija koja ne zahtijeva certifikate . Ako možete usvojiti ovaj model, izbjegavate potrebu za implementacijom korporativnih CA za kontrolere domena i korisnike. To ga čini posebno atraktivnim za okruženja koja ne žele da se bave PKI-jem.

Međutim, u hibridnim modelima zasnovanim na povjerenju ključa ili povjerenju certifikata , kao i u isključivo lokalnim modelima, potreban vam je PKI:

• u kontroleri domena Hibridnim i lokalnim okruženjima potreban je certifikat kako bi im Windows klijenti mogli vjerovati prilikom validacije autentifikacije zasnovane na certifikatu.
• Ako koristite povjerenje u certifikatZa izdavanje korisničkih certifikata potreban vam je poslovni PKI i autoritet za registraciju certifikata (CRA). AD FS djeluje kao CRA u mnogim implementacijama.
• U nekim hibridnim okruženjima morat ćete izdavanje VPN certifikata korisnicima, ako njihov pristup lokalnim resursima ide kroz tunele koji zavise od certifikata.

Stoga, ako oklijevate da li da koristite kontroler domene, a vaše okruženje je već sinhronizovano sa Microsoft Entra ID-om, najpraktičnije rješenje je obično da se odlučite za Kerberos u oblaku , što znatno pojednostavljuje infrastrukturu.

Autentifikacija pomoću Microsoft Login ID-a

Windows Hello for Business se također koristi za autentifikaciju korisnika pomoću Microsoft Entra ID-a , bez obzira na to kako komunicirate s Active Directoryjem. Ovdje dolaze u obzir dvije glavne opcije: federirana autentifikacija (na primjer, s AD FS-om) ili autentifikacija u oblaku (PHS/PTA).

U zavisnosti od modela implementacije i vrste povjerenja, nameću se određeni zahtjevi:

• Samo u oblakuAutentifikacija u oblaku se koristi prema zadanim postavkama. Možete se odlučiti za federiranu autentifikaciju s IdP-om treće strane ako želite, ali Windows Hello besprijekorno radi sa standardnom autentifikacijom u oblaku.
• Hibrid s Kerberos cloud povjerenjem ili Key povjerenjemMožete koristiti sinhronizaciju heširanja lozinki (PHS), prolaznu autentifikaciju (PTA) ili federaciju (AD FS ili druge IdP-ove), ovisno o vašem trenutnom dizajnu.
• Certificirani hibridZahtijeva federiranu autentifikaciju s AD FS-om; ne podržava PHS ili PTA. AD FS je ključan za ovo.

Ako je vaš zakupac već postavio PHS ili PTA i ne želite mijenjati AD FS, Kerberos cloud trust ili model Key Trust su bolji izbor. Međutim, ako već koristite AD FS federaciju za sve, certificate trust bi mogao biti prirodan izbor.

Registracija uređaja prema modelu

Još jedan ključni blok je registar uređaja , koji određuje ko kontroliše opremu za izdavanje tokena i omogućavanje SSO-a.

U lokalnim okruženjima , server s ulogom AD FS obrađuje registraciju uređaja. Upravlja odnosom povjerenja s uređajima i izdaje tokene potrebne za funkcioniranje Windows Hello for Business unutar lokalne domene.

U hibridnim ili okruženjima isključivo u oblaku , uređaji se moraju registrovati pomoću Microsoft Entra ID-a, bilo kao:

• Microsoft Azure AD se pridružio.
• Microsoft spaja hibride (hibridno AD spajanje).
• Microsoft prijava za registrovane korisnike (uobičajeno u BYOD-u).

Vrsta pridruživanja određuje koje mogućnosti imate: na primjer, hibridni uređaji omogućavaju jednokratnu prijavu (SSO) i za oblak i za lokalnu mrežu bez potrebe da korisnik žonglira s različitim akreditivima.

Višefaktorska autentifikacija (MFA) u pružanju usluga

Jedan od glavnih ciljeva Windows Hello for Business je odmak od tradicionalnih lozinki , pružajući snažne akreditivne podatke podržane sigurnim uređajima. Da bi se to postiglo, proces pružanja usluga zahtijeva dvofaktorsku autentifikaciju.

Ideja je da se slabi akreditivi (korisničko ime i lozinka) koriste samo kao prvi faktor, dok drugi faktor osigurava MFA rješenje . Windows ne generira Windows Hello for Business akreditiv dok korisnik uspješno ne završi MFA.

U hibridnim i okruženjima isključivo u oblaku, možete koristiti:

• Microsoft ulazi u MFA integrisan.
• MFA rješenja trećih strana, bilo kao eksterna metoda autentifikacije u Microsoft Enter ID-u ili putem federiranog IdP-a.

U lokalnim okruženjima bez Microsoft Entra ID-a, trebat će vam MFA opcija koja se integrira kao AD FS MFA adapter . Microsoft i drugi dobavljači nude namjenske adaptere za ovu svrhu.

Osim toga, u federiranim domenama možete prilagoditi brendiranje Ponašanje federiranog IdpMfaOvo govori Microsoft Entra ID-u da li da prihvati, zahtijeva ili odbije MFA koji dolazi od federiranog IdP-a. Ova postavka se pregleda i mijenja pomoću PowerShell naredbi kao što su Get-MgDomainFederationConfiguration y Update-MgDomainFederationConfiguration.

Konfiguracija pravila: GPO vs CSP

Da biste omogućili korisnicima da koriste Windows Hello for Business na svojim uređajima, potrebno je da konfigurišete odgovarajuće politike . Postoje dva glavna mehanizma:

• Pružatelj usluga konfiguracije (CSP)Idealno za uređaje kojima se upravlja putem MDM-a, kao što je Microsoft Intune. Omogućava vam primjenu Windows Hello politika pomoću konfiguracijskih profila, pa čak i s paketima za pružanje usluga.
• Grupna politika (GPO): koristi se za računare povezane s domenom kojima ne upravlja MDM ili gdje želite nastaviti s tradicionalnim lokalnim upravljanjem.

U bilo kojem modelu (samo u oblaku, hibridnom ili lokalnom), možete koristiti CSP, GPO ili njihovu kombinaciju, ovisno o tome kako upravljate svojim uređajima. Na primjer, možete upravljati laptopima pridruženim domeni pomoću Intune-a (hibrid) dok istovremeno primjenjujete neku osnovnu konfiguraciju putem GPO-a ili sigurne udaljene administracije.

U klasičnoj GPO implementaciji postoji jedna obavezna ključna politika za omogućavanje Windows Hello for Business u modelu povjerenja ključeva i još jedna toplo preporučena politika:

• Ruta tima: Konfiguracija računara → Administrativni predlošci → Windows komponente → Windows Hello za tvrtke → Korištenje Windows Hello za tvrtke (omogućeno).
• Putanja korisnika: Konfiguracija korisnika → Administrativni predlošci → Windows komponente → Windows Hello za tvrtke → Korištenje Windows Hello za tvrtke (omogućeno ako želite da se prisili na korištenje po korisniku).
• Dodatno: Koristite hardverski sigurnosni uređaj, kako bi se sprovela upotreba TPM-a i poboljšala zaštita ključeva.

Ako primijenite postavku na čvoru Računar, svi korisnici koji se prijave na te uređaje bit će prisiljeni pokušati se registrirati za Windows Hello for Business. Ako je primijenite na čvoru Korisnik, samo će predviđeni korisnici vidjeti iskustvo registracije. U slučaju sukoba, korisničke politike imaju prednost nad pravilima računara.

Objekti grupnih politika (GPO) mogu se povezati s domenom ili određenim organizacijskim jedinicama (OU), filtrirati prema sigurnosnim grupama ili čak pomoću WMI filtera kako bi se precizno segmentiralo koje mašine su uključene u implementaciju. Pored ovih osnovnih opcija, postoji niz detaljnih Windows Hello politika (npr. složenost PIN-a, vrijeme zaključavanja, upotreba biometrije) koje možete prilagoditi prema sigurnosnoj politici vaše kompanije.

Proces registracije i korisničko iskustvo

Iz perspektive korisnika, proces podešavanja Windows Hello for Business je prilično jednostavan. Pružanje usluga počinje odmah nakon što se korisnički profil učita i prije nego što vide radnu površinu, pod uslovom da su ispunjeni svi preduslovi infrastrukture i pravila.

Ako želite provjeriti jesu li prethodne provjere uspješno provedene, možete pregledati dnevnik administratora korisničkog uređaja U Pregledniku događaja: Zapisnici aplikacija i usluga → Microsoft → Windows. Druga opcija je korištenje dsregcmd.exe /status na konzoli da biste vidjeli status registracije uređaja i njegov odnos s Microsoft Enter ID-om.

Koraci koje korisnik slijedi tokom registracije su obično sljedeći:

1. Ako uređaj podržava biometrijsku autentifikaciju (čitač otiska prsta, kompatibilna kamera), Windows će zatražiti od korisnika da konfigurirajte biometrijsku gestuOvaj gest će otključati uređaj i autentificirati korisnike s resursima koji prihvataju Windows Hello for Business. Korisnik može preskočiti ovaj korak ako želi koristiti samo PIN.
2. Windows vas obavještava da će koristiti Windows Hello s korporativnim računom i korisnik mora prihvatiti.
3. Faza počinje višefaktorska autentifikacijaWindows obavještava korisnika da pokušava da ga kontaktira putem konfigurirane MFA metode (na primjer, mobilne aplikacije, poziva ili SMS-a). Pružanje usluga se ne nastavlja dok se MFA ne završi, ne uspije ili ne istekne. Ako MFA ne uspije ili istekne, korisnik prima poruku o grešci i od njega se traži da ponovo pokuša.
4. Nakon uspješne MFA, sistem traži od korisnika da Kreirajte i potvrdite PINOvaj PIN mora biti u skladu sa konfigurisanim direktivama složenosti (minimalna dužina, ograničenje ponovljenih cifara itd.).
5. Konačno, Windows zahtijeva asimetrični par ključeva Za korisnika, idealno generirano i zaštićeno unutar TPM-a (ili obavezno ako je navedeno u politici). Nakon što se ključevi generiraju, Windows registrira javni ključ kod IdP-a (Microsoft Entra ID ili AD FS, ovisno o modelu). Nakon završetka registracije ključa, čarobnjak obavještava korisnika da sada može koristiti svoj PIN ili biometrijske podatke za prijavu, a korisnik zatvara aplikaciju za pružanje usluga i pristupa radnoj površini.

Zvanična dokumentacija obično uključuje dijagrame sekvenci i video zapise koji ilustruju ove korake, uključujući primjere s prilagođenim MFA adapterima za AD FS. Ovo je korisno za razumijevanje poziva između klijenta, IdP-a, kontrolera domena i MFA servisa.

Zapisivanje ključeva i sinhronizacija direktorija

U srži Windows Hello-a za preduzeća je kreiranje i registracija asimetričnog para ključeva . Pružanje usluga generiše privatni ključ povezan sa uređajem (obično pohranjen u TPM-u) i registruje javni ključ kod odgovarajućeg provajdera identiteta.

• Modeli samo za oblakJavni ključ je registrovan u Microsoft Login ID-u.
• Hibridni modeliTakođer se registrira s Microsoft Entra ID-om; zatim se Microsoft Entra Connect Sync brine o sinhronizaciji javnog ključa s Active Directoryjem.
• Lokalni modeliJavni ključ je registrovan u AD FS-u, koji deluje kao provajder identiteta za lokalno okruženje.

U hibridnim modelima, Microsoft Entra Connect ne samo da sinhronizuje korisnike i uređaje, već i javne Windows Hello akreditive , omogućavajući korisniku da dobije SSO za lokalne resurse koristeći te jake akreditive, bez potrebe za ponovnim korištenjem lozinke.

U isključivo lokalnim modelima koji koriste Azure MFA kao višefaktorsko rješenje, sinhronizacija direktorija može se koristiti za uvoz korisnika iz Active Directoryja na Azure MFA server, koji zauzvrat komunicira s MFA cloud uslugom radi validacije drugog faktora.

zahtjevi operativnog sistema

Što se tiče verzija Windowsa, sve verzije klijenata koje zvanično podržava Microsoft mogu koristiti Windows Hello for Business . Međutim, Kerberos povjerenje u oblaku ima određene minimalne zahtjeve:

• Windows 10 21H2 sa ažuriranjem KB5010415 ili novijim.
• Windows 11 21H2 sa ažuriranjem KB5010414 ili novijim.

Za ostale vrste povjerenja (ključ i certifikat) u hibridnim ili lokalnim modelima, sve podržane klijentske verzije sustava Windows su važeće, pod uvjetom da primaju sigurnosna ažuriranja.

Što se tiče kontrolera domena, Windows Hello za preduzeća radi sa svim podržanim verzijama Windows Servera, ali Kerberos povjerenje u oblaku ponovo ima minimalne zahtjeve:

• Windows Server 2016 sa KB4534307 ili novijom verzijom.
• Windows Server 2019 sa KB4534321 ili novijom verzijom.
• Windows Server 2022.
• Windows Server 2025.

U svakom slučaju, minimalni funkcionalni nivo šume i domene mora biti Windows Server 2008 R2 za sve modele implementacije. Ako još uvijek imate domene sa ranijim funkcionalnim nivoima, morat ćete ih nadograditi prije nego što razmotrite ozbiljno implementaciju Windows Hello for Business.

Zahtjevi za licenciranje i usluge u oblaku

Što se tiče licenciranja, sam Windows Hello za tvrtke ne zahtijeva direktno Microsoft Entra ID P1 ili P2 . Međutim, neke povezane funkcije (kao što su automatska MDM registracija, određene politike uvjetnog pristupa ili povratno pisanje uređaja) mogu zahtijevati nivoe P1/P2.

Neke ključne tačke licenciranja su:

• Možete implementirati Windows Hello za poslovanje pomoću besplatni nivo Microsoft Sign In ID. Svi besplatni računi mogu koristiti Microsoft Sign In MFA za Windows funkcije bez lozinke.
• Uređaji kojima se upravlja putem MDM-a (Intune ili drugi) ne zahtijevaju P1/P2 jednostavno zato što koriste Windows Hello; međutim, bez P1/P2, registracija u MDM možda neće biti automatska i korisnici će morati registrujte se ručno u MDM rješenju.
• Ako koristite model od povjerenje u certifikat U hibridnom režimu, trebat će vam barem Microsoft Enter ID P1 da biste omogućili funkcije kao što su povratno pisanje uređaja i upis certifikata putem ovlaštenja za registraciju AD FS-a.
• U lokalnim okruženjima, ako odlučite koristiti Azure MFA kao višefaktorsko rješenje, morat ćete imati odgovarajuće Azure MFA licence ili pakete koji ga uključuju.

Ukratko: za mnoge hibridne implementacije s Kerberosom u oblaku ili povjerenjem ključeva, P1/P2 pretplate nisu obavezne, ali ako želite u potpunosti iskoristiti prednosti modernog upravljanja, naprednog uvjetnog pristupa i povratnog pisanja uređaja, ove pretplate postaju relevantne.

Kako se sve ovo uklapa u scenarij iz stvarnog svijeta: hibridno povezani tableti

U tipičnom okruženju terenskog tehničara s hibridno povezanim Windows tabletima, obično je slučaj sljedeće:

• Uređaji su pridružio se domeni i registrovan sa Microsoft Login ID-om (hibridno AD spajanje).
• Konfiguracijom se upravlja pomoću Intunea, GPO-a ili kombinacije oba.
• Želite omogućiti Prijava otiskom prsta ili PIN-om kako biste izbjegli kucanje lozinki na ekranu osjetljivom na dodir.

U ovom kontekstu, obično je preporučljivije odlučiti se za Kerberos u oblaku nego za modele koji zahtijevaju potpunu PKI infrastrukturu. Ne morate ništa "lomiti" na kontrolerima domena osim instaliranja potrebnih zakrpa i konfiguriranja Microsoft Entra Kerberosa, a izbjegavate i muke s korisničkim certifikatima i CRA.

Ako ste već kreirali konfiguracijski profil u Intuneu da biste omogućili Windows Hello i vidite da sistem nudi konfigurisanje PIN-a ili biometrije, ali zatim dobijate grešku "Vaši akreditivni podaci nisu mogli biti verifikovani" kada pokušavate da koristite Windows Hello, to je najverovatnije zato što:

• Zar nemate Pouzdani backend završen (Kerberos u oblaku/Ključ/Certifikat) za komunikaciju s domenom.
• Ili konfiguracija ne radi ispravno hibridni model implementacije slijedeći službene smjernice (na primjer, specifični vodič za hibridni oblak Kerberos povjerenje).

Globalna konfiguracija pod "Registracija uređaja → Windows registracija" u Intuneu aktivira Windows Hello na nivou zakupca, ali ne zamjenjuje osnovne infrastrukturne zahtjeve (vrsta povjerenja, Microsoft Entra Kerberos, sinhronizacija direktorija itd.). Zato vidite čarobnjaka na klijentu, ali autentifikacija na strani servera ne uspijeva prilikom validacije akreditiva.

U ovim slučajevima je razumno korak po korak pregledati dokumentaciju za implementaciju Windows Hello for Business i njegovu hibridizaciju s Kerberosom u oblaku, pazeći da se uređaji ispravno registruju (putem dsregcmd /status), da je Microsoft Entra Kerberos konfiguriran u ispravnoj šumi i da su politike (CSP/GPO) primijenjene na odgovarajuće korisnike i računare.

Sa svim ovim pravilno usklađenim elementima - jasnim modelom implementacije, pravom vrstom povjerenja, funkcionalnim MFA, ispravnom registracijom uređaja i ključeva i dobro primijenjenim politikama - Windows Hello for Business prestaje biti "mučenje u postavljanju" i postaje prilično praktičan način za vaše korisnike da se prijave na domenu pomoću PIN-a, otiska prsta ili lica umjesto da se muče s beskrajnim lozinkama na tastaturama osjetljivim na dodir.