Planeamiento de una implementación de Windows Hello para empresas
Esta guía de planificación te ayuda a comprender las distintas topologías, arquitecturas y componentes que abarcan una infraestructura de Windows Hello para empresas.
En esta guía se explica el rol de cada componente de Windows Hello para empresas y cómo determinadas decisiones de implementación afectan a otros aspectos de la infraestructura.
Sugerencia
Si tiene un inquilino Microsoft Entra ID, puede usar nuestro Asistente interactivo sin contraseña en línea, que le guiará por las mismas opciones en lugar de usar nuestra guía manual a continuación. El Asistente sin contraseña está disponible en el Centro de administración de Microsoft 365.
Usar esta Guía
Hay muchas opciones disponibles para implementar Windows Hello para empresas, lo que garantiza la compatibilidad con varias infraestructuras organizativas. Aunque el proceso de implementación puede parecer complejo, la mayoría de las organizaciones descubrirán que ya han implementado la infraestructura necesaria. Es importante tener en cuenta que Windows Hello para empresas es un sistema distribuido y requiere un planeamiento adecuado en varios equipos dentro de una organización.
Esta guía tiene como objetivo simplificar el proceso de implementación ayudándole a tomar decisiones informadas sobre cada aspecto de la implementación de Windows Hello para empresas. Proporciona información sobre las opciones disponibles y ayuda a seleccionar el enfoque de implementación que mejor se adapte a su entorno.
Procedimiento para continuar
Lea este documento y registre sus decisiones. Cuando haya terminado, debe tener toda la información necesaria para evaluar las opciones disponibles y determinar los requisitos de la implementación de Windows Hello para empresas.
Hay siete áreas principales que se deben tener en cuenta al planear una implementación de Windows Hello para empresas:
Opciones de implementación
El objetivo de Windows Hello para empresas es permitir implementaciones en todas las organizaciones de cualquier tamaño o escenario. Para proporcionar este tipo de implementación detallada, Windows Hello para empresas ofrece una amplia variedad de opciones de implementación.
Modelos de implementación
Es fundamental comprender qué modelo de implementación usar para una implementación correcta. Es posible que ya se hayan decidido algunos aspectos de la implementación en función de la infraestructura actual.
Hay tres modelos de implementación entre los que puede elegir:
| Modelo de implementación | Descripción | |
|---|---|---|
| 🔲 | Solo en la nube | Para organizaciones que solo tienen identidades en la nube y no tienen acceso a recursos locales. Estas organizaciones suelen unir sus dispositivos a la nube y usan exclusivamente recursos en la nube, como SharePoint Online, OneDrive y otros. Además, dado que los usuarios no usan recursos locales, no necesitan certificados para cosas como VPN porque todo lo que necesitan se hospeda en servicios en la nube. |
| 🔲 | Híbrida | Para las organizaciones que tienen identidades sincronizadas entre Active Directory y Microsoft Entra ID. Estas organizaciones usan aplicaciones registradas en Microsoft Entra ID y quieren una experiencia de inicio de sesión único (SSO) para los recursos locales y Microsoft Entra. |
| 🔲 | Local | Para las organizaciones que no tienen identidades en la nube ni usan aplicaciones hospedadas en Microsoft Entra ID. Estas organizaciones usan aplicaciones locales, integradas en Active Directory y quieren experiencias de usuario de SSO al acceder a ellas. |
Nota
- El caso de uso principal de la implementación local es para "Entornos administrativos de seguridad mejorada", también conocidos como "Bosques rojos".
- La migración de una implementación local a una implementación híbrida requiere una nueva implementación
Tipos de confianza
El tipo de confianza de una implementación define cómo Windows Hello para empresas clientes se autentican en Active Directory. El tipo de confianza no afecta a la autenticación para Microsoft Entra ID. Por este motivo, el tipo de confianza no es aplicable a un modelo de implementación solo en la nube.
Windows Hello para empresas autenticación para Microsoft Entra ID siempre usa la clave, no un certificado (excepto la autenticación de tarjeta inteligente en un entorno federado).
El tipo de confianza determina si emite certificados de autenticación a los usuarios. Un modelo de confianza no es más seguro que el otro.
La implementación de certificados en usuarios y controladores de dominio requiere más configuración e infraestructura, lo que también podría ser un factor a tener en cuenta en su decisión. Más infraestructura necesaria para las implementaciones de confianza de certificados incluye una entidad de registro de certificados. En un entorno federado, debe activar la opción Escritura diferida de dispositivos en Microsoft Entra Connect.
Hay tres tipos de confianza entre los que puede elegir:
| Tipo de confianza | Descripción | |
|---|---|---|
| 🔲 | Kerberos en la nube | Los usuarios se autentican en Active Directory solicitando un TGT de Microsoft Entra ID, mediante Microsoft Entra Kerberos. Los controladores de dominio locales siguen siendo responsables de los vales de servicio kerberos y la autorización. La confianza de Kerberos en la nube usa la misma infraestructura necesaria para el inicio de sesión de clave de seguridad FIDO2 y se puede usar para implementaciones de Windows Hello para empresas nuevas o existentes. |
| 🔲 | Llave | Los usuarios se autentican en el Active Directory local mediante una clave enlazada a dispositivos (hardware o software) creada durante la experiencia de aprovisionamiento de Windows Hello. Requiere distribuir certificados a los controladores de dominio. |
| 🔲 | Certificado | El tipo de confianza de certificado emite certificados de autenticación a los usuarios. Los usuarios se autentican mediante un certificado solicitado mediante una clave enlazada a un dispositivo (hardware o software) creada durante la experiencia de aprovisionamiento de Windows Hello. |
La confianza clave y la confianza del certificado usan Kerberos basado en autenticación de certificados al solicitar vales de concesión de vales (TGT) de Kerberos para la autenticación local. Este tipo de autenticación requiere una PKI para los certificados de controlador de dominio y requiere certificados de usuario final para la confianza de certificados.
El objetivo de Windows Hello para empresas confianza de Kerberos en la nube es proporcionar una experiencia de implementación más sencilla, en comparación con los otros tipos de confianza:
- No es necesario implementar una infraestructura de clave pública (PKI) ni cambiar una PKI existente
- No es necesario sincronizar las claves públicas entre Microsoft Entra ID y Active Directory para que los usuarios accedan a los recursos locales. No hay ningún retraso entre el aprovisionamiento de Windows Hello para empresas del usuario y la capacidad de autenticarse en Active Directory
- El inicio de sesión de la clave de seguridad FIDO2 se puede implementar con una configuración adicional mínima
Sugerencia
Windows Hello para empresas confianza de Kerberos en la nube es el modelo de implementación recomendado en comparación con el modelo de confianza clave. También es el modelo de implementación preferido si no necesita admitir escenarios de autenticación de certificados.
La confianza de Kerberos en la nube requiere la implementación de Microsoft Entra Kerberos. Para obtener más información sobre cómo Microsoft Entra Kerberos permite el acceso a los recursos locales, consulte Habilitación del inicio de sesión de clave de seguridad sin contraseña en recursos locales.
Requisitos de PKI
La confianza de Kerberos en la nube es la única opción de implementación híbrida que no requiere la implementación de ningún certificado. Los demás modelos híbridos y locales dependen de una PKI empresarial como delimitador de confianza para la autenticación:
- Los controladores de dominio para implementaciones híbridas y locales necesitan un certificado para que los dispositivos Windows confíen en el controlador de dominio como legítimo.
- Las implementaciones que usan el tipo de confianza de certificado requieren una PKI empresarial y una entidad de registro de certificados (CRA) para emitir certificados de autenticación a los usuarios. AD FS se usa como CRA
- Es posible que las implementaciones híbridas necesiten emitir certificados VPN a los usuarios para habilitar la conectividad de recursos locales.
| Modelo de implementación | Tipo de confianza | ¿Se requiere PKI? | |
|---|---|---|---|
| 🔲 | Solo en la nube | n/d | no |
| 🔲 | Híbrida | Kerberos en la nube | no |
| 🔲 | Híbrida | Key | sí |
| 🔲 | Híbrida | Certificado | sí |
| 🔲 | Local | Key | sí |
| 🔲 | Local | Certificado | sí |
Autenticación para Microsoft Entra ID
Los usuarios pueden autenticarse para Microsoft Entra ID mediante la autenticación federada o la autenticación en la nube (no federada). Los requisitos varían según el tipo de confianza:
| Modelo de implementación | Tipo de confianza | Autenticación para Microsoft Entra ID | Requisitos | |
|---|---|---|---|---|
| 🔲 | Solo en la nube | n/d | Autenticación en la nube | n/d |
| 🔲 | Solo en la nube | n/d | Autenticación federada | Servicio de federación que no es de Microsoft |
| 🔲 | Híbrida | Confianza de Kerberos en la nube | Autenticación en la nube | Sincronización de hash de contraseña (PHS) o autenticación de paso a través (PTA) |
| 🔲 | Híbrida | Confianza de Kerberos en la nube | Autenticación federada | AD FS o servicio de federación que no es de Microsoft |
| 🔲 | Híbrida | Clave de confianza | Autenticación en la nube | Sincronización de hash de contraseña (PHS) o autenticación de paso a través (PTA) |
| 🔲 | Híbrida | Clave de confianza | Autenticación federada | AD FS o servicio de federación que no es de Microsoft |
| 🔲 | Híbrida | Certificado de confianza | Autenticación federada | Este modelo de implementación no admite PTA ni PHS. Active Directory debe estar federado con Microsoft Entra ID mediante AD FS |
Para obtener más información:
- Federación con Microsoft Entra ID
- Sincronización de hash de contraseña (PHS)
- Autenticación de paso a través (PTA)
Registro de dispositivos
En el caso de las implementaciones locales, el servidor que ejecuta el rol de Servicios de federación de Active Directory (AD FS) (AD FS) es responsable del registro de dispositivos. Para implementaciones híbridas y solo en la nube, los dispositivos deben registrarse en Microsoft Entra ID.
| Modelo de implementación | Tipo de combinación compatible | Proveedor de servicios de registro de dispositivos |
|---|---|---|
| Solo en la nube | Microsoft Entra unidos Microsoft Entra registrado |
Microsoft Entra ID |
| Híbrida | Microsoft Entra unidos Microsoft Entra unidos a híbridos Microsoft Entra registrado |
Microsoft Entra ID |
| Local | Dominio unido a Active Directory | AD FS |
Importante
Para obtener Microsoft Entra guía de combinación híbrida, consulte Planeamiento de la implementación de la unión híbrida Microsoft Entra.
Autenticación multifactor
El objetivo de Windows Hello para empresas es alejar a las organizaciones de las contraseñas proporcionándoles una credencial segura que permita una autenticación sencilla en dos fases. La experiencia de aprovisionamiento integrada acepta las credenciales débiles del usuario (nombre de usuario y contraseña) como la autenticación en primer factor. Sin embargo, el usuario debe proporcionar un segundo factor de autenticación antes de que Windows aprovisione una credencial segura:
- En el caso de las implementaciones híbridas y solo en la nube, hay diferentes opciones para la autenticación multifactor, incluido Microsoft Entra MFA.
- Las implementaciones locales deben usar una opción multifactor que se pueda integrar como un adaptador multifactor de AD FS. Las organizaciones pueden elegir entre opciones que no son de Microsoft que ofrecen un adaptador de MFA de AD FS. Para obtener más información, consulte Métodos de autenticación adicionales de Microsoft y que no son de Microsoft.
Importante
A partir del 1 de julio de 2019, Microsoft no ofrece servidor MFA para nuevas implementaciones. Las nuevas implementaciones que requieren autenticación multifactor deben usar la autenticación multifactor Microsoft Entra basada en la nube.
A partir del 30 de septiembre de 2024, las implementaciones del servidor Azure Multi-Factor Authentication ya no atenderán las solicitudes de MFA. Para garantizar servicios de autenticación ininterrumpidos y permanecer en un estado compatible, las organizaciones deben migrar los datos de autenticación de sus usuarios a Azure MFA basado en la nube.
| Modelo de implementación | Opciones de MFA | |
|---|---|---|
| 🔲 | Solo en la nube | MFA de Microsoft Entra |
| 🔲 | Solo en la nube | Mfa que no es de Microsoft, mediante el método de autenticación externa en Microsoft Entra ID o federación |
| 🔲 | Híbrida | MFA de Microsoft Entra |
| 🔲 | Híbrida | Mfa que no es de Microsoft, mediante el método de autenticación externa en Microsoft Entra ID o federación |
| 🔲 | Local | Adaptador de MFA de AD FS |
Para más información:
- Configuración de Microsoft Entra configuración de autenticación multifactor
- Administración de un método de autenticación externo en Microsoft Entra ID
MFA y autenticación federada
Es posible que los dominios federados configuren la marca FederatedIdpMfaBehavior . La marca indica a Microsoft Entra ID que acepte, aplique o rechace el desafío de MFA del IdP federado. Para obtener más información, vea federatedIdpMfaBehavior values(Valores de federatedIdpMfaBehavior). Para comprobar esta configuración, use el siguiente comando de PowerShell:
Connect-MgGraph
$DomainId = "<your federated domain name>"
Get-MgDomainFederationConfiguration -DomainId $DomainId |fl
Para rechazar la notificación de MFA del IdP federado, use el siguiente comando. Este cambio afecta a todos los escenarios de MFA para el dominio federado:
Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp
Si configura la marca con un valor de acceptIfMfaDoneByFederatedIdp (valor predeterminado) o enforceMfaByFederatedIdp, debe comprobar que el IDP federado está configurado correctamente y funcionando con el adaptador de MFA y el proveedor utilizados por el IdP.
Registro de claves
La experiencia integrada de aprovisionamiento de Windows Hello para empresas crea un par de claves asimétricas enlazadas a dispositivos como credenciales del usuario. La clave privada está protegida por los módulos de seguridad del dispositivo. La credencial es una clave de usuario, no una clave de dispositivo. La experiencia de aprovisionamiento registra la clave pública del usuario con el proveedor de identidades:
| Modelo de implementación | Proveedor de servicios de registro de claves |
|---|---|
| Solo en la nube | Microsoft Entra ID |
| Híbrida | Microsoft Entra ID |
| Local | AD FS |
Sincronización de directorios
Las implementaciones híbridas y locales usan la sincronización de directorios, pero cada una con un propósito diferente:
- Las implementaciones híbridas usan Microsoft Entra Connect Sync para sincronizar identidades de Active Directory (usuarios y dispositivos) o credenciales entre sí y Microsoft Entra ID. Durante el proceso de aprovisionamiento de Window Hello for Business, los usuarios registran la parte pública de su credencial de Windows Hello para empresas con Microsoft Entra ID. Microsoft Entra Connect Sync sincroniza la clave pública Windows Hello para empresas con Active Directory. Esta sincronización permite que el inicio de sesión único Microsoft Entra ID y sus componentes federados.
Importante
Windows Hello para empresas está asociada entre un usuario y un dispositivo. Tanto el usuario como el objeto de dispositivo deben sincronizarse entre Microsoft Entra ID y Active Directory.
- Las implementaciones locales usan la sincronización de directorios para importar usuarios de Active Directory al servidor Azure MFA, que envía datos al servicio en la nube de MFA para realizar la comprobación.
| Modelo de implementación | Opciones de sincronización de directorios |
|---|---|
| Solo en la nube | n/d |
| Híbrida | Microsoft Entra Connect Sync |
| Local | Servidor Azure MFA |
Importante
A partir del 30 de septiembre de 2024, las implementaciones del servidor Azure Multi-Factor Authentication ya no atenderán las solicitudes de MFA. Para garantizar servicios de autenticación ininterrumpidos y permanecer en un estado compatible, las organizaciones deben migrar los datos de autenticación de sus usuarios a Azure MFA basado en la nube.
Opciones de configuración del dispositivo
Windows Hello para empresas proporciona un amplio conjunto de configuraciones de directivas pormenorizadas. Hay dos opciones principales para configurar Windows Hello para empresas: proveedor de servicios de configuración (CSP) y directiva de grupo (GPO).
- La opción CSP es ideal para dispositivos que se administran a través de una solución de Administración de dispositivos móvil (MDM), como Microsoft Intune. Los CSP también se pueden configurar con paquetes de aprovisionamiento
- GPO se puede usar para configurar dispositivos unidos a un dominio y donde los dispositivos no se administran a través de MDM
| Modelo de implementación | Opciones de configuración del dispositivo | |
|---|---|---|
| 🔲 | Solo en la nube | CSP |
| 🔲 | Solo en la nube | GPO (local) |
| 🔲 | Híbrida | CSP |
| 🔲 | Híbrida | GPO (Active Directory o local) |
| 🔲 | Local | CSP |
| 🔲 | Local | GPO (Active Directory o local) |
Licencias para requisitos de servicios en la nube
Estas son algunas consideraciones relacionadas con los requisitos de licencia para los servicios en la nube:
- Windows Hello para empresas no requiere una suscripción Microsoft Entra ID P1 o P2. Sin embargo, algunas dependencias, como la inscripción automática de MDM y el acceso condicional ,
- Los dispositivos administrados a través de MDM no requieren una suscripción Microsoft Entra ID P1 o P2. Al renunciar a la suscripción, los usuarios deben inscribir manualmente dispositivos en la solución MDM, como Microsoft Intune o una MDM compatible que no sea de Microsoft.
- Puede implementar Windows Hello para empresas mediante el nivel gratis de Microsoft Entra ID. Todas las cuentas Microsoft Entra ID gratis pueden usar Microsoft Entra autenticación multifactor para las características sin contraseña de Windows
- Algunas características de autenticación multifactor Microsoft Entra requieren una licencia. Para obtener más información, consulte Características y licencias para la autenticación multifactor de Microsoft Entra.
- La inscripción de un certificado mediante la entidad de registro de AD FS requiere que los dispositivos se autentiquen en el servidor de AD FS, lo que requiere la reescritura de dispositivos, una característica Microsoft Entra ID P1 o P2
| Modelo de implementación | Tipo de confianza | Licencias de servicios en la nube (mínimo) | |
|---|---|---|---|
| 🔲 | Solo en la nube | n/d | no es necesario |
| 🔲 | Híbrida | Kerberos en la nube | no es necesario |
| 🔲 | Híbrida | Key | no es necesario |
| 🔲 | Híbrida | Certificado | Microsoft Entra ID P1 |
| 🔲 | Local | Key | Azure MFA, si se usa como solución de MFA |
| 🔲 | Local | Certificado | Azure MFA, si se usa como solución de MFA |
Importante
A partir del 30 de septiembre de 2024, las implementaciones del servidor Azure Multi-Factor Authentication ya no atenderán las solicitudes de MFA. Para garantizar servicios de autenticación ininterrumpidos y permanecer en un estado compatible, las organizaciones deben migrar los datos de autenticación de sus usuarios a Azure MFA basado en la nube.
Requisitos del sistema operativo
Requisitos de Windows
Todas las versiones compatibles de Windows se pueden usar con Windows Hello para empresas. Sin embargo, la confianza de Kerberos en la nube requiere versiones mínimas:
| Modelo de implementación | Tipo de confianza | Versión de Windows | |
|---|---|---|---|
| 🔲 | Solo en la nube | n/d | Todas las versiones admitidas |
| 🔲 | Híbrida | Kerberos en la nube | - Windows 10 21H2, con KB5010415 y versiones posteriores - Windows 11 21H2, con KB5010414 y versiones posteriores |
| 🔲 | Híbrida | Key | Todas las versiones admitidas |
| 🔲 | Híbrida | Certificado | Todas las versiones admitidas |
| 🔲 | Local | Key | Todas las versiones admitidas |
| 🔲 | Local | Certificado | Todas las versiones admitidas |
Requisitos de Windows Server
Windows Hello para empresas se puede usar para autenticarse en todas las versiones compatibles de Windows Server como controlador de dominio. Sin embargo, la confianza de Kerberos en la nube requiere versiones mínimas:
| Modelo de implementación | Tipo de confianza | Versión del sistema operativo del controlador de dominio | |
|---|---|---|---|
| 🔲 | Solo en la nube | n/d | Todas las versiones admitidas |
| 🔲 | Híbrida | Kerberos en la nube | - Windows Server 2016, con KB3534307 y versiones posteriores - Windows Server 2019, con KB4534321 y versiones posteriores - Windows Server 2022 - Windows Server 2025 |
| 🔲 | Híbrida | Key | Todas las versiones admitidas |
| 🔲 | Híbrida | Certificado | Todas las versiones admitidas |
| 🔲 | Local | Key | Todas las versiones admitidas |
| 🔲 | Local | Certificado | Todas las versiones admitidas |
Los niveles funcionales mínimos de bosque y funcional de dominio necesarios son Windows Server 2008 R2 para todos los modelos de implementación.
Preparación de usuarios
Cuando esté listo para habilitar Windows Hello para empresas en su organización, asegúrese de preparar a los usuarios explicando cómo aprovisionar y usar Windows Hello.
Para obtener más información, consulte Preparación de usuarios.
Pasos siguientes
Ahora que ha leído sobre las diferentes opciones y requisitos de implementación, puede elegir la implementación que mejor se adapte a su organización.
Para obtener más información sobre el proceso de implementación, elija un modelo de implementación y un tipo de confianza en las siguientes listas desplegables: