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 la 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.
🔲 Clave 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
🔲 Híbrida Certificado
🔲 Local Key
🔲 Local Certificado

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:

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. La implementación existente en la que se activó el servidor MFA antes del 1 de julio de 2019 puede descargar la versión más reciente, futuras actualizaciones y generar credenciales de activación. Para obtener más información, consulte Introducción al servidor Azure Multi-Factor Authentication.

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 a través de Microsoft Entra ID controles personalizados o federación
🔲 Híbrida MFA de Microsoft Entra
🔲 Híbrida MFA que no es de Microsoft a través de Microsoft Entra ID controles personalizados o federación
🔲 Local Adaptador de MFA de AD FS

Para obtener más información sobre cómo configurar Microsoft Entra autenticación multifactor, consulte Configuración de Microsoft Entra opciones de autenticación multifactor.

Para obtener más información sobre cómo configurar AD FS para proporcionar autenticación multifactor, consulte Configuración de Azure MFA como proveedor de autenticación con AD FS.

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 para empresas, 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

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
  • 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

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

Todas las versiones compatibles de Windows Server se pueden usar con Windows Hello para empresas 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
🔲 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

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: