Modelos de implementación de Windows Hello para empresas 

Los modelos de implementación de Windows Hello para empresas son las tres arquitecturas que Microsoft admite para implementar la autenticación sin contraseña: solo en la nube, híbrida y local.

Cada modelo de implementación determina qué proveedor de identidades gestiona la autenticación y qué modelo de confianza está disponible para verificar a los usuarios con Active Directory. La mayoría de las organizaciones ya cuentan con la mayor parte de la infraestructura necesaria para una implementación. La confianza en Cloud Kerberos es el modelo de confianza recomendado por Microsoft para implementaciones híbridas, a menos que una organización tenga un requisito específico de autenticación basada en certificados, ya que elimina la necesidad de implementar una infraestructura de clave pública (PKI) para Windows Hello para empresas.

Puntos Clave

• Existen tres modelos de implementación: exclusivamente en la nube, híbrido y local. El modelo híbrido es el más común en empresas que utilizan tanto Active Directory como Microsoft Entra ID.
• La autenticación local se rige por tres modelos de confianza: confianza en Cloud Kerberos, confianza en certificados y confianza en claves. La confianza en Cloud Kerberos es exclusivamente híbrida y no requiere una infraestructura de clave pública (PKI).
• Microsoft recomienda la confianza en Cloud Kerberos como modelo de confianza híbrido predeterminado, a menos que se requiera específicamente la autenticación mediante certificado.
• Los administradores de dominio y otras cuentas privilegiadas no pueden usar la confianza de Cloud Kerberos de forma predeterminada debido a las restricciones de la Política de replicación de contraseñas.
• Actualmente, la implementación local se aplica a un conjunto más reducido de casos, principalmente a organizaciones que aún no están preparadas para adoptar Microsoft Entra ID.

Los tres modelos de despliegue

Windows Hello para empresas admite modelos de implementación exclusivamente en la nube, híbridos y locales. La opción más adecuada depende de dónde residan las identidades de la organización: completamente en Microsoft Entra ID, divididas entre Microsoft Entra ID y Active Directory local, o completamente en Active Directory sin presencia en la nube.

Modelo de implementación exclusivamente en la nube

El modelo de implementación exclusivamente en la nube se basa completamente en Microsoft Entra ID para la identidad y la autenticación, sin intervención de Active Directory local. Es ideal para organizaciones cuyos dispositivos se conectan únicamente a recursos en la nube como Microsoft 365, SharePoint Online y OneDrive. Dado que no existe un Active Directory local con el que autenticarse, el concepto de modelo de confianza no se aplica en esta implementación; los dispositivos se autentican directamente en Microsoft Entra ID mediante la clave de Windows Hello para empresas.

Ventajas

• Gestión simplificada: La configuración, la supervisión y las actualizaciones se realizan a través de Microsoft Entra ID e Intune, lo que reduce la carga de trabajo de los administradores de TI.
• Escalabilidad organizacionalLas organizaciones pueden agregar usuarios y dispositivos sin necesidad de invertir en infraestructura local adicional.
• Flexibilidad: Los usuarios pueden autenticarse desde cualquier lugar con conexión a internet, lo que resulta ideal para equipos de trabajo remotos y distribuidos.

Desventajas

• Dependencia de la conectividad a Internet: La autenticación requiere una conexión a Microsoft Entra ID, por lo que las interrupciones afectan al inicio de sesión.
• Preocupaciones de seguridad: Algunas organizaciones se muestran cautelosas a la hora de almacenar datos de autenticación exclusivamente en la nube, a pesar de los controles de seguridad de Microsoft.
• Privacidad de datos y cumplimientoLas organizaciones que manejan datos biométricos regulados pueden necesitar sopesar la residencia de los datos en la nube frente a sus obligaciones de cumplimiento normativo.

Modelo de implementación local

El modelo de implementación local utiliza únicamente Active Directory local, sin identidades de Microsoft Entra ID ni aplicaciones en la nube. Las preguntas frecuentes de Microsoft sobre Windows Hello para empresas describen las implementaciones locales como destinadas a organizaciones que necesitan más tiempo antes de migrar a la nube y que dependen exclusivamente de Active Directory; las organizaciones que ya utilizan los servicios en la nube de Microsoft se orientan hacia una implementación híbrida. Un caso de uso documentado para implementaciones locales son los Entornos Administrativos de Seguridad Mejorada, también conocidos como Bosques Rojos, donde las credenciales administrativas se aíslan en un bosque reforzado.

Ventajas

• Control local: Las organizaciones mantienen el control directo sobre todo Windows Hello para hacer negocios infraestructura, lo cual es importante para cumplir con los requisitos específicos de seguridad y cumplimiento.
• Residencia de datos: Los datos de autenticación permanecen dentro de los centros de datos de la propia organización, lo que puede simplificar la presentación de informes regulatorios.
• Menor dependencia de la conectividad a Internet: La autenticación puede continuar durante las interrupciones temporales de Internet, ya que no depende de Microsoft Entra ID.

Desventajas

• Desafíos de escalabilidadAmpliar la base de usuarios implica una inversión inicial en hardware y licencias, en lugar de un aumento gradual del consumo en la nube.
• Acceso remoto limitado: Los usuarios que se encuentran fuera de la red corporativa se enfrentan a requisitos de configuración adicionales, ya que no existe una capa de identidad en la nube a la que recurrir.
• Complejidad del mantenimiento: El funcionamiento de la infraestructura requiere personal informático especializado y cualificado para las actualizaciones y la resolución de problemas.

Modelo de implementación híbrido

El modelo de implementación híbrido sincroniza las identidades entre Active Directory local y Microsoft Entra ID, lo que permite a los usuarios iniciar sesión con un solo clic en ambos entornos. Es el modelo de implementación más común en las empresas, ya que la mayoría de las organizaciones aún operan con una combinación de recursos locales y en la nube. Además, el modelo híbrido es el único que admite los tres modelos de confianza, incluido el modelo de confianza Kerberos en la nube.

Ventajas

• FlexibilidadLa solución híbrida equilibra el control local con la escalabilidad en la nube, lo que resulta adecuado para organizaciones que migran gradualmente en lugar de hacerlo todo a la vez.
• Control local donde importa: El registro de dispositivos, las autoridades de certificación y el almacenamiento de claves pueden permanecer en las instalaciones de la organización para aquellas entidades con requisitos de cumplimiento específicos.
• Opciones de cumplimiento: Las organizaciones pueden elegir dónde se procesan y almacenan los datos de autenticación específicos, ya sea en sus propias instalaciones o en la nube, para cumplir con los requisitos de residencia de datos.

Desventajas

• Complejidad de configuración: La configuración híbrida requiere más planificación que una implementación en un único entorno, para integrar correctamente los componentes locales y en la nube.
• Dependencia de la conectividad a Internet: Los pasos de autenticación que dependen de la nube, incluida la confianza de Cloud Kerberos, se ven afectados por las interrupciones de Internet.
• Gastos generales de gestiónLos equipos de TI necesitan conocimientos especializados tanto en Active Directory local como en Microsoft Entra ID para supervisar y mantener el entorno.

Modelos de confianza

El modelo de confianza determina cómo se autentica un cliente de Windows Hello para empresas en Active Directory local. No afecta a la autenticación con Microsoft Entra ID, que siempre utiliza la clave de Windows Hello para empresas. Las implementaciones híbridas admiten los tres modelos de confianza: confianza en Cloud Kerberos, confianza en certificados y confianza en claves. Las implementaciones locales solo admiten la confianza en certificados y la confianza en claves, ya que la confianza en Cloud Kerberos depende de Microsoft Entra Kerberos.

Modelo de confianza clave

La autenticación mediante clave de confianza autentica a los usuarios con una clave vinculada al hardware, generada durante el proceso de aprovisionamiento integrado de Windows Hello para empresas . No se emite ningún certificado de autenticación al usuario, aunque los controladores de dominio siguen requiriendo un certificado para funcionar como raíz de confianza para los clientes.

Modelo de confianza del certificado

El modelo de confianza de certificados emite un certificado de autenticación al usuario, solicitado mediante la clave vinculada al hardware creada durante el aprovisionamiento. Requiere una infraestructura de clave pública (PKI) empresarial y una autoridad de registro de certificados, lo que lo convierte en el modelo de confianza que requiere mayor infraestructura de los tres.

Modelo de confianza Kerberos en la nube

La confianza Kerberos en la nube utiliza Microsoft Entra Kerberos para emitir un ticket de concesión de tickets directamente desde Microsoft Entra ID, lo que elimina la necesidad de implementar una infraestructura de clave pública (PKI) para Windows Hello para empresas. Microsoft lo recomienda como modelo de confianza híbrida predeterminado cuando no se requiere específicamente la autenticación mediante certificados, ya que es la única opción de confianza híbrida que no requiere la implementación de ningún certificado.

Comparación entre los modelos de confianza

La tabla que aparece a continuación compara la confianza en Cloud Kerberos, la confianza en los certificados y la confianza en las claves en función del método de autenticación, la compatibilidad con el modelo de implementación, los requisitos de PKI y las directrices actuales de Microsoft.

Criterios	Confianza Kerberos en la nube	Certificado de confianza	Fideicomiso clave
Autenticacion de usuario	Solicita un ticket de concesión de tickets Kerberos directamente desde Microsoft Entra ID mediante Microsoft Entra Kerberos.	Requiere un certificado de autenticación, emitido mediante una clave vinculada al dispositivo creada durante el aprovisionamiento.	Utiliza una clave vinculada al dispositivo creada durante el aprovisionamiento. No se emite ningún certificado al usuario.
Soporte para modelos de despliegue	Sólo híbrido	Híbrido y en las instalaciones	Híbrido y en las instalaciones
Requisito de PKI	No se requiere	Requisitos: infraestructura de clave pública (PKI) empresarial y una autoridad de registro de certificados.	Requerido únicamente para certificados de controlador de dominio.
La guía actual de Microsoft	Configuración predeterminada recomendada para implementaciones híbridas, a menos que se requiera específicamente autenticación mediante certificado.	Utilizar cuando se requiera autenticación basada en certificados.	Opción heredada, en gran medida reemplazada por la confianza en Cloud Kerberos en las nuevas implementaciones híbridas.

Algunos detalles operativos no se ajustan perfectamente a la tabla anterior, pero afectan a la selección del modelo de confianza. De forma predeterminada, los administradores de dominio y otros miembros de grupos protegidos de Active Directory no pueden usar la confianza de Cloud Kerberos ni las claves de seguridad FIDO2 para iniciar sesión en recursos locales, ya que la directiva de replicación de contraseñas del objeto de equipo Microsoft Entra Kerberos lo impide.

La confianza en Cloud Kerberos tampoco se puede usar como credencial para sesiones RDP o VDI, a menos que se registre un certificado por separado para ese fin o se use Remote Credential Guard. Las rutas de migración entre modelos de confianza no son simétricas: la migración de la confianza en clave a la confianza en Cloud Kerberos se puede realizar mediante directivas de grupo o Intune, pero no existe una ruta de migración directa de la confianza en certificado a la confianza en Cloud Kerberos, ya que el contenedor de Windows Hello para empresas existente debe eliminarse antes de la reimplementación.

Comparación entre los modelos de despliegue

Esta tabla compara los modelos de implementación locales, exclusivamente en la nube e híbridos en cuanto a control, residencia de datos, integración y escalabilidad.

Elemento	En el local	Solo en la nube	Híbrido
Control y gestión	Control local total sobre la infraestructura y los datos.	Gestionado íntegramente a través de Microsoft Entra ID e Intune.	Equilibrio entre el control local y la gestión basada en la nube.
Residencia de datos	Los datos de autenticación permanecen en las instalaciones.	Datos de autenticación almacenados en Microsoft Entra ID	Los datos de registro y políticas pueden residir en las instalaciones, en la nube o en ambos, según el modelo de confianza.
Integración:	Se integra únicamente con Active Directory local.	Depende completamente de Microsoft Entra ID.	Sincroniza las identidades de Active Directory con Microsoft Entra ID.
Escalabilidad organizacional	La escalabilidad requiere una inversión adicional en infraestructura local.	Escalable con infraestructura adicional mínima	La escalabilidad es similar a la de las soluciones exclusivamente en la nube para los componentes registrados con Entra ID, pero los componentes locales aún requieren planificación de infraestructura.

