Windows Hello za preduzeća: Kompletan vodič za jednokratnu prijavu (SSO) i sigurnost hardvera

Windows Hello for Business postao je temelj Microsoftove strategije prijave bez lozinki: kombinira PIN-ove, biometriju i kriptografske ključeve kako bi korisnicima omogućio prijavu bez unosa lozinki, ali uz znatno viši nivo sigurnosti. Sve ovo podržava hardverska sigurnost, TPM i moderni SSO modeli u cloud, hibridnim i lokalnim okruženjima.

Daleko od toga da je samo "Windows PIN", Windows Hello for Business (WHfB) je distribuirani sistem koji integriše Microsoft Entra ID (ranije Azure AD), Active Directory, PKI, Kerberos, FIDO2 i napredne politike za uređaje i korisnike. Ako ste administrator Windowsa ili identiteta, razumijevanje kako se sve uklapa - registracija, obezbjeđivanje, sinhronizacija ključeva, certifikati i autentifikacija - ključno je za nesmetano postavljanje robusne, na phishing otporne jedinstvene prijave.

Šta je tačno Windows Hello za preduzeća i kako mijenja autentifikaciju?

Windows Hello za tvrtke je upravljana verzija sustava Windows Hello na razini poduzeća. Zamjenjuje lozinku javnim ključem koji je povezan s uređajem, zaštićen TPM-om i otključan PIN-om ili biometrijskim gestom. Ovaj vjerodajnica omogućuje autentifikaciju za Microsoft Entra ID, Active Directory ili AD FS i druge usluge koje se oslanjaju na njega.

Umjesto oslanjanja na dijeljene tajne (lozinke, OTP-ove, SMS kodove), WHfB generira par javnog/privatnog ključa za svakog korisnika i uređaj. Javni ključ se registrira kod pružatelja identiteta (IdP), a privatni ključ ostaje sigurno pohranjen na uređaju i ne može se izvesti. Korisnik samo pruža "entropiju" sa svojim PIN-om ili biometrijskim podacima kako bi oslobodio ovaj privatni ključ kada želi izvršiti autentifikaciju.

Rezultat je iskustvo autentifikacije otporno na phishing, krađu vjerodajnica i napade grubom silom , održavajući SSO i u oblaku (Microsoft 365, moderne aplikacije) i u lokalnim uslugama (Kerberos, naslijeđene aplikacije, VPN-ovi zasnovani na certifikatima itd.).

Interne faze Windows Hello za preduzeća: Od nule do SSO-a

Da bismo u potpunosti razumjeli WHfB, korisno je podijeliti njegov rad na nekoliko hronoloških faza: registracija uređaja, obezbjeđivanje, sinhronizacija ključeva (ako je primjenjivo), upis certifikata (ako se koristi) i konačno, dnevna autentifikacija.

1. Registracija uređaja

Prvo, uređaj mora proći kroz proces registracije . Ovaj korak povezuje uređaj sa određenim IdP-om i daje mu vlastiti identitet.

Cloud ili hibridne implementacijeIdP je Microsoft Enter ID, a uređaj je registrovan u servisu za registraciju uređaja.
Čisto lokalne implementacijeIdP je AD FS, a registracija se vrši putem servisa za registraciju uređaja preduzeća koji je izložen putem AD FS-a.

Nakon registracije, uređaj ima pouzdani identitet koji mu omogućava autentifikaciju s IdP-om kada se korisnik prijavi. Postoje različite vrste registracije (pridruživanje domeni, pridruživanje Microsoft Entri, lična registracija itd.), poznate kao vrste pridruživanja , koje određuju naknadno ponašanje WHfB-a i SSO-a.

2. Faza nabavke

Tokom pružanja usluga, korisnik prestaje biti "korisnik s lozinkom" i umjesto toga ima vlastiti Windows Hello kontejner na uređaju. Ovaj kontejner grupira kriptografski materijal povezan s njihovim računima (korporativni, obrazovni, lični) izolovano od strane dobavljača identiteta.

Tipičan tok nabavke slijedi ove korake:

U asistentu za korisničko iskustvo (CXH), korisnik se autentifikuje kod IdP-a koristeći MFA (obično korisničko ime/lozinka plus drugi faktor).
Nakon uspješnog MFA, sistem traži od korisnika da konfiguriše PIN i, ako je dostupan kompatibilan hardver, jedan ili više biometrijski gestovi (lice, otisak stopala).
Kontejner za Windows Hello je kreiran na uređaju.
Tim generira par javnih/privatnih ključeva za autentifikaciju, po mogućnosti povezano s TPM-om; ako nema TPM-a, zaštićeno je softverskom enkripcijom.
Privatni ključ se pohranjuje lokalno, zapečaćuje ga TPM ako postoji i označava se kao nije za izvoz.
Javni ključ je registrovan u IdP-u povezanom s korisničkim računom:
- U cloud okruženjima, servis za registraciju uređaja ga zapisuje u korisnički objekt Microsoft Enter ID.
- U lokalnim scenarijima, AD FS pohranjuje ključ u Active Directory.

Od tog trenutka nadalje, kada korisnik otključa uređaj PIN-om ili biometrijskim podacima, on zapravo "pokreće" korištenje tog privatnog ključa Hello kako bi dokazao svoj identitet IdP-u.

3. Detalji kontejnera za Windows Hello i tipovi ključeva

Kontejner Windows Hello ne pohranjuje samo jedan ključ: on može sadržavati različite vrste kriptografskog materijala , svaki sa svojom funkcijom i vlastitim "zaštitnikom". Svaki zaštitnik šifrira svoju kopiju autentifikacijskog ključa koristeći drugačiju tehniku (na primjer, zapečaćivanje u TPM-u korištenjem PIN-a kao entropije ili simetrično šifriranje izvedeno iz PIN-a ako nema TPM-a).

Unutar kontejnera možemo pronaći:

Una primarni ključ za autentifikacijuUvijek se tokom registracije kreira asimetrični (javno/privatno) par. Ovo je onaj koji se mora otključati svaki put pomoću PIN-a ili biometrije. Ako korisnik resetuje PIN, a Nova šifra i sav materijal koji je prethodni zaštitio ponovo se šifrira novim.
Jedan ili više ključevi za identifikaciju korisnika (Ključevi korisničkog ID-a): Oni mogu biti simetrični ili asimetrični ovisno o IdP-u i modelu povjerenja. U implementacijama zasnovanim na certifikatima, ovi ključevi se koriste za generiranje zahtjeva prema CA ili za RDP, VPN itd.
Opciono, a administrativni ključ, dizajniran za scenarije resetiranja (npr. oporavak PIN-a) i podatke povezane s TPM-om uređaja.

Ključevi korisničkog ID-a koriste se za dokazivanje vlasništva nad privatnim ključem za uslugu (na primjer, potpisivanje jednokratnog broja). Active Directory, Microsoft Entra ID i lični Microsoft računi zahtijevaju asimetrične parove ključeva; uređaj generira par, zapisuje javni dio i štiti privatni dio, koji nikada ne napušta uređaj.

Ako vaša organizacija ima korporativni PKI, možete povezati ključeve korisničkog ID-a s certifikatima koje je izdao vaš CA , što omogućava WHfB-u da se integrira s aplikacijama koje zavise od certifikata (klasični VPN-ovi, RDP sa pametnim karticama itd.). Ako vam PKI nije potreban, sam IdP može generirati i upravljati ovim identifikacijskim materijalom kako bi se smanjila složenost.

4. Sinhronizacija ključeva u hibridnim okruženjima

U hibridnim implementacijama , gdje Microsoft Entra ID i Active Directory koegzistiraju, potreban je dodatni korak: sinhronizacija javnog ključa Hello iz oblaka u lokalni direktorij kako bi kontroleri domena mogli autentificirati korisnike.

Javni ključ je pohranjen u atributu msDS-KeyCredentialLink korisničkog objekta u Active Directoryju, a sinhronizacijom upravlja Microsoft Connect sinhronizacijaBez ove replikacije, lokalnoj domeni bi bilo nemoguće provjeriti autentifikaciju zasnovanu na WHfB-u sa uređaja povezanog s Microsoft Entra-om.

5. Registracija certifikata (pri korištenju povjerenja certifikata)

U modelima gdje se WHfB oslanja na certifikate za Kerberos autentifikaciju ili lokalne aplikacije , pojavljuje se dodatna faza: registracija certifikata.

Nakon što je ključ registrovan, klijent generiše zahtjev za certifikat i šalje ga Certificate Authority (CRA) , koji se obično nalazi na AD FS serveru i orkestrira zahtjev sa korporativnom PKI. CA izdaje certifikat, koji se pohranjuje unutar korisnikovog Hello kontejnera na uređaju i koristi se za autentifikaciju lokalnim resursima koji očekuju certifikat pametne kartice ili slično.

Dnevna autentifikacija, SSO i uloga hardverske sigurnosti

U svakodnevnoj upotrebi , kada korisnik uključi ili otključa računar, autentifikacija se uvijek zasniva na privatnom dijelu Windows Hello akreditiva (ključ ili certifikat), plus korisnikovom gestu (PIN ili biometrijski podaci). Ovaj gest se nikada ne šalje IdP-u niti se kao takav pohranjuje u sistemu.

Autentifikacija je, u stvari, dvofaktorska :

Nešto što korisnik posjeduje: ključ ili certifikat povezan s uređajem.
Nešto što korisnik zna ili jeste: lokalni PIN ili biometrijski podaci.

Kada korisnik unese svoj PIN ili koristi otisak prsta/lice, Windows oslobađa ključ za autentifikaciju iz njegovog spremnika i koristi ga za kriptografsko potpisivanje podataka poslanih dobavljaču identiteta (IdP) . Dobavljač identiteta provjerava ovaj potpis u odnosu na pohranjeni javni ključ i, ako se sve poklapa, izdaje tokene potrebne za pristup resursima (Microsoft 365, SaaS aplikacije, lokalni resursi itd.).

Ni PIN ni biometrijski predložak ne napuštaju uređaj . PIN se čak ni ne pohranjuje kao tekst: služi kao entropija za kriptografske operacije i za otključavanje materijala zaštićenog TPM-om. IdP vidi samo kriptografski dokaz da korisnik kontrolira registrirani privatni ključ.

Glavni token za osvježavanje (PRT) i moderni SSO

Jednokratna prijava (SSO) u modernom Microsoftovom svijetu oslanja se na ključni token: Primarni token za osvježavanje (PRT) . To je JSON web token koji uključuje korisničke i uređajne zahtjeve te omogućava SSO za aplikacije zaštićene Microsoft Entra ID-om ili AD FS-om.

PRT se dobija prijavom ili otključavanjem uređaja pomoću pouzdanih vjerodajnica (WHfB ili tradicionalne vjerodajnice), slično kao što se Kerberos TGT prethodno dobijao u okruženju samo na lokaciji. Na uređajima :

Pridružite se Microsoftu. ili hibridi povezani s Microsoft Enterom: PRT se izdaje prilikom same prijave.
Registrovani lični uređaji (BYOD): PRT se generira kada se na uređaj doda poslovni ili obrazovni račun.

Bez PRT-a, korisnici bi morali stalno unositi akreditive, a politike uslovnog pristupa zasnovane na statusu uređaja ne bi se mogle procijeniti . Sa WHfB-om i važećim PRT-om, postiže se besprijekoran SSO, a istovremeno je uslovljen na osnovu statusa uređaja, usklađenosti, rizika i drugih faktora.

Ključne postavke pravila: SSO i sigurnost hardvera

WHfB nudi sveobuhvatan skup konfiguracija politika putem CSP-a (za MDM kao što je Intune) i GPO-a. Mnoge od njih se fokusiraju na jačanje SSO-a i osiguravanje da se dostupni sigurnosni hardver na uređaju uvijek koristi.

Obavezna upotreba hardverskih sigurnosnih uređaja (TPM)

Jedna od najvažnijih politika nalaže da se obezbjeđivanje Windows Hello for Business usluge vrši samo na uređajima s upotrebljivim TPM-om (1.2 ili 2.0) . TPM pruža dodatnu zaštitu jer je privatni ključ vezan za tu fizičku komponentu; čak i ako napadač kopira disk, neće moći koristiti ključ na drugom računaru.

