Cómo implementar Windows Hello para empresas en un dominio híbrido

Si tienes técnicos de campo o usuarios con portátiles y tablets que viven pegados al teclado táctil, lo normal es que estén hartos de escribir la contraseña una y otra vez. Windows Hello para empresas (Windows Hello for Business) precisamente nació para eso: sustituir la contraseña por métodos de inicio de sesión más cómodos y seguros, como PIN, huella o reconocimiento facial, manteniendo la integración con tu dominio y con Microsoft Entra ID (antiguo Azure AD).

El problema es que, cuando empiezas a leer documentación oficial, aparecen conceptos como modelos de implementación, tipos de confianza, Kerberos en la nube, PKI, AD FS, MFA, sincronización de claves… y es fácil agobiarse, sobre todo si no te apetece tocar demasiado los controladores de dominio. En esta guía vamos a desgranarlo con calma, explicando qué necesitas de verdad para implementar Windows Hello en un entorno de dominio (incluido híbrido) y qué partes puedes ignorar según tu escenario real.

Qué es Windows Hello para empresas y en qué se diferencia del Windows Hello “normal”

Windows Hello para empresas es la versión corporativa de Windows Hello que sustituye las contraseñas por credenciales de clave pública ligadas al dispositivo. No se limita a desbloquear el equipo: se usa también para autenticarse frente a Active Directory y/o Microsoft Entra ID.

En la práctica, el usuario inicia sesión usando un PIN, huella o reconocimiento facial, pero por debajo Windows utiliza un par de claves asimétricas almacenadas y protegidas en el dispositivo (preferentemente en el TPM) para autenticarse ante el proveedor de identidades (IdP): puede ser solo Microsoft Entra ID, un entorno híbrido o un entorno puramente local con AD FS.

La clave privada nunca sale del equipo; la clave pública se registra en Microsoft Entra ID o en AD FS durante la inscripción. A partir de ahí, el usuario puede hacer SSO contra recursos en la nube y/o recursos on‑prem según el modelo de implementación que elijas.

Modelos de implementación de Windows Hello para empresas

Antes de tocar GPOs o Intune conviene tener claro qué modelo de implementación encaja con tu entorno. Windows Hello para empresas diferencia tres grandes escenarios, en función de dónde residan las identidades y los recursos:

Solo en la nube: organizaciones que solo tienen identidades en Microsoft Entra ID y no acceden a recursos locales. Los dispositivos se unen a Microsoft Entra (Azure AD join) o se registran, y todo lo que el usuario necesita (SharePoint Online, OneDrive, apps SaaS, etc.) está en la nube. No hay controladores de dominio locales ni necesidad de certificados para VPN u otros servicios on‑prem.

Híbrida: empresas que sincronizan identidades entre Active Directory local y Microsoft Entra ID. Suelen tener dispositivos unidos a dominio tradicional, equipos Azure AD joined o híbridos, y quieren SSO tanto a recursos locales (servidores de ficheros, aplicaciones legacy) como a recursos en la nube. Es el escenario más frecuente y el más interesante cuando te preguntas cómo implementar Windows Hello en un dominio sin romper nada.

Local (on‑prem): organizaciones sin identidades en la nube ni aplicaciones en Microsoft Entra ID. Todo vive en Active Directory y las apps están integradas con AD o con AD FS. Aun así, pueden aprovechar Windows Hello para empresas para tener una experiencia sin contraseña y SSO dentro del propio entorno local.

El modelo que elijas condiciona qué servicios necesitas (por ejemplo, Microsoft Entra Connect, AD FS, PKI, Kerberos en la nube, etc.) y qué tipo de confianza vas a usar para hablar con Active Directory.

Tipos de confianza: cómo se autentica Windows Hello contra el dominio

El tipo de confianza define cómo los clientes de Windows Hello para empresas se autentican frente a Active Directory. Es un concepto clave cuando quieres que el usuario pueda usar PIN o huella en un PC unido a dominio para acceder a recursos on‑prem.

Importante: el tipo de confianza solo aplica cuando hay Active Directory local. Para autenticarse en Microsoft Entra ID, Windows Hello siempre utiliza clave (no certificado), salvo escenarios específicos de tarjeta inteligente en entornos federados.

Los tres tipos de confianza que puedes elegir son:

1. Confianza Kerberos en la nube (Cloud Kerberos Trust)
En este modelo, los usuarios obtienen su TGT de Active Directory a través de Microsoft Entra Kerberos. Microsoft Entra ID emite un ticket que los controladores de dominio locales aceptan, y estos siguen emitiendo tickets de servicio Kerberos y realizando la autorización. Es el mismo mecanismo usado para el inicio de sesión con llaves de seguridad FIDO2.

Las ventajas clave de la confianza Kerberos en la nube son:

• No necesitas desplegar una PKI ni tocar tu infraestructura de certificados existente.
• No hay que sincronizar claves públicas entre Microsoft Entra ID y Active Directory para que el usuario acceda a recursos locales, así que no hay retraso entre la inscripción de Windows Hello y la capacidad de autenticarse en el dominio.
• Permite habilitar inicio de sesión con claves de seguridad FIDO2 con una configuración adicional muy ligera.

Eso sí, la confianza Kerberos en la nube requiere que implementes Microsoft Entra Kerberos y que cumplas con versiones mínimas de Windows y Windows Server (lo veremos más adelante en requisitos de sistema).

2. Confianza de clave (Key trust)
En este caso, los usuarios se autentican frente al Active Directory local usando una clave ligada al dispositivo creada durante la inscripción de Windows Hello. El cliente solicita un TGT de Kerberos utilizando esa clave. Para que esto funcione, es necesario distribuir ciertos certificados a los controladores de dominio, ya que Kerberos va a usar autenticación basada en certificados hacia el DC.

Este modelo no emite certificados de usuario final: la credencial de usuario sigue siendo la clave asimétrica protegida por el dispositivo, pero los DC necesitan certificados para que los equipos Windows los reconozcan como entidades de confianza.

3. Confianza de certificado (Certificate trust)
Aquí se van un paso más allá: se emiten certificados de autenticación a los usuarios. Durante la inscripción, el usuario solicita un certificado mediante una clave ligada al dispositivo (generada por Windows Hello). Después, el inicio de sesión y las peticiones de TGT Kerberos se basan en ese certificado de usuario, respaldado por tu PKI corporativa.

Este modelo requiere una PKI empresarial bien montada y una entidad de registro de certificados (CRA). En implementaciones federadas, AD FS suele actuar como CRA. Además, en entornos híbridos hace falta habilitar la “escritura diferida de dispositivos” (device writeback) en Microsoft Entra Connect.

Punto importante: ninguno de estos tipos de confianza es intrínsecamente más seguro que otro; la elección depende de tu infraestructura actual, de si ya tienes PKI, de si quieres o no añadir AD FS, y de lo dispuesto que estés a tocar los controladores de dominio.

Requisitos de PKI según el modelo y tipo de confianza

Una de las preguntas típicas al hablar de Windows Hello en dominio es si hace falta montar una PKI completa para que funcione. La respuesta depende totalmente de tu modelo de implementación y del tipo de confianza elegido:

La confianza Kerberos en la nube es la única opción híbrida que no requiere certificados. Si puedes ir a este modelo, te ahorras tener que desplegar CA corporativas para los controladores de dominio y los usuarios. Esto lo hace especialmente atractivo para entornos que no quieren complicarse con PKI.

En cambio, en los modelos híbridos basados en Key trust o Certificate trust, así como en los modelos puramente locales, sí necesitas PKI:

• Los controladores de dominio de entornos híbridos y locales necesitan un certificado para que los clientes Windows puedan confiar en ellos al validar la autenticación basada en certificados.
• Si usas confianza de certificado, necesitas una PKI corporativa y una entidad de registro de certificados (CRA) para emitir certificados de usuario. AD FS hace de CRA en muchos despliegues.
• En algunos entornos híbridos tendrás que emitir certificados VPN a los usuarios, si su acceso a recursos locales pasa por túneles que dependen de certificados.

Por tanto, si te da “yuyu” tocar el controlador de dominio y tu entorno ya está sincronizado con Microsoft Entra ID, lo más práctico suele ser apostar por Kerberos en la nube, que simplifica mucho la infraestructura.

Autenticación frente a Microsoft Entra ID

Windows Hello para empresas también se usa para autenticar al usuario en Microsoft Entra ID, independientemente de cómo hables con Active Directory. Aquí entran en juego dos grandes opciones: autenticación federada (por ejemplo, con AD FS) o autenticación en la nube (PHS/PTA).

Según el modelo de implementación y tipo de confianza, se imponen ciertos requisitos:

• Solo nube: se utiliza autenticación en la nube por defecto. Puedes optar por autenticación federada con un IdP de terceros si quieres, pero Windows Hello funciona sin problema con autenticación en la nube estándar.
• Híbrido con confianza Kerberos en la nube o Key trust: puedes usar sincronización de hash de contraseña (PHS), autenticación de paso a través (PTA) o federación (AD FS u otros IdP), según tu diseño actual.
• Híbrido con confianza de certificado: requiere autenticación federada con AD FS; no es compatible con PHS ni PTA. Aquí AD FS es pieza central.

Si tu tenant ya está montado con PHS o PTA y no quieres tocar AD FS, la confianza Kerberos en la nube o el modelo Key trust encajan mejor. Si en cambio ya usas federación con AD FS para todo, la confianza de certificado puede ser una opción natural.

Registro de dispositivos según el modelo

Otro bloque clave es el registro de dispositivos, que determina quién lleva el control de los equipos para emitir tokens y permitir SSO.

En entornos locales, el servidor con rol de AD FS se encarga del registro de dispositivos. Es quien gestiona la relación de confianza con los equipos y emite los tokens necesarios para que Windows Hello para empresas funcione dentro del dominio on‑prem.

En entornos híbridos o solo nube, los dispositivos deben registrarse en Microsoft Entra ID, ya sea como:

• Microsoft Entra unidos (Azure AD joined).
• Microsoft Entra unidos a híbridos (híbrido AD join).
• Microsoft Entra registrados (habitual en BYOD).

El tipo de combinación (join) condiciona qué capacidades tienes: por ejemplo, los dispositivos híbridos permiten SSO tanto a la nube como a on‑prem sin que el usuario tenga que hacer malabares con distintas credenciales.

Autenticación multifactor (MFA) en el aprovisionamiento

Uno de los objetivos principales de Windows Hello para empresas es alejarse de las contraseñas tradicionales, proporcionando una credencial fuerte respaldada por dispositivos seguros. Para lograrlo, el proceso de aprovisionamiento exige dos factores de autenticación.

La idea es que las credenciales débiles (usuario y contraseña) se usen solo como primer factor, mientras que el segundo factor lo aporta una solución MFA. Windows no genera la credencial de Windows Hello para empresas hasta que el usuario complete correctamente el MFA.

En entornos híbridos y solo nube, puedes usar:

• Microsoft Entra MFA integrado.
• Soluciones MFA de terceros, ya sea como método de autenticación externa en Microsoft Entra ID o a través de un IdP federado.

En entornos locales sin Microsoft Entra ID, necesitarás una opción MFA que se integre como adaptador de MFA de AD FS. Microsoft y otros fabricantes ofrecen adaptadores específicos para esto.

Además, en dominios federados puedes ajustar la marca FederatedIdpMfaBehavior, que indica a Microsoft Entra ID si debe aceptar, exigir o rechazar el MFA que viene del IdP federado. Esta configuración se revisa y modifica con comandos de PowerShell como Get-MgDomainFederationConfiguration y Update-MgDomainFederationConfiguration.

Configuración de directivas: GPO vs CSP

Para que los usuarios puedan usar Windows Hello para empresas en sus dispositivos, necesitas configurar las directivas adecuadas. Hay dos mecanismos principales:

• Proveedor de servicios de configuración (CSP): ideal para dispositivos gestionados vía MDM como Microsoft Intune. Permite empujar políticas de Windows Hello mediante perfiles de configuración, e incluso con paquetes de aprovisionamiento.
• Directiva de grupo (GPO): usada para equipos unidos a dominio que no están gestionados por MDM o donde prefieras seguir con la gestión tradicional on‑prem.

En cualquier modelo (solo nube, híbrido o local) puedes usar CSP, GPO o una combinación, según cómo administres los equipos. Por ejemplo, puedes gestionar portátiles unidos a dominio mediante Intune (híbrido) y a la vez aplicar alguna configuración base vía GPO o mediante administración remota segura.

En un despliegue por GPO clásico, hay una directiva clave obligatoria para habilitar Windows Hello para empresas en un modelo de confianza de clave, y otra directiva muy recomendable:

• Ruta equipo: Configuración del equipo → Plantillas administrativas → Componentes de Windows → Windows Hello para empresas → Usar Windows Hello para empresas (habilitada).
• Ruta usuario: Configuración de usuario → Plantillas administrativas → Componentes de Windows → Windows Hello para empresas → Usar Windows Hello para empresas (habilitada si quieres forzarlo por usuario).
• Adicional: Usar un dispositivo de seguridad de hardware, para obligar al uso de TPM y mejorar la protección de las claves.

Si aplicas la configuración en el nodo Equipo, todos los usuarios que inicien sesión en esos dispositivos serán forzados a intentar inscribirse en Windows Hello para empresas. Si la aplicas en el nodo Usuario, solo los usuarios destinatarios verán la experiencia de inscripción. Cuando exista conflicto, las directivas de usuario tienen prioridad sobre las de equipo.

Las GPO se pueden vincular al dominio o a OUs específicas, filtrar por grupos de seguridad o incluso por filtros WMI para segmentar bien qué máquinas entran en el despliegue. Y además de estas opciones básicas, hay un buen número de directivas detalladas de Windows Hello (por ejemplo, complejidad del PIN, tiempo de bloqueo, uso de biometría) que puedes ajustar según la política de seguridad de tu empresa.

Proceso de inscripción y experiencia de usuario

Desde el punto de vista del usuario, el proceso de configuración de Windows Hello para empresas es bastante guiado. El aprovisionamiento arranca justo después de cargar el perfil de usuario y antes de que vea el escritorio, siempre que se cumplan todos los requisitos previos de la infraestructura y las directivas.

Si quieres verificar si las comprobaciones previas se han superado, puedes revisar el registro de administrador de dispositivos de usuario en el Visor de eventos: Registros de aplicaciones y servicios → Microsoft → Windows. Otra opción es usar dsregcmd.exe /status en una consola para ver el estado de registro del dispositivo y su relación con Microsoft Entra ID.

Los pasos que sigue el usuario durante la inscripción suelen ser:

1. Si el dispositivo soporta autenticación biométrica (lector de huellas, cámara compatible), Windows pedirá al usuario que configure un gesto biométrico. Este gesto servirá para desbloquear el dispositivo y autenticarse ante recursos que acepten Windows Hello para empresas. El usuario puede saltarse este paso si prefiere usar solo PIN.
2. Windows informa de que va a usar Windows Hello con la cuenta corporativa y el usuario debe aceptar.
3. Comienza la fase de autenticación multifactor. Windows indica al usuario que está intentando comunicarse con él a través del método MFA configurado (por ejemplo, app del móvil, llamada o SMS). El aprovisionamiento no continúa hasta que el MFA se completa, falla o expira. Si el MFA falla o expira, el usuario recibe un mensaje de error y se le invita a reintentarlo.
4. Tras un MFA correcto, el sistema pide al usuario que cree y valide un PIN. Este PIN debe cumplir las directivas de complejidad configuradas (longitud mínima, restricción de dígitos repetidos, etc.).
5. Por último, Windows solicita un par de claves asimétricas para el usuario, idealmente generado y protegido dentro del TPM (o de forma obligatoria si así lo marcaste en la directiva). Una vez generadas las claves, Windows registra la clave pública con el IdP (Microsoft Entra ID o AD FS, según el modelo). Al completarse el registro de claves, el asistente informa de que el usuario ya puede usar su PIN o biometría para iniciar sesión, y este cierra la app de aprovisionamiento y accede al escritorio.

En documentación oficial suele haber diagramas de secuencia y vídeos donde se muestran todos estos pasos, incluyendo ejemplos con adaptadores de MFA personalizados para AD FS. Son útiles para entender las llamadas entre el cliente, el IdP, los DC y el servicio MFA.

Registro de claves y sincronización de directorios

En el corazón de Windows Hello para empresas está la creación y registro del par de claves asimétricas. El aprovisionamiento genera una clave privada ligada al dispositivo (normalmente almacenada en TPM) y registra la clave pública en el proveedor de identidad adecuado:

• Modelos solo nube: la clave pública se registra en Microsoft Entra ID.
• Modelos híbridos: también se registra en Microsoft Entra ID; después, Microsoft Entra Connect Sync se encarga de sincronizar la clave pública con Active Directory.
• Modelos locales: la clave pública se registra en AD FS, que hace de proveedor de identidad para el entorno on‑prem.

En modelos híbridos, Microsoft Entra Connect no solo sincroniza usuarios y dispositivos, sino también las credenciales públicas de Windows Hello, permitiendo que el usuario consiga SSO contra recursos locales mediante esa credencial fuerte, sin necesidad de volver a usar la contraseña.

En modelos puramente locales que utilizan Azure MFA como solución multifactor, se puede usar sincronización de directorios para importar usuarios desde Active Directory al servidor de Azure MFA, que a su vez se comunica con el servicio en la nube de MFA para validar el segundo factor.

Requisitos de sistema operativo

En cuanto a versiones de Windows, todas las versiones de cliente que estén oficialmente soportadas por Microsoft pueden usar Windows Hello para empresas. Sin embargo, la confianza Kerberos en la nube sí marca mínimos específicos:

• Windows 10 21H2 con la actualización KB5010415 o posterior.
• Windows 11 21H2 con la actualización KB5010414 o posterior.

Para otros tipos de confianza (Key y Certificate) en modelos híbridos o locales, todas las versiones de Windows cliente admitidas son válidas, siempre que reciban actualizaciones de seguridad.

Respecto a los controladores de dominio, Windows Hello para empresas funciona con todas las versiones de Windows Server que sigan en soporte, pero la confianza Kerberos en la nube vuelve a tener requisitos mínimos:

• Windows Server 2016 con KB4534307 o posterior.
• Windows Server 2019 con KB4534321 o posterior.
• Windows Server 2022.
• Windows Server 2025.

En cualquier caso, el nivel funcional mínimo de bosque y dominio debe ser Windows Server 2008 R2 para todos los modelos de implementación. Si todavía tienes dominios con niveles funcionales anteriores, tocará actualizarlos antes de plantear un despliegue serio de Windows Hello para empresas.

Licenciamiento y requisitos de servicios en la nube

En el plano de licencias, Windows Hello para empresas en sí no exige directamente Microsoft Entra ID P1 o P2. No obstante, algunas características relacionadas (como la inscripción automática en MDM, ciertas políticas de acceso condicional o device writeback) sí pueden requerir niveles P1/P2.

Algunos puntos clave de licenciamiento son:

• Puedes desplegar Windows Hello para empresas con el nivel gratuito de Microsoft Entra ID. Todas las cuentas gratuitas pueden usar Microsoft Entra MFA para las características sin contraseña de Windows.
• Los dispositivos gestionados mediante MDM (Intune u otros) no requieren P1/P2 solo por usar Windows Hello; sin embargo, sin P1/P2 la inscripción MDM puede no ser automática y los usuarios deberán inscribirse manualmente en la solución MDM.
• Si usas el modelo de confianza de certificado en híbrido, necesitarás al menos Microsoft Entra ID P1 para habilitar características como device writeback y la inscripción de certificados mediante la entidad de registro de AD FS.
• En entornos locales, si decides usar Azure MFA como solución multifactor, tendrás que contar con las licencias correspondientes de Azure MFA o paquetes que lo incluyan.

Resumiendo: para muchos despliegues de tipo híbrido con Kerberos en la nube o Key trust no es obligatorio contar con P1/P2, pero si quieres aprovechar al máximo la gestión moderna, acceso condicional avanzado y device writeback, esas suscripciones sí pasan a ser relevantes.

Cómo encaja todo esto en un caso real: tablets unidas de forma híbrida

En un entorno típico de técnicos de campo con tablets Windows unidas de forma híbrida, lo normal es que:

• Los dispositivos estén unidos al dominio y registrados en Microsoft Entra ID (híbrido AD join).
• Se gestione la configuración con Intune, GPO o una mezcla de ambas.
• Se quiera habilitar inicio de sesión con huella o PIN para evitar teclear contraseñas en pantalla táctil.

En este contexto, suele ser más recomendable apostar por Kerberos en la nube que por modelos que exigen una PKI completa. No tienes que “romper” nada en los controladores de dominio más allá de instalar los parches necesarios y configurar Microsoft Entra Kerberos, y evitas complicarte con certificados de usuario y CRA.

Si ya has creado un perfil de configuración en Intune para permitir Windows Hello y ves que el sistema te ofrece configurar PIN o biometría, pero luego aparece el error “No se pudieron verificar sus credenciales” al intentar usar Windows Hello, lo más probable es que:

• No tengas completado el backend de confianza (Kerberos en la nube/Key/Certificate) para hablar con el dominio.
• O falte configurar correctamente el modelo de implementación híbrido siguiendo las guías oficiales (por ejemplo, la guía específica de hybrid cloud Kerberos trust).

La configuración global desde “Inscribir dispositivos → Inscripción de Windows” en Intune activa Windows Hello a nivel de tenant, pero no sustituye los requisitos de infraestructura de fondo (tipo de confianza, Microsoft Entra Kerberos, sincronización de directorios, etc.). De ahí que veas el asistente en el cliente pero, al validar las credenciales, falle la parte de servidor.

Lo sensato en estos casos es revisar paso a paso la documentación de despliegue de Windows Hello para empresas e hibridación con Kerberos en la nube, asegurarte de que los dispositivos aparecen bien registrados (via dsregcmd /status), de que se ha configurado Microsoft Entra Kerberos en el bosque correcto y de que las políticas (CSP/GPO) se aplican a los usuarios y equipos adecuados.

Con todas estas piezas bien alineadas —modelo de implementación claro, tipo de confianza adecuado, MFA funcionando, registro de dispositivos y claves correcto y directivas bien aplicadas— Windows Hello para empresas deja de ser un “coñazo de montar” y se convierte en una forma bastante cómoda de que tus usuarios entren al dominio con PIN, huella o cara en lugar de estar sufriendo con contraseñas eternas en teclados táctiles.