Cómo ayuda la consultoría de cifrado

Para elegir el modelo de implementación y el modelo de confianza adecuados para Windows Hello for Business, es necesario tener una visión precisa de la infraestructura de clave pública (PKI) existente en la organización, la topología de Active Directory y la configuración de Microsoft Entra ID. El equipo de servicios de PKI de Encryption Consulting evalúa primero dicho entorno y, a continuación, diseña las plantillas de certificados, las autoridades de registro y los certificados de controlador de dominio de los que dependen las implementaciones de confianza de certificados y de claves.

Para las organizaciones que planean una implementación desde cero, el servicio de implementación de Windows Hello para empresas de Encryption Consulting abarca la selección del modelo de implementación, la configuración del modelo de confianza y la implementación integral mediante Intune o directivas de grupo. Las organizaciones que deseen evitar la creación o el mantenimiento de una infraestructura de clave pública (PKI) interna pueden gestionar su infraestructura de certificados mediante PKI como servicio (PKI-as-a-Service) . Una vez emitidos los certificados, CertSecure Manager proporciona visibilidad del ciclo de vida y renovación automatizada para los certificados de controlador de dominio y de usuario, de los que depende una implementación híbrida o local.

Preguntas frecuentes

¿Qué modelo de implementación de Windows Hello para empresas debería elegir mi organización?

La solución exclusivamente en la nube es adecuada para organizaciones sin Active Directory local que dependen completamente de Microsoft Entra ID. La solución híbrida es adecuada para organizaciones que sincronizan identidades entre Active Directory y Microsoft Entra ID y necesitan inicio de sesión único para ambos, que es el escenario empresarial más común. La solución local es adecuada para organizaciones sin presencia de Microsoft Entra ID; las propias directrices de Microsoft orientan a las organizaciones que ya utilizan los servicios en la nube de Microsoft hacia un modelo híbrido.

¿Está disponible la confianza Kerberos en la nube para implementaciones locales?

No. La confianza en Cloud Kerberos depende de Microsoft Entra Kerberos y solo es compatible con implementaciones híbridas. Las implementaciones locales, que no tienen conexión con Microsoft Entra ID, solo admiten los modelos de confianza de clave y de certificado.

¿Necesito una infraestructura de clave pública (PKI) para implementar Windows Hello para empresas?

Solo para la confianza en certificados, que requiere una infraestructura de clave pública (PKI) empresarial y una autoridad de registro de certificados, o para la confianza en claves, que requiere certificados en los controladores de dominio. La confianza en Cloud Kerberos elimina la necesidad de implementar una PKI para Windows Hello for Business, por lo que Microsoft la recomienda como modelo de confianza híbrida predeterminado cuando no se requiere específicamente la autenticación mediante certificados.

¿Pueden los administradores de dominio utilizar la confianza Kerberos en la nube?

No de forma predeterminada. La directiva de replicación de contraseñas del objeto de equipo Microsoft Entra Kerberos impide que las cuentas con altos privilegios, incluidos los administradores de dominio y otros miembros de grupos protegidos, inicien sesión en recursos locales con claves de seguridad Cloud Kerberos o FIDO2. Microsoft no recomienda flexibilizar esta directiva, dado el riesgo de vulnerabilidad que introduce entre Microsoft Entra ID y Active Directory.

¿Puedo migrar directamente de la confianza en certificados a la confianza en Kerberos en la nube?

No. No existe una ruta de migración directa de la confianza en certificados a la confianza en Cloud Kerberos. El contenedor de Windows Hello para empresas existente debe eliminarse antes de que un dispositivo pueda volver a implementarse bajo la confianza en Cloud Kerberos. La migración de la confianza en claves a la confianza en Cloud Kerberos es más sencilla y puede realizarse mediante directivas de grupo o Intune sin eliminar el contenedor.

Elija el modelo de implementación adecuado con confianza.

¿Listo para planificar el despliegue de Windows Hello para empresas o solucionar un problema con un modelo de confianza híbrido? Vea los servicios PKI en acción o lea sobre los fundamentos de la infraestructura de clave pública (PKI).