Windows Hello per a Empreses (Windows Hello for Business, WHfB) s'ha convertit en una de les peces clau de l'estratègia d'identitat de Microsoft per a empreses: adéu a les contrasenyes de tota la vida i hola a un model d'autenticació basat en claus criptogràfiques, biometria, PIN i dispositius de confiança. En combinació amb Microsoft Entra ID i l'inici de sessió únic (SSO), permet que els usuaris accedeixin a recursos al núvol i en local amb un sol gest, però mantenint controls de seguretat de nivell empresarial.
En aquest article desgranarem, amb calma però sense embuts, com funciona l'autenticació del Windows Hello for Business quan intervenen claus de maquinari, dispositius amb TPM i escenaris de SSO davant de Microsoft Entra ID i Active Directory. Veurem les fases internes (registre de dispositius, aprovisionament, sincronització de claus, certificats i autenticació), quin paper juga el PRT a l'SSO, com s'integra amb Kerberos en entorns híbrids i quins requisits d'infraestructura necessites perquè tot funcioni com un rellotge.
Arquitectura general de Windows Hello per a Empreses i el seu model sense contrasenyes
Windows Hello per a Empreses no és només “posar un PIN o la cara” per iniciar sessió; és un sistema distribuït que combina identitat d'usuari, identitat de dispositiu i claus criptogràfiques protegides pel maquinari. L'autenticació es basa en un parell de claus pública/privada o en certificats, enllaçats al dispositiu (TPM) i desbloquejats per alguna cosa que l'usuari sap (PIN) o quelcom (biometria).
La gran diferència davant les contrasenyes clàssiques és que ja no existeix un “secret compartit” que viatgi per la xarxa o s'emmagatzemi centralment: el servidor (Microsoft Entra ID o Active Directory) guarda únicament la part pública de la clau, mentre que la privada mai no surt del dispositiu. Quan l'usuari vol autenticar-se, Windows signa un desafiament (nonze) amb la clau privada, i el proveïdor d'identitats valida aquesta signatura amb la clau pública registrada.
Aquest enfocament fa que WHfB sigui resistent al phishing: encara que un atacant enganyés l'usuari perquè introdueixi el seu nom d'usuari en un lloc maliciós, no podria reproduir l'autenticació sense la clau privada vinculada al TPM de l'ordinador. El resultat és un sistema d'autenticació en dues fases (clau + PIN/biometria) que compleix els criteris de MFA forta, però amb una experiència d'usuari molt més fluida i amb la seguretat de Windows 11.
WHfB s'integra de forma nativa amb Microsoft Entra ID i amb Active Directory, permetent diferents models de desplegament: només núvol, híbrid o totalment local. A més, podeu conviure amb targetes intel·ligents i claus FIDO2, i fins i tot reutilitzar la PKI existent de l'organització quan s'opta per models basats en certificats.
Fases del funcionament del Windows Hello for Business
Per entendre bé què passa “per sota del capó”, el més pràctic és dividir el cicle de vida de Windows Hello per a Empreses en diverses fases encadenades: registre de dispositius, aprovisionament, sincronització de claus (en híbrid), inscripció de certificats (si es fan servir) i, finalment, autenticació i SSO.
1. Registre de dispositius
Abans d'emetre credencials de WHfB a un usuari, el dispositiu ha de tenir identitat pròpia. Aquest procés s'anomena registre de dispositiu i associa l'equip amb el proveïdor d'identitats (IdP) de l'organització.
Depenent del tipus de desplegament, canvieu l'IdP i el servei de registre:
- Implementacions al núvol o híbrides: l'IdP és Microsoft Entra ID. El dispositiu es registra al Device Registration Service d'Entrada ID i es converteix en “dispositiu unit a Microsoft Entra” o “híbrid unit a Microsoft Entra”.
- Implementacions purament locals: l'IdP és AD FS, i el dispositiu es registra al servei de registre de dispositius empresarials que exposa AD FS.
Com a resultat del registre, l'IdP concedeix a l'equip una identitat pròpia, que s'usarà en posteriors intercanvis d'autenticació d'usuari i en l'obtenció de tokens. Hi ha diferents tipus de combinació o estats d'unió (només Entra, híbrid, unit a domini clàssic + registrat, etc.), que determinen com es comporta el dispositiu en entorns mixtos.
2. Aprovisionament de Windows Hello for Business
La fase de proveïment és quan realment es creen les credencials de Hello per a un usuari concret en un dispositiu. Aquí apareix un concepte clau: el contenidor de Windows Hello, que és una estructura lògica on s'emmagatzema tot el material de clau associat a les identitats de l'usuari en aquest equip.
El flux típic d'aprovisionament inclou diversos passos encadenats:
- L'usuari inicia sessió amb les credencials tradicionals (normalment, usuari i contrasenya) i el sistema llança l'experiència de configuració de WHfB, sol·licitant autenticació multifactor davant l'IdP (Microsoft Entra ID o AD FS).
- Després de superar correctament el MFA, es demana a l'usuari que defineixi un PIN i, si el maquinari ho permet, que enregistri biometria (petjada, rostre, iris).
- Confirmat el PIN, Windows crea el contenidor de Windows Hello al dispositiu.
- Es genera un parell de claus pública i privada d'autenticació, enllaçat al TPM (si existeix) o, si no, protegit per programari.
- La clau privada es desa localment i queda segellada al TPM, no exportable.
- La clau pública es registra a l'IdP i es lliga al compte de l'usuari:
- En escenaris al núvol o híbrids, el servei de registre de dispositius l'escriu a l'objecte d'usuari de Microsoft Entra ID.
- A escenaris locals amb AD FS, s'emmagatzema a Active Directory.
Dins del contenidor, cada protector (PIN, gest biomètric, etc.) manté la seva pròpia còpia xifrada de la clau d'autenticació. Si hi ha TPM, el PIN es fa servir com a entropia en una operació de segellat; si no, deriva una clau simètrica per xifrar el material. Això permet que l'usuari desbloquegi el mateix parell de claus amb gestos diferents, sense debilitar la protecció.
A més de la clau principal d'autenticació, el contenidor pot incloure altres elements, com una clau administrativa per a escenaris de restabliment de PIN, blobs amb certificats de TPM, i, sobretot, diferents tipus de claus d'identificador d'usuari que es fan servir per a protocols concrets (WebAuthn/FIDO2, Entra ID, certificats d'usuari per a VPN o RDP, etc.).
Detalls de les claus d'autenticació i identificador d'usuari
La clau d'autenticació de Windows Hello és sempre un parell asimètric (pública/privada) generat durant el registre. Cada vegada que cal fer-la servir, s'ha de desbloquejar amb el PIN o la biometria. Si l'usuari restableix el PIN, es genera un nou parell de claus d'autenticació i es rexifra tot el material protegit pel parell anterior.
Les claus d'identificador d'usuaris poden ser simètriques o asimètriques, segons l'IdP i l'escenari. En entorns empresarials moderns (Microsoft Entra ID, Active Directory, comptes Microsoft personals), l'habitual és que siguin també parells de claus asimètrics, generats i emmagatzemats al dispositiu, amb la part pública registrada al proveïdor d'identitat.
Hi ha dos camins principals per generar les claus d'identificador d'usuari en organitzacions:
- Associar-les a la PKI corporativa, de manera que la clau es vinculi a un certificat emès per la CA de lempresa. Això facilita la transició des d'infraestructures basades en certificats (VPN, RDP amb certificats d'usuari, etc.) a WHfB.
- Permetre que sigui directament el IdP (Entra ID o AD FS) el que gestioni el parell de claus associat a la identitat, reduint la complexitat de PKI quan no és imprescindible.
Aquestes claus es fan servir per demostrar possessió mitjançant signatura de nonces o tokens d'autenticació, tant davant de controladors de domini (Kerberos) com davant de serveis web que utilitzin WebAuthn (FIDO2). Un mateix dispositiu pot acollir diverses credencials FIDO associades a llocs web o aplicacions diferents, totes gestionades dins del contenidor de Windows Hello.
Emmagatzematge local de dades biomètriques
Un punt que sol preocupar molts usuaris i auditors és què passa amb els seus trets biomètrics. A Windows Hello per a Empreses, les plantilles biomètriques només s'emmagatzemen al dispositiu, en una base de dades local a què no accedeix Microsoft ni se sincronitza amb el núvol.
Cada sensor biomètric manté la seva pròpia base de dades de plantilles (Per exemple, en C:\WINDOWS\System32\WinBioDatabase), xifrada amb una clau aleatòria única per base de dades, protegida amb AES en mode CBC i amb hash SHA-256. Encara que un atacant aconseguís aquesta base de dades, no podria reconstruir imatges “en cru” de la cara o l'empremta; es tracta de dades de plantilla irreversibles.
3. Sincronització de claus en entorns híbrids
En desplegaments híbrids, la clau pública registrada a Microsoft Entra ID també ha d'arribar a Active Directory perquè l'usuari pugui autenticar-se sense contrasenya tant davant de serveis al núvol com en recursos on-premises.
Aquest procés el gestiona Microsoft Entra Connect Sync, que sincronitza la clau pública d'usuari des de Entra ID a l'atribut msDS-KeyCredentialLink de l'objecte d'usuari a l'Active Directory. D'aquesta manera, els controladors de domini poden validar autenticacions basades en clau (escenari key trust) o fer servir la informació associada per a models de cloud Kerberos trust.
4. Inscripció de certificats (quan es fa servir el model basat en certificats)
Si la vostra organització ja té una PKI desplegada i vol aprofitar-la amb WHfB, pots optar pel model de confiança basat en certificats. En aquest cas, després de registrar la clau a l'IdP, el client genera una petició de certificat i l'envia a una entitat de registre (CRA) allotjada típicament a un servidor AD FS.
La CRA valida la sol·licitud i la canalitza cap a la CA corporativa, que emet un certificat d'usuari. Aquest certificat s'emmagatzema dins del contenidor de Windows Hello i s'usarà per autenticar-se davant de recursos locals que requereixin certificats de client (per exemple, autèntica Kerberos amb certificats o VPN IPsec).
5. Fase d'autenticació: com es “allibera” la clau
Un cop superades les fases prèvies, l'experiència diària de l'usuari és molt senzilla: per iniciar sessió o desbloquejar el dispositiu, feu servir el PIN o la biometria. Tècnicament, el que fa aquest gest és “desbloquejar” l'accés a la part privada de les credencials de WHfB emmagatzemades al TPM.
Ni el PIN ni la clau privada surten del dispositiu o s'envien a l'IdP. El PIN actua com a entropia per a les operacions de signatura amb la clau privada; en altres paraules, és un disparador local que autoritza lús de la clau. Quan una aplicació o el mateix sistema necessita autenticar-se davant d'un IdP, Windows signa un bloc de dades amb la clau privada i envia la signatura al servidor, que comprova la validesa amb la clau pública registrada.
Aquest patró es repeteix tant per a autenticació directa davant d'Entrar ID (mitjançant protocols web i el proveïdor Cloud AP) com per a autenticacions Kerberos contra Active Directory (ja sigui mitjançant clau, certificat o confiança de Kerberos al núvol).
Token d'actualització principal (PRT) i Single Sign-On (SSO)
L'SSO modern en entorns Microsoft gira al voltant del Token d'Actualització Principal o PRT. Mentre que a Kerberos clàssic el “token mestre” és el TGT, en escenaris Entra ID el PRT és un token JWT que conté informació de l'usuari i del dispositiu, i permet anar obtenint tokens d'accés per a diferents aplicacions sense que l'usuari s'hagi de tornar a autenticar explícitament.
El PRT normalment s'emet durant l'inici de sessió o desbloqueig del dispositiu quan l'usuari s'autentica amb WHfB en un equip unit a Microsoft Entra o híbrid unit a Entra. En dispositius personals només registrats, el PRT s'obté en afegir un compte professional o educatiu a Windows.
Sense PRT no hi ha SSO real cap a aplicacions protegides per Entra ID o AD FS. Si per alguna raó el dispositiu no disposa d'un PRT vàlid, els usuaris veuran sol·licituds de credencials reiterades i, a més, fracassaran les polítiques d'accés condicional que requereixin informació del dispositiu (per exemple, “només dispositius marcats com a conformes”).
A escenaris d'accés remot amb VPN i SAML SSO, quan l'usuari ja s'ha autenticat amb WHfB al sistema operatiu, el PRT permet a Entra ID “recordar” que ja s'ha satisfet la MFA resistent al phishing. Per això, durant l'inici de sessió a la VPN via SAML, Entra ID pot marcar la sessió com a MFA-compliant sense demanar un segon factor addicional, cosa que sol generar debats amb asseguradores i auditors.
Flux d'autenticació de dispositius units a Microsoft Entra cap a Entra ID
En un dispositiu unit a Entra, la cadena d'esdeveniments durant un inici de sessió amb WHfB és, simplificada, la següent:
- L'usuari descarta la pantalla de bloqueig i introdueix el PIN o la biometria al proveïdor de credencials de WHfB.
- Winlogon passa aquestes credencials a LSASS, que al seu torn les lliura al proveïdor de seguretat d'autenticació al núvol (Cloud AP).
- Cloud AP sol·licita un nunci apostòlic a Microsoft Entra ID; Entra ID respon amb aquest valor.
- El client signa el nonce amb la clau privada de l'usuari i envia el resultat a Entra ID.
- Entra ID verifica la signatura amb la clau pública prèviament registrada, i si tot és correcte genera un PRT, xifrat amb la clau de transport del dispositiu.
- Cloud AP desxifra la clau de sessió del PRT usant la clau de transport privada (protegida per TPM) i desa el PRT en memòria cau protegida.
- LSASS informa Winlogon que l'autenticació ha estat satisfactòria i es crea la sessió d'usuari.
Des d'aquest moment, el PRT es farà servir per aconseguir tokens d'accés i actualització per a diferents aplicacions (Microsoft 365, SaaS de tercers, aplicacions SAML, etc.) sense que l'usuari hagi de tornar a escriure res, sempre subjecte a les polítiques d'accés condicional configurades.
Autenticació de Windows Hello for Business davant Active Directory
Quan el dispositiu només és “unit a Entra” però necessita accedir a recursos locals, entra en joc la integració amb Active Directory a través de diferents models: confiança Kerberos al núvol, key trust i certificate trust. Tots ells permeten que una credencial de WHfB generi vals Kerberos sense necessitat de contrasenyes.
Confiança de Kerberos al núvol amb Microsoft Entra
Al model de Cloud Kerberos Trust, Microsoft Entra ID emet un TGT parcial associat a la identitat de l'usuari i signat pel servei de Kerberos al núvol. Quan el dispositiu necessita un TGT complet d'un controlador de domini on premis, envia aquest TGT parcial al KDC local, que el valida i emet un TGT “real” per a l'usuari.
Aquest enfocament simplifica força la infraestructura, perquè delega a Entra ID part de la lògica d'autenticació, però exigeix que els controladors de domini estiguin actualitzats i correctament configurats per reconèixer i validar aquests TGT parcials procedents del núvol.
Model de confiança mitjançant clau (Key Trust)
Al model key trust, el controlador de domini valida directament una signatura realitzada amb la clau privada de l'usuari registrada a Active Directory. El flux d'alt nivell és:
- El proveïdor Kerberos al client signa les dades de preautenticació amb la clau privada i envia la signatura juntament amb la clau pública (en un certificat autosignat) al KDC.
- El KDC comprova que el certificat és autosignat, localitza aquesta clau pública a l'atribut
msDS-KeyCredentialLinkde l'usuari i valida la signatura. - Si tot quadra (UPN, claus, signatura), el KDC torna un TGT al client.
Després, el client valida el certificat del KDC (cadena fins a una arrel de confiança, EKU d'autenticació KDC, nom alternatiu que coincideixi amb el domini, algorismes segurs com SHA-256 i RSA 2048, etc.) abans d'acceptar aquest TGT i emmagatzemar-lo en memòria cau per a futures peticions de vals de servei.
Model de confiança mitjançant certificat (Certificate Trust)
Al model basat en certificats, l'usuari presenta al KDC un certificat de client emès per la CA de l'organització. Kerberos utilitza la informació del certificat (DN del subjecte o UPN al SAN) com a pista per localitzar el compte a Active Directory.
El controlador de domini valida la cadena de certificats fins a una arrel de confiança, comprova que el certificat està dins del seu període de validesa i no s'ha revocat, i utilitza la clau pública del certificat per verificar les dades de preautenticació signades. Si tot és correcte, emet el TGT, que el client accepta després de verificar el certificat del KDC.
Requisits d'infraestructura per a entorns híbrids segurs
Aconseguir que un dispositiu unit a Microsoft Entra s'autentiqui correctament a Active Directory implica prestar molta atenció a la configuració de la PKI corporativa, els punts de distribució de CRL i la confiança en certificats de controlador de domini.
Punts de distribució de llistes de revocació (CDP/CRL)
Un error molt habitual és deixar el CDP només a LDAP dins del domini. Els dispositius units a Entra ID que no formen part del domini no poden llegir aquesta ruta LDAP abans d'autenticar-se, cosa que genera un bucle: necessiten validar el certificat del DC per autenticar-se, però no poden llegir la CRL sense haver-se autenticat.
La solució recomanada és publicar la CRL en un punt accessible per HTTP sense autenticació, normalment un lloc web intern, i afegir aquesta URL com a CDP als certificats de la CA i dels controladors de domini. El procés implica:
- Configurar un servidor web (IIS) amb un directori virtual (per exemple,
cdp) i habilitar l'exploració de directoris. - Ajustar permisos NTFS i de recurs compartit perquè la CA pugui publicar automàticament els fitxers de CRL en aquest directori.
- Actualitzar la configuració de la CA per incloure la nova URL HTTP com a CDP i com a ubicació de publicació de CRL i delta CRL.
- Torneu a emetre els certificats dels controladors de domini perquè incloguin el nou CDP HTTP.
Després d'aquests passos, els dispositius units a Entra poden validar el certificat del DC sense haver d'estar autenticats, eliminant el problema circular i permetent que l'autenticació basada en certificats o en clau funcioni correctament.
Requisits dels certificats de controlador de domini
Perquè Windows Hello per a Empreses apliqui la “validació estricta de KDC” en autenticar-se des d'un dispositiu unit a Entra, els certificats dels controladors de domini han de complir diversos criteris:
- La CA arrel emissora ha d'estar al magatzem de entitats de certificació arrel de confiança de el dispositiu.
- El certificat s'ha de basar en la plantilla d'autenticació Kerberos adequada.
- Heu d'incloure l'EKU de autenticació de KDC.
- El nom alternatiu del subjecte (SAN) ha de contenir un nom DNS que coincideixi amb el domini.
- L'algorisme de signatura ha de ser SHA-256 i la clau pública ha de ser RSA d'almenys 2048 bits.
Si falla alguna cosa, els dispositius units a Entra poden rebutjar el certificat del DC i l'autenticació amb WHfB cap a Active Directory no funcionarà, fins i tot encara que amb contrasenyes clàssiques sí que sembli anar tot bé.
Distribució del certificat arrel de la CA en dispositius units a Entra
Perquè confiïn en els certificats dels controladors de domini, els dispositius units a Microsoft Entra han de tenir instal·lat el certificat arrel de la CA d'empresa. Normalment s'exporta aquest certificat des d'un controlador de domini i es desplega als equips mitjançant Microsoft Intune amb una directiva de “certificat de confiança”.
La directiva ha d'apuntar al magatzem de certificats d'equip (arrel de confiança) i assignar-se als grups dusuaris o dispositius adequats. Un cop aplicada, els equips veuran com a “de confiança” els certificats emesos per aquesta CA, inclòs el dels KDC, i la validació estricta podrà completar-se correctament.
Models de desplegament, reptes i bones pràctiques
Windows Hello per a Empreses admet desplegaments només al núvol, híbrids o totalment locals, i cada model té implicacions pràctiques diferents en termes de complexitat, compatibilitat i costos.
En organitzacions cloud-first sense Active Directory on-premises, el més senzill és un model només núvol on tot el govern de claus i autenticació es realitza des de Microsoft Entra ID, sense necessitat de PKI local ni AD FS. Els usuaris accedeixen via SSO a Microsoft 365 ia aplicacions SaaS amb WHfB com a autenticador sense contrasenya.
A la majoria d'empreses mitjanes i grans, l'escenari més realista continua sent l'híbrid: recursos crítics segueixen en local, existeixen aplicacions Kerberos pures i, alhora, es consumeixen serveis al núvol. Aquí és on cal decidir entre confiança Kerberos al núvol, key trust i certificate trust, avaluar compatibilitat d'aplicacions heretades i, en molts casos, continuar convivint amb mètodes basats en contrasenya o targetes intel·ligents durant un temps.
En sectors molt regulats o amb requisits extrems de sobirania de dades (govern, certes entitats financeres o sanitàries), pot tenir sentit un model totalment local amb AD FS i PKI pròpia, on WHfB es fa servir com a substitut de contrasenyes però sense dependre del núvol. A canvi, la complexitat operativa i de manteniment és més gran.
En tots els casos, hi ha reptes comuns: maquinari compatible, estacions de treball compartides, resistència dels usuaris al canvi, i justificar davant d'asseguradores i auditors que WHfB realment compta com a MFA. La clau és combinar WHfB amb polítiques d'accés condicional que requereixin autenticadors resistents al phishing, habilitar reautenticació o step-up MFA on sigui raonable (per exemple, en operacions molt sensibles o connexions VPN crítiques) i documentar bé el model d'amenaces.
Si us acompanyeu d'una bona capacitació, polítiques clares de PIN, supervisió d'inicis de sessió i un desplegament esglaonat recolzat a Intune o GPO, Windows Hello per a Empreses permet a les organitzacions fer un salt qualitatiu cap a un model d'identitat sense contrasenyes, reduint la superfície d'atac, millorant el compliment normatiu i oferint als usuaris una experiència d'inici de sessió molt més natural i ràpida.