Korištenjem CSP-a, ova konfiguracija se kontrolira pomoću:

./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice
I, opcionalno, isključenje određenih TPM 1.2 sa:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/ExcludeSecurityDevices/TPM12

Pored toga, postoji ekvivalent GPO-a u okviru administrativnih predložaka za Windows Hello for Business na nivou računara. Omogućavanje ove opcije će spriječiti WHfB pružanje usluga na računarima bez važećeg TPM-a , što će drastično ojačati sigurnost okruženja.

Konfigurišite lokalni SSO: certifikat naspram povjerenja u oblak

Za SSO prema lokalnim resursima (kontroleri domena, lokalne aplikacije), WHfB može koristiti tri glavna modela povjerenja : zasnovan na certifikatu, zasnovan na ključu (Key Trust) i, u novije vrijeme, Cloud Kerberos Trust.

Postoje dvije osnovne politike :

Korištenje certifikata za lokalnu autentifikaciju:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCertificateForOnPremAuth
Ako je omogućeno, WHfB unosi certifikat za prijavu unutar kontejnera i koristi ga za lokalnu autentifikaciju.
Korištenje cloud trust-a za lokalnu autentifikaciju:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth
Ako je omogućeno, WHfB koristi Kerberos tiket izveden iz autentifikacije u Microsoft Entra ID-u za autentifikaciju prema lokalnim resursima, bez potrebe za izdavanjem dodatnih certifikata.

Onemogućavanje ili nekonfigurisanje ovih pravila uzrokuje da se sistem oslanja na ključ ili certifikat , ovisno o drugim aktivnim opcijama. U grupnim pravilima, ove opcije se nalaze u odjeljcima Računar i Korisnik pod Windows komponente > Windows Hello for Business.

Glavna kontrola: Omogućavanje ili onemogućavanje Windows Hello za preduzeća

Postoji globalna politika koja odlučuje da li uređaj koristi WHfB i da li se čarobnjak za opskrbu pokreće nakon prijave:

./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/DisablePostLogonProvisioning

S njima možete :

Zahtijevajte od svih korisnika da omoguće WHfB na uređaju.
Potpuno spriječite upotrebu WHfB-a.
Dozvolite svakom korisniku da odluči da li želi da konfiguriše Hello.
Sprečite automatsko pokretanje čarobnjaka nakon prve prijave, što je korisno kada Koristite rješenje treće strane za obezbjeđivanje WHfB-a.

Politike PIN-a, oporavak i kontrole složenosti

PIN za Windows Hello je jedan od temelja rješenja. Iako ga mnogi ljudi pogrešno smatraju "kratkom" lozinkom, on je zapravo lokalni faktor vezan za uređaj, zaštićen TPM-om i mnogo manje upotrebljiv od tradicionalne lozinke.

Istek, historija i trajanje PIN-a

Pravila za PIN vam omogućavaju da prilagodite njihov životni ciklus i složenost na sličan način - iako detaljniji - kao i kod tradicionalnih lozinki:

IstekMožete podesiti da PIN istekne u periodu od 1 do 730 dana. Ako je vrijednost 0, PIN nikada ne ističe (zadana vrijednost).
Istorija: definira koliko se prethodnih PIN-ova ne može ponovo koristiti, između 0 i 50. Vrijednost 0 znači da se historija ne pohranjuje.
Minimalna i maksimalna dužina: konfigurabilni minimum od 4 znaka; maksimum do 127, uvijek vodeći računa da je minimum manji od maksimuma i da je prema zadanim postavkama, ako nije konfigurisano, potreban minimum od 6 znakova.

Ako ove politike nisu postavljene, zadano ponašanje dozvoljava do 127 znakova i zahtijeva PIN od najmanje 6, bez dodatnog sprovođenja osim pravila složenosti koja definirate.

Zahtjevi za sastavljanje PIN-a

Možete odlučiti koje vrste znakova su podržane, a koje su obavezne u PIN-u za Windows Hello:

ZnamenkeAko omogućite pravilo da zahtijeva cifre, PIN mora sadržavati barem jedan broj. Ako ga onemogućite, brojevi su zabranjeni. Bez ove postavke, brojevi su dozvoljeni, ali nisu obavezni.
Mala slova: omogućava vam da zahtijevate barem jedan, da ih potpuno zabranite ili da ih ostavite opcionalnim.
Letras mayúsculas: ista shema kao i mala slova.
Posebni znakovi: barem jedan može biti obavezan, mogu biti zabranjeni ili mogu biti dozvoljeni. Smatra se širokim skupom simbola (! " # $ % & ' ( ) + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~).

Ova pravila vam omogućavaju da prilagodite ravnotežu između upotrebljivosti i robusnosti . Međutim, ako je složenost pretjerana, povećava se rizik od zaboravljenih PIN-ova i zahtjeva za podršku, što mnoge organizacije pokušavaju izbjeći upravo prilikom usvajanja WHfB-a.

Oporavak PIN-a

Oporavak PIN-a omogućava korisniku da resetuje zaboravljeni PIN bez gubitka povezanih akreditiva ili certifikata (uključujući ključeve povezane s ličnim računima na tom računaru). Da bi to uradio, Windows Hello šifrira tajni kod za oporavak koji se pohranjuje lokalno, tako da ga samo usluga oporavka i sam uređaj mogu dešifrirati.

Ova funkcija zahtijeva od korisnika da izvrši višefaktorsku autentifikaciju s Microsoft Entra ID-om kako bi oporavio svoj PIN. Ako omogućite odgovarajuću politiku (putem CSP-a ili GPO-a), Windows će generirati i pohraniti ovaj tajni kod za oporavak. Ako ga onemogućite ili ga ostavite nekonfigurisanim, uređaj neće kreirati niti pohraniti tajni kod, a ako se PIN zaboravi, korisnik će ga morati potpuno izbrisati i obezbijediti novi, ponovo se registrujući za usluge kojima se pristupa sa starim PIN-om.

Biometrija, zaštita od lažiranja podataka i ESS

Biometrija u WHfB-u (lice, otisak prsta, šarenica) je dodatak PIN-u, a ne potpuna zamjena. Uvijek postoji rezervni PIN u slučaju da senzor zakaže ili kontekst ne dozvoljava njegovu upotrebu.

Poboljšana zaštita od lažiranja identiteta

Postoji specifična politika koja zahtijeva poboljšanu zaštitu od lažiranja identiteta za prepoznavanje lica. Kada je omogućena, Windows će dozvoliti autentifikaciju lica samo ako senzor i stek ispunjavaju ove napredne zahtjeve za otkrivanje napada (na primjer, sprečavanje prijava pomoću fotografija, videozapisa ili jednostavnih deepfakeova).

Ako je onemogućeno ili nije konfigurirano, Windows neće zahtijevati tu pojačanu zaštitu i autentifikacija lica će biti manje restriktivna. Povezana CSP ruta je ./Device/Vendor/MSFT/PassportForWork/Biometrics/FacialFeaturesUseEnhancedAntiSpoofing, a ekvivalent se može pronaći i u GPO-u pod opcijama biometrije u programu Windows Hello for Business.

ESS: Poboljšana sigurnost prijave s perifernim uređajima

Poboljšana sigurnost prijave (ESS) je dodatni sloj koji kombinuje VBS (virtualizacija zasnovana sigurnost), TPM 2.0 i specifične komponente kako bi se izolovali biometrijski predlošci i operacije poređenja pomoću hardvera.

Sa ESS-om, biometrijski podaci (lice, otisak prsta) i poređenja se vrše u izolovanim i zaštićenim memorijskim regijama , kojima ostatak operativnog sistema nema direktan pristup. Kanal između senzora i algoritma je takođe zaštićen, tako da zlonamjerni softver ili napadači ne mogu ubrizgati ili reprodukovati lažne biometrijske podatke kako bi simulirali prijave ili blokirali korisnike.

Politika EnableESSwithSupportedPeripherals dozvolite dvije glavne vrijednosti:

0ESS je omogućen čak i ako postoje periferni ili integrirani senzori koji ne podržavaju ESS. Operacije autentifikacije su dozvoljene s ovim uređajima, uz određena ograničenja. Ovo nije najpreporučljivija opcija.
1ESS omogućen grijeh Prihvata periferne ili integrirane senzore koji nisu ESS. Drugim riječima, biometrijske operacije s bilo kojeg uređaja koji ne podržava ESS blokirane su za Windows Hello. Ovo je konfiguracija sa veća sigurnost.

Ako se onemoguće ili ne konfiguriraju, ESS uređaji će blokirati senzore koji nisu kompatibilni s ESS-om, održavajući konzervativan pristup sigurnosti.

Upotreba biometrije općenito

Politika UseBiometrics kontrolira da li Windows Hello for Business dozvoljava korištenje biometrijskih gesti ili podržava samo PIN-ove. Ako je omogućeno ili nije konfigurirano, biometrijski podaci su dozvoljeni; ako je onemogućeno, njihova upotreba je zabranjena i korisnici se uvijek moraju autentificirati PIN-om ili drugim faktorima.

U svakom slučaju , biometrijski podaci:

Oni su pohranjeni samo na lokalnom uređaju (baza podataka u C:\Windows\System32\WinBioDatabase).
Svaki senzor ima svoju datoteku i jedinstveni nasumično generirani ključ, šifriran AES-om u CBC modu i SHA-256 hashom.
Ne šalju se na eksterne servere niti sinhronizuju između računara, što sprečava napadače da imaju jedinstvene tačke prikupljanja.

Integracija sa pametnim karticama i starijim aplikacijama

Mnoge organizacije se i dalje oslanjaju na pametne kartice i aplikacije koje očekuju certifikate "slične pametnim karticama" . WHfB uključuje opcije za emulaciju ili integraciju s ovim okruženjima bez gubitka prednosti moderne autentifikacije.

Emulacija i nabrajanje pametnih kartica

Podrazumevano , Windows sprečava korisnike na istom računaru da vide Windows Hello akreditive koji su dodijeljeni drugim korisnicima. Politika vam omogućava da isključite ovu opciju u scenarijima gdje:

Isti korisnik može imati račune sa i bez privilegija na istom računaru.
Želi se prijaviti s "normalnim" računom, ali povećati privilegije prije odjave, koristeći vlastite Hello podatke.

Također postoji opcija za onemogućavanje emulacije pametne kartice . Ako je omogućena, WHfB akreditivi više neće biti kompatibilni s aplikacijama koje očekuju pametnu karticu. Ako se ostavi onemogućena ili nije konfigurirana, Windows će nastaviti automatski pružati ovu emulaciju.

Koristite Hello certifikate kao certifikate pametnih kartica

Još jedna važna politika es UseHelloCertificatesAsSmartCardCertificatesAko je omogućeno, aplikacije mogu obraditi Windows Hello certifikati za preduzeća, kao što su certifikati pametnih kartica.Međutim, u tom kontekstu, biometrijski faktori Nisu dostupni kada se zatraži autorizacija za korištenje privatnog ključa certifikata.

Ako ova postavka nije konfigurirana ili je onemogućena , aplikacije neće koristiti Hello certifikate na ovaj način, a biometrijska autentifikacija će ostati dostupna korisniku. Nije moguće omogućiti ovu opciju istovremeno s pravilom koje onemogućava emulaciju pametne kartice.

Zahtjevi za PKI, CRL i certifikat kontrolera domene

U implementacijama gdje WHfB mora osigurati SSO za lokalne resurse koristeći certifikate i Kerberos , PKI i infrastruktura certifikata moraju biti dobro podešeni, posebno ako postoje uređaji povezani samo s Microsoft Entra-om koji će se autentificirati prema Active Directoryju.

Tačka distribucije CRL-a dostupna uređajima povezanim na Entru

Jedna od ključnih tačaka je Lista opozvanih certifikata (CRL) . Kada CA opozove certifikat, dodaje informacije na ovu listu, a Windows je konsultuje kako bi provjerio da li je certifikat još uvijek važeći.

U mnogim lokalnim okruženjima, CDP (CRL Distribution Point) se objavljuje kao LDAP putanja u Active Directoryju . Ovo dobro funkcioniše za mašine povezane s domenom, ali ne i za uređaje povezane samo s Microsoft Entra-om, koji ne mogu čitati AD prije autentifikacije. Ovo stvara kružnu zavisnost: da biste validirali certifikat kontrolera domene, morate čitati AD, ali ne možete čitati AD bez prethodne autentifikacije.

Rješenje je objavljivanje CDP-a na web serveru dostupnom putem HTTP-a (ne HTTPS-a) , što ne zahtijeva prethodnu autentifikaciju. Tipična procedura uključuje:

Instalirajte IIS ili neki drugi web server na interni server.
Kreirajte virtuelni direktorijum (na primjer, cdp) koji ukazuje na dijeljenu mapu u kojoj CA može objaviti CRL-ove.
Prilagodite NTFS i dozvole za dijeljenje tako da CA može pisati u tu mapu.
Kreirajte DNS zapis (na primjer, crl.midominio.com) koji pokazuje na taj server.
Konfigurišite klima uređaj za emitovanje da uključi CDP HTTP u ekstenzijama izdanih certifikata i da objavi CRL i delta CRL na toj lokaciji.

Posle Morate prisilno objaviti novi CRL i provjeriti da li mu se može pristupiti iz preglednika. http://crl.tudominio.com/cdp i pregledajte datoteke .crl generisano.

Ponovno izdavanje certifikata kontrolera domene i stroga KDC validacija

Postojeći certifikati se ne ažuriraju automatski s novim CDP-om; moraju se obnoviti . Ovo se posebno odnosi na certifikate kontrolera domene koji se koriste za Kerberos autentifikaciju. WHfB provodi funkciju "KDC stroge validacije" kada se uređaj pridružio Microsoft Entri autentifikuje na lokalnoj domeni, tako da certifikat kontrolera domene mora ispunjavati nekoliko zahtjeva:

Domen mora posjedovati privatni ključ predstavljenog certifikata.
Korijenski CA koji je izdao DC certifikat mora biti u korijeni povjerenja uređaja.
Morate koristiti Predložak certifikata za Kerberos autentifikacijune stare šablone.
Certifikat mora sadržavati EKU od KDC autentifikacija.
Alternativno ime subjekta mora sadržavati DNS ime koje podudara se s nazivom domene.
Algoritam potpisa mora biti najmanje SHA256.
Javni ključ mora biti 2048 bit RSA.

Nakon konfigurisanja CA i obnavljanja DC certifikata, morate provjeriti na kartici s detaljima svakog certifikata da li je prisutan ispravan HTTP CDP. Ovo je ključno za uređaje povezane s Entra-om kako bi vjerovali kontrolerima domena prilikom autentifikacije s WHfB-om.

Implementirajte CA korijenski certifikat na uređajima koji su se pridružili Entri

Konačno, uređaji povezani s Microsoft Entra sistemom moraju vjerovati korijenskom CA te kompanije. To se postiže izvozom korijenskog certifikata iz lanca povjerenja DC certifikata i njegovom distribucijom računarima, na primjer, korištenjem:

Politika certifikat o povjerenju u opremu u Microsoft Intuneu, pokazujući na pouzdano korijensko skladište tima.
Ili ekvivalentne metode u drugim MDM/upravljanim rješenjima.

Ako se ovaj korak izostavi, čak i ako su svi ostali elementi ispravno konfigurirani, uređaji neće vjerovati DC-ovima i WHfB autentifikacije će propasti na TLS/certifikatnom sloju.

Windows Hello za preduzeća donosi značajan skok naprijed u sigurnosti i iskustvu prijave : zamjenjuje lozinke hardverski povezanim, centralno upravljanim akreditivima, nudeći moderno, na phishing otporno SSO u cloud i lokalnim okruženjima. Međutim, da bi zaista dobro funkcionisao, ključno je ozbiljno shvatiti infrastrukturu identiteta i PKI, definirati odgovarajuće politike za PIN-ove, biometriju i obaveznu upotrebu TPM-a, te implementirati postepeno uvođenje s jasnom komunikacijom s korisnicima, tako da se promjena doživljava kao poboljšanje, a ne samo kao još jedno IT opterećenje.