Windows Hello for Business: modelos de confianza y PIN
Despliega Windows Hello for Business con confianza de Kerberos en la nube o de clave, exige claves en el TPM, define la directiva de PIN y verifica el aprovisionamiento.
Las contraseñas son la credencial que los atacantes roban con más frecuencia: por phishing, password spraying, keyloggers, volcados de memoria o reutilización de otra filtración. Windows Hello for Business sustituye la contraseña en el inicio de sesión de Windows por un par de claves asimétricas generado en el dispositivo y protegido por su TPM. El usuario desbloquea la clave con un PIN o un gesto biométrico; la clave privada nunca sale del dispositivo y no hay nada reutilizable que robar por phishing.
Esta guía cubre las decisiones que importan para la seguridad: qué modelo de confianza usar, cómo forzar claves respaldadas por hardware, cómo definir la directiva de PIN y cómo confirmar que los usuarios y administradores inician sesión realmente con Hello y no recurren a la contraseña. Se apoya en la serie Protección de credenciales, donde Credential Guard protege lo que queda en memoria.
Cómo funciona, en resumen
Durante el aprovisionamiento, Windows crea un par de claves en el TPM para el usuario y registra la clave pública en Microsoft Entra ID (y, según el modelo de confianza, en Active Directory). Al iniciar sesión, el usuario desbloquea la clave privada localmente y la usa para autenticarse: ante Entra ID para obtener un Primary Refresh Token y ante Active Directory para obtener un ticket Kerberos. El PIN es un gesto de desbloqueo local, no un secreto compartido.
Dos propiedades lo hacen valioso:
- Resistencia al phishing. No hay contraseña que escribir en una página falsa, y la clave solo funciona en el dispositivo donde se creó.
- Ningún secreto reutilizable en la red. Un atacante que capture el tráfico o retransmita la autenticación no obtiene nada que funcione en otro lugar.
Paso 1: elegir el modelo de confianza
En los entornos híbridos (AD + Entra ID), el modelo de confianza determina cómo un inicio de sesión con Hello obtiene un ticket Kerberos de tus controladores de dominio.
| Modelo | Cómo funciona la autenticación local | Requiere | Uso típico |
|---|---|---|---|
| Confianza de Kerberos en la nube (cloud Kerberos trust) | Entra ID emite un ticket parcial; el DC local lo canjea por un TGT completo | Objeto de servidor Kerberos de Entra en AD, DC y clientes compatibles | Recomendado para entornos híbridos |
| Confianza de clave (key trust) | Clave pública sincronizada con AD (msDS-KeyCredentialLink); el DC la valida con PKINIT | Certificados en los DC, sincronización de claves con Entra Connect | Entornos que no pueden usar la confianza de Kerberos en la nube |
| Confianza de certificado (certificate trust) | El usuario recibe un certificado emitido por AD CS | PKI empresarial, AD FS como entidad de registro de certificados, autenticación federada | Escenarios que necesitan un certificado de usuario, como algunos usos de RDP |
La confianza de Kerberos en la nube elimina los dos problemas habituales: no hace falta PKI para las claves de Hello ni hay retraso en el aprovisionamiento mientras la clave pública se sincroniza con AD. Sus requisitos son concretos: Windows 10 21H2 con KB5010415 o Windows 11 21H2 con KB5010414 o posterior en los clientes; controladores de dominio con Windows Server 2016 con KB4534307, Server 2019 con KB4534321, o Server 2022/2025; suficientes controladores de dominio de escritura en cada sitio donde se autentican los usuarios; y usuarios sincronizados con Entra ID. Los miembros de grupos integrados privilegiados (Domain Admins y similares) no pueden usarla, porque la directiva de replicación de contraseñas del objeto AzureADKerberos los deniega, y Microsoft desaconseja relajarla.
Los despliegues solo en la nube (unidos a Entra, sin AD local) no necesitan ningún modelo de confianza.
Paso 2: crear el objeto Kerberos de Entra (confianza de Kerberos en la nube)
La confianza de Kerberos en la nube se basa en un objeto de tipo controlador de dominio de solo lectura en cada dominio, que permite a Entra ID emitir tickets Kerberos parciales en los que confían tus DC. Créalo desde una máquina con el módulo AzureADHybridAuthenticationManagement, como miembro de Domain Admins (y de Enterprise Admins para el bosque) y con una cuenta de Entra que tenga el rol Hybrid Identity Administrator:
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
$domain = $env:USERDNSDOMAIN
$upn = "admin@contoso.com"
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upnEsto crea un objeto de equipo AzureADKerberos en la OU Domain Controllers y una cuenta krbtgt_AzureAD. Trata ambos como activos de Tier 0: la clave de krbtgt_AzureAD permite a quien la controle influir en la emisión de tickets. Rótala periódicamente con el mismo módulo (Set-AzureADKerberosServer -RotateServerKey) y mantén las cuentas de Entra que pueden administrarla dentro de tu modelo de administración de Tier 0.
Paso 3: configurar la directiva
Con directiva de grupo, la configuración está en Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Hello for Business:
| Configuración | Valor | Motivo |
|---|---|---|
| Use Windows Hello for Business | Enabled | Activa el aprovisionamiento |
| Use cloud Kerberos trust for on-premises authentication | Enabled | Confianza de Kerberos en la nube (déjala sin establecer para la confianza de clave; Use certificate for on-premises authentication debe quedar sin configurar o ganará la confianza de certificado) |
| Use a hardware security device | Enabled, y marca Do not allow TPM 1.2 | Rechaza las claves de software; consulta el paso 4 |
| Use biometrics | Enabled o Disabled según tu directiva | Reconocimiento facial y huella dactilar como gestos de desbloqueo |
En Intune puedes establecer un valor predeterminado para todo el inquilino en Devices > Enrollment > Windows Hello for Business, pero para tener control y segmentación usa una directiva de Endpoint security > Account protection o el catálogo de configuración. Ambos usan el CSP PassportForWork, con configuraciones como Use Windows Hello For Business, Use Cloud Trust For On Prem Auth y Require Security Device. Evita configurar el mismo dispositivo a la vez desde el valor predeterminado del inquilino y desde una directiva segmentada, porque complica la resolución de problemas. Si un dispositivo recibe configuración de Windows Hello for Business tanto de directiva de grupo como de Intune, gana la directiva de grupo y la configuración de Intune se ignora.
Paso 4: exigir claves respaldadas por el TPM
Si un dispositivo no tiene un TPM utilizable, Windows puede recurrir a una clave de software, un objetivo mucho más fácil para el malware que se ejecuta como el usuario o para un atacante que tenga el disco. Use a hardware security device (Intune: Require Security Device) impide esa alternativa: los dispositivos sin un TPM adecuado no aprovisionan Hello en absoluto.
Comprueba el estado del TPM antes de imponerlo, sobre todo en equipos de sobremesa antiguos y VM:
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, ManufacturerVersionRechazar el TPM 1.2 evita chips antiguos con algoritmos más débiles y un historial de problemas de firmware. El mismo TPM protege las claves de BitLocker, así que un inventario de TPM sirve para ambos proyectos.
En el hardware con Windows 11 que lo admite, Enhanced Sign-in Security añade aislamiento VBS para los datos biométricos y la ruta de inicio de sesión. Depende de sensores y firmware concretos, así que comprueba la compatibilidad de los dispositivos antes de incluirla como requisito.
Paso 5: definir la directiva de PIN
La complejidad del PIN está en Computer Configuration > Policies > Administrative Templates > System > PIN Complexity (Intune: configuración PIN Complexity en el mismo perfil de protección de cuentas).
| Configuración | Recomendado | Notas |
|---|---|---|
| Minimum PIN length | 6 | El valor predeterminado es 6. Más largo aporta poco porque el TPM limita los intentos |
| Maximum PIN length | 127 (predeterminado) | No limites a los usuarios que quieran un PIN más largo |
| Require digits / lowercase / uppercase / special characters | Dígitos permitidos; el resto opcional | La complejidad añade fricción sin mucha seguridad en una clave vinculada al TPM |
| Expiration | Sin configurar | Los cambios de PIN forzados empujan a los usuarios hacia patrones predecibles |
| History | 0 salvo que una auditoría lo exija | Solo es relevante si se usa la caducidad |
La verdadera protección frente a los intentos de adivinar es el antimartilleo del TPM, que bloquea tras varios PIN incorrectos seguidos. Mantén los valores predeterminados salvo que tengas un motivo concreto.
Habilita la recuperación del PIN (Use PIN Recovery en la directiva, EnablePinRecovery en el CSP) para que los usuarios puedan restablecer un PIN olvidado mediante el servicio de restablecimiento de PIN de Microsoft sin destruir y volver a aprovisionar su clave. Así, "he olvidado mi PIN" no se convierte en un restablecimiento de contraseña por el soporte técnico.
Paso 6: los administradores y la contraseña que queda
Windows Hello no elimina la contraseña del usuario; hace que deje de escribirla. Para obtener todo el beneficio:
- Habilita la experiencia sin contraseña, que oculta el proveedor de credenciales de contraseña para el último usuario que inició sesión con Hello o con una llave FIDO2 (
Authentication/EnablePasswordlessExperienceen el Policy CSP). Requiere Windows 11 22H2 con KB5030310 o posterior, unión a Microsoft Entra y administración MDM; los dispositivos con unión híbrida y los unidos a AD quedan fuera del alcance. - Para los administradores, aprovisiona Hello para la cuenta de administración del nivel en la PAW y usa el acceso condicional para exigir autenticación resistente al phishing a los roles de administración en Entra ID. Con la confianza de Kerberos en la nube, las cuentas de Tier 0 de los grupos integrados privilegiados no pueden obtener así un TGT local, de modo que planifica otro método de inicio de sesión para ellas, como las tarjetas inteligentes.
- Recuerda que RDP hacia un servidor suele seguir necesitando una credencial que el servidor acepte. Remote Credential Guard puede usar tu inicio de sesión con Hello porque las solicitudes Kerberos se quedan en el cliente; prueba tu combinación concreta.
Qué se rompe
- Los dispositivos sin un TPM utilizable no aprovisionan en cuanto se exigen claves de hardware.
- Los usuarios que nunca han iniciado sesión en la red corporativa, con la confianza de clave, pueden tener que esperar a la sincronización de la clave antes de que funcionen los recursos locales. La confianza de Kerberos en la nube evita este retraso.
- Los dispositivos compartidos por muchas personas: cada usuario aprovisiona su propia clave y hay un límite de registros de Hello por dispositivo.
- Las aplicaciones que piden directamente la contraseña de Windows (clientes VPN antiguos, algunas aplicaciones de negocio) en lugar de usar el inicio de sesión integrado.
Verificarlo
- Estado del aprovisionamiento. Ejecuta
dsregcmd /statuscomo el usuario. En User State,NgcSet : YESsignifica que existe una clave de Hello. Para la confianza de Kerberos en la nube,OnPremTgt : YES(en SSO State) muestra que el usuario recibió un ticket local a través de Entra ID. - Eventos de aprovisionamiento. Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin registra si se inició el aprovisionamiento: el evento 358 cuando se cumplen los requisitos previos y el 360 cuando no, con el requisito que falla.
- Método de inicio de sesión. En los registros de inicio de sesión de Entra, filtra los inicios de sesión de Windows y comprueba que el método de autenticación sea Windows Hello for Business. Una proporción alta de inicios de sesión con contraseña en dispositivos aprovisionados significa que los usuarios están esquivando Hello.
- Cobertura respaldada por hardware. Con la directiva de dispositivo de seguridad de hardware activada, los dispositivos sin un TPM listo no aprovisionan en absoluto. Compara la cobertura de
NgcSetcon el inventario deGet-Tpmdel paso 4 para encontrar los dispositivos que nunca se inscribieron sin que nadie lo notara.
Lista de comprobación
- Modelo de confianza elegido; confianza de Kerberos en la nube para entornos híbridos salvo excepción documentada
- Objeto
AzureADKerberoscreado en cada dominio y tratado como Tier 0, rotación de clave programada - Hello habilitado desde un único origen de directiva, dispositivo de seguridad de hardware exigido, TPM 1.2 rechazado
- PIN mínimo de 6, sin caducidad, recuperación del PIN habilitada
- Administradores aprovisionados en las PAW; autenticación resistente al phishing exigida a los roles de administración
- Experiencia sin contraseña habilitada donde sea compatible
-
dsregcmdy los eventos 358/360 usados para seguir la cobertura del aprovisionamiento
Windows Hello for Business saca del uso diario la credencial más robada de Windows. Para una definición que compartir con las partes interesadas, consulta Windows Hello for Business en el glosario.
Preguntas frecuentes
¿Un PIN de Windows Hello es más débil que una contraseña?
No. El PIN solo desbloquea una clave privada guardada en el TPM del dispositivo; nunca se envía por la red y no sirve en ningún otro dispositivo. La protección antimartilleo del TPM limita los intentos. Una contraseña robada funciona desde cualquier lugar, mientras que un PIN robado solo funciona en ese dispositivo concreto y en manos del atacante. Por eso un PIN de seis dígitos respaldado por un TPM es más robusto que la mayoría de las contraseñas.
¿Qué modelo de confianza debe elegir una organización híbrida?
La confianza de Kerberos en la nube, en la mayoría de los casos. No necesita PKI para las claves de Hello, ni certificados en los controladores de dominio para el inicio de sesión con Hello, ni esperar a la sincronización de claves, y Microsoft la recomienda para los despliegues híbridos. La confianza de clave o de certificado siguen siendo pertinentes en casos concretos, como entornos solo locales o escenarios que la confianza de Kerberos en la nube no admite. Consulta la comparación actual de Microsoft antes de decidir.
¿Deben usar Windows Hello for Business los administradores?
Encaja bien para los administradores que inician sesión en su propia estación de trabajo de acceso privilegiado, porque elimina las contraseñas escritas y las credenciales susceptibles de phishing del trabajo diario de administración. Inscribe la cuenta de administración del nivel en la propia PAW, no en el portátil de un usuario. Para las cuentas de administración que deben funcionar en muchos sistemas compartidos, una llave de seguridad FIDO2 o una tarjeta inteligente suele ser más práctica, porque las claves de Hello están vinculadas a un solo dispositivo.
Windows Hello for Business: modelos de confianza y PIN