Cómo funciona Windows Hello para empresas

• Se aplica a:

  ✅ Windows 11, ✅ Windows 10

Windows Hello para empresas es un sistema distribuido que requiere que varias tecnologías funcionen conjuntamente. Para simplificar la explicación de cómo funciona Windows Hello para empresas, vamos a dividirlo en cinco fases, que representan el orden cronológico del proceso de implementación.

Nota

Dos de estas fases solo son necesarias para determinados escenarios de implementación.

Los escenarios de implementación se describen en el artículo Planeamiento de una implementación de Windows Hello para empresas.

Fase de registro de dispositivos

En esta fase, el dispositivo registra su identidad con el proveedor de identidades (IdP), para que pueda asociarse y autenticarse en el IdP.

Fase de aprovisionamiento

Durante esta fase, el usuario se autentica mediante una forma de autenticación (normalmente, nombre de usuario o contraseña) para solicitar una nueva credencial de Windows Hello para empresas. El flujo de aprovisionamiento requiere un segundo factor de autenticación para poder generar un par de claves pública y privada. La clave pública se registra con el IdP, asignado a la cuenta de usuario.

Fase de sincronización de claves

En esta fase, requerida por algunas implementaciones híbridas, la clave pública del usuario se sincroniza de Microsoft Entra ID a Active Directory.

Fase de inscripción de certificados

En esta fase, necesaria solo para las implementaciones que usan certificados, se emite un certificado al usuario mediante la infraestructura de clave pública (PKI) de la organización.

Fase de autenticación

En esta última fase, el usuario puede iniciar sesión en Windows mediante biometría o un PIN. Independientemente del gesto usado, la autenticación se produce mediante la parte privada de la credencial Windows Hello para empresas. El IdP valida la identidad de usuario mediante la asignación de la cuenta de usuario a la clave pública registrada durante la fase de aprovisionamiento.

En las secciones siguientes se proporciona información más detallada sobre cada una de estas fases.

Registro de dispositivos

Todos los dispositivos incluidos en la implementación de Windows Hello para empresas deben pasar por un proceso denominado registro de dispositivos. El registro de dispositivos permite que los dispositivos se asocien y se autentiquen en un IdP:

• En el caso de las implementaciones híbridas y en la nube, el proveedor de identidades se Microsoft Entra ID y el dispositivo se registra con el servicio de registro de dispositivos.
• En el caso de las implementaciones locales, el proveedor de identidades se Servicios de federación de Active Directory (AD FS) (AD FS) y el dispositivo se registra con el servicio de registro de dispositivos empresariales hospedado en AD FS.

Cuando se registra un dispositivo, el IdP proporciona al dispositivo una identidad que se usa para autenticar el dispositivo cuando un usuario inicia sesión.

Hay diferentes tipos de registro, que se identifican como tipo de combinación. Para obtener más información, consulte ¿Qué es una identidad de dispositivo?

Para obtener diagramas de secuencia detallados, vea cómo funciona el registro de dispositivos.

Aprovisionamiento

Windows Hello aprovisionamiento se desencadena una vez que se completa el registro de dispositivos y después de que el dispositivo recibe una directiva que habilita Windows Hello. Si se cumplen todos los requisitos previos, se inicia una ventana del host de eXperience en la nube (CXH) para llevar al usuario a través del flujo de aprovisionamiento.

Nota

En función del tipo de implementación, Windows Hello para empresas aprovisionamiento solo se inicia si:

• El dispositivo cumple los requisitos de hardware Windows Hello
• El dispositivo se une a Active Directory o Microsoft Entra ID
• El usuario inicia sesión con una cuenta definida en Active Directory o Microsoft Entra ID
• La directiva de Windows Hello para empresas está habilitada
• El usuario no está conectado a la máquina a través de Escritorio remoto

Los requisitos previos adicionales para tipos de implementación específicos se describen en el artículo Planeamiento de una implementación Windows Hello para empresas.

Durante la fase de aprovisionamiento, se crea un contenedor de Windows Hello. Un contenedor de Windows Hello es una agrupación lógica de material de clave o datos. El contenedor contiene las credenciales de la organización solo en los dispositivos registrados con el IdP de la organización.

Nota

No hay contenedores físicos en el disco, en el registro o en otro lugar. Los contenedores son unidades lógicas que se usan para agrupar elementos relacionados. Las claves, certificados y credenciales que Windows Hello almacenes se protegen sin la creación de contenedores o carpetas reales.

Estos son los pasos implicados en la fase de aprovisionamiento:

1. En la ventana CXH, se pide al usuario que se autentique en el IdP con MFA.
2. Después de una MFA correcta, el usuario debe proporcionar un gesto bio (si está disponible) y un PIN
3. Después de la confirmación del PIN, se crea el contenedor de Windows Hello
4. Se genera un par de claves pública y privada. El par de claves está enlazado al módulo de plataforma segura (TPM), si está disponible o en software.
5. La clave privada se almacena localmente y está protegida por el TPM y no se puede exportar
6. La clave pública se registra con el IdP, asignada a la cuenta de usuario.
   1. El servicio de registro de dispositivos escribe la clave en el objeto de usuario en Microsoft Entra ID
   2. En escenarios locales, AD FS escribe la clave en Active Directory.

En el vídeo siguiente se muestran los pasos de inscripción de Windows Hello para empresas después de iniciar sesión con una contraseña:

Para obtener más información y diagramas de secuencia detallados, consulte cómo funciona el aprovisionamiento.

Windows Hello detalles del contenedor

Durante la fase de aprovisionamiento, Windows Hello genera un nuevo par de claves pública y privada en el dispositivo. El TPM genera y protege la clave privada. Si el dispositivo no tiene un TPM, la clave privada se cifra y almacena en software. Esta clave inicial se conoce como clave protector. La clave del protector está asociada con un solo gesto: si un usuario registra un PIN, una huella digital y una cara en el mismo dispositivo, cada uno de esos gestos tiene una clave de protector única.

La clave del protector encapsula la clave de autenticación de forma segura. La clave de autenticación se usa para desbloquear las claves de identificador de usuario. El contenedor tiene solo una clave de autenticación, pero puede haber varias copias de dicha clave encapsuladas con distintas claves protectoras únicas.

Cada protector cifra su propia copia de la clave de autenticación. La forma en que se realiza el cifrado depende del propio protector. Por ejemplo, el protector de PIN realiza una operación de sellado de TPM mediante el PIN como entropía o, cuando no hay ningún TPM disponible, realiza el cifrado simétrico de la clave de autenticación mediante una clave derivada del propio PIN.

Importante

Las claves se pueden generar en hardware (TPM 1.2 o 2.0) o software, según la configuración de directiva configurada. Para garantizar que las claves se generan en hardware, debe configurar una configuración de directiva. Para obtener más información, consulte Uso de un dispositivo de seguridad de hardware.

Las cuentas personales (cuenta Microsoft) y profesionales o educativas (Active Directory o Microsoft Entra ID) usan un único contenedor para las claves. Todas las claves están separadas por dominios de proveedores de identidad para garantizar la privacidad del usuario.

Windows Hello también genera una clave administrativa. La clave administrativa se puede usar para restablecer las credenciales cuando sea necesario. Por ejemplo, cuando se usa el servicio de restablecimiento de PIN. Además de la clave protectora, los dispositivos habilitados para TPM generan un bloque de datos que contiene los certificados del TPM.

El acceso al material clave almacenado en el contenedor solo se habilita mediante el PIN o el gesto biométrico. La comprobación en dos pasos que tiene lugar durante el aprovisionamiento crea una relación de confianza entre el IdP y el usuario. Esto sucede cuando la parte pública del par de claves pública y privada se envía a un proveedor de identidades y se asocia a la cuenta de usuario. Cuando un usuario escribe el gesto en el dispositivo, el proveedor de identidades sabe que se trata de una identidad verificada, debido a la combinación de Windows Hello claves y gestos. A continuación, proporciona un token de autenticación que permite a Windows acceder a recursos y servicios.

Un contenedor puede contener varios tipos de material clave:

• Una clave de autenticación, que siempre es un par de claves públicas y privadas asimétricas. Este par de claves se genera durante el registro. Debe desbloquearse cada vez que se accede a él, mediante el PIN del usuario o un gesto biométrico. La clave de autenticación existe hasta que el usuario restablece el PIN, momento en el que se genera una nueva clave. Cuando se genera la nueva clave, todo el material de clave que la clave anteriormente protegida debe descifrarse y volver a cifrarse con la nueva clave
• Una o varias claves de identificador de usuario. Estas claves pueden ser simétricas o asimétricas, en función del IdP que use. En el caso de Windows Hello basadas en certificados para Work, cuando el contenedor está desbloqueado, las aplicaciones que requieren acceso a la clave de identificador de usuario o al par de claves pueden solicitar acceso. Las claves de identificador de usuario se usan para firmar o cifrar solicitudes de autenticación o tokens enviados desde este dispositivo al IdP. Las claves de identificador de usuario suelen ser de larga duración, pero podrían tener una duración más corta que la clave de autenticación. Las cuentas de Microsoft, las cuentas de Active Directory y las cuentas de Microsoft Entra requieren el uso de pares de claves asimétricas. El dispositivo genera claves públicas y privadas, registra la clave pública con el IdP (que la almacena para su posterior comprobación) y almacena de forma segura la clave privada. En el caso de los organizatrones, las claves de identificador de usuario se pueden generar de dos maneras:
  • El par de claves de id. de usuario se puede asociar a la entidad de certificación (CA) de una organización. Esta opción permite a las organizaciones con una PKI existente seguir usándola según corresponda. Dado que muchas aplicaciones, como las soluciones VPN, requieren el uso de certificados, al implementar Windows Hello en este modo, permite una transición más rápida de las contraseñas de usuario, a la vez que conserva la funcionalidad basada en certificados. Esta opción también permite a la organización almacenar otros certificados en el contenedor protegido. Por ejemplo, certificados que permiten al usuario autenticarse a través de RDP
  • El IdP puede generar el par de claves de id. de usuario directamente, lo que permite una implementación rápida y de menor sobrecarga de Windows Hello en entornos que no tienen o necesitan una PKI.

Las claves de id. de usuario se usan para autenticar al usuario en un servicio. Por ejemplo, al firmar un nonce para demostrar la posesión de la clave privada, que corresponde a una clave pública registrada. Los usuarios con una cuenta de Active Directory, Microsoft Entra ID o Microsoft tienen una clave asociada a su cuenta. La clave se puede usar para iniciar sesión en su dispositivo Windows mediante la autenticación en un controlador de dominio (escenario de Active Directory) o en la nube (escenarios de Microsoft Entra ID y MSA).

Windows Hello también se puede usar como autenticador FIDO2 para autenticarse en cualquier sitio web que admita WebAuthn. Los sitios web o la aplicación pueden crear una clave de identificador de usuario FIDO en el contenedor de Windows Hello del usuario mediante las API. En las visitas posteriores, el usuario puede autenticarse en el sitio web o la aplicación mediante su PIN Windows Hello o gesto biométrico.

Para obtener más información sobre cómo Windows usa el TPM en compatibilidad con Windows Hello para empresas, vea Cómo Windows usa el módulo de plataforma segura.

Almacenamiento de datos biométricos

Los datos biométricos que se usan para la compatibilidad con Windows Hello se almacenan solo en el dispositivo local. No se desplaza y nunca se envía a dispositivos o servidores externos. Esta separación ayuda a detener a los posibles atacantes al impedir que se produzca un único punto de colección que un atacante puede poner en riesgo para robar los datos biométricos. Incluso si un atacante pudiera obtener los datos biométricos de un dispositivo, el sensor biométrico no podría volver a convertirlo en una muestra biométrica sin procesar reconocible.

Cada sensor tiene su propio archivo de base de datos biométrica donde se almacenan los datos de plantilla (ruta de acceso C:\WINDOWS\System32\WinBioDatabase). Cada archivo de base de datos tiene una clave única y generada aleatoriamente que se cifra en el sistema. Los datos de plantilla del sensor se cifran con la clave por base de datos mediante AES con el modo de encadenamiento CBC. El hash es SHA256.

Nota

Algunos sensores de huellas digitales tienen la capacidad de completar la coincidencia en el módulo del sensor de huellas digitales en lugar de en el sistema operativo. Estos sensores almacenan datos biométricos en el módulo de huellas digitales en lugar de en el archivo de base de datos. Para obtener más información, consulte Windows Hello inicio de sesión de seguridad mejorada (ESS).

Sincronización de claves

La sincronización de claves es necesaria en entornos híbridos. Después de que el usuario aprovisiona una credencial de Windows Hello para empresas, la clave debe sincronizarse de Microsoft Entra ID a Active Directory.

La clave pública del usuario se escribe en el msDS-KeyCredentialLink atributo del objeto de usuario en Active Directory. La sincronización se controla mediante Microsoft Entra Connect Sync.

Inscripción de certificados

En el caso de las implementaciones de certificados, después de registrar la clave, el cliente genera una solicitud de certificado. La solicitud se envía a la entidad de registro de certificados (CRA). La CRA se encuentra en el servidor de Servicios de federación de Active Directory (AD FS) (AD FS), que valida la solicitud de certificado y la satisface mediante la PKI empresarial.

Un certificado se inscribe en el contenedor Hello del usuario, que se usa para autenticarse en los recursos locales.

Authentication

Las credenciales de Windows Hello se basan en un certificado o un par de claves asimétricas. Windows Hello credenciales y el token que se obtiene con esas credenciales, se enlazan al dispositivo.

La autenticación es la autenticación en dos fases con la combinación de:

• Una clave, o certificado, asociada a un dispositivo y
  • algo que la persona sabe (un PIN) o
  • algo que la persona es (biometría)

Tanto la entrada de PIN como el gesto biométrico desencadenan que Windows use la clave privada para firmar criptográficamente los datos que se envían al proveedor de identidades. El IdP comprueba la identidad del usuario y autentica al usuario.

El PIN o la parte privada de las credenciales nunca se envían al IdP y el PIN no se almacena en el dispositivo. Los gestos pin y bio son entropía proporcionada por el usuario al realizar operaciones que usan la parte privada de la credencial.

Cuando un usuario quiere acceder al material de clave protegido, el proceso de autenticación comienza con el usuario que escribe un PIN o gesto biométrico para desbloquear el dispositivo, un proceso que a veces se denomina liberar la clave. Esto se puede comparar con el uso de una llave para abrir una puerta: antes de poder abrir la puerta, hay que sacar la llave del bolsillo o bolso. El PIN del usuario desbloquea la clave protectora del contenedor del dispositivo. Cuando ese contenedor está desbloqueado, las aplicaciones (y, por tanto, el usuario) pueden usar las claves de id. de usuario que residan dentro del contenedor.

Estas claves se usan para firmar las solicitudes que se envían al IdP y solicitan acceso a los recursos especificados.

Importante

Aunque las claves están desbloqueadas, las aplicaciones no pueden usarlas a voluntad. Las aplicaciones pueden usar API específicas para solicitar operaciones que requieren el material de clave para acciones concretas (por ejemplo, descifrar un mensaje de correo electrónico o iniciar sesión en un sitio web). El acceso a través de estas API no requiere validación explícita a través de un gesto del usuario y el material de clave no se expone a la aplicación solicitante. En cambio, la aplicación solicita la autenticación, el cifrado o el descifrado, y el nivel de Windows Hello controla el trabajo real y devuelve los resultados. Cuando corresponda, una aplicación puede solicitar una autenticación forzada incluso en un dispositivo desbloqueado. Windows pide al usuario que vuelva a escribir el PIN o a realizar un gesto de autenticación, lo que agrega un nivel adicional de protección de datos o acciones confidenciales. Por ejemplo, puede configurar una aplicación para que requiera volver a autenticarse cada vez que se realice una operación específica, aunque ya se hayan usado la misma cuenta y pin o gesto para desbloquear el dispositivo.

Para obtener más información y diagramas de secuencia detallados, consulte cómo funciona la autenticación.

Token de actualización principal

El inicio de sesión único (SSO) se basa en tokens especiales obtenidos para acceder a aplicaciones específicas. En el caso tradicional de autenticación integrada de Windows mediante Kerberos, el token es un TGT de Kerberos (vale de concesión de vales). Para las aplicaciones Microsoft Entra ID y AD FS, este token es un token de actualización principal (PRT). Se trata de un token web JSON que contiene notificaciones sobre el usuario y el dispositivo.

El PRT se obtiene inicialmente durante el inicio de sesión o el desbloqueo de forma similar a la que se obtiene el TGT de Kerberos. Este comportamiento es válido tanto para dispositivos unidos a Microsoft Entra como para Microsoft Entra híbridos. Para los dispositivos personales registrados con Microsoft Entra ID, el PRT se obtiene inicialmente en Agregar cuenta profesional o educativa. Para un dispositivo personal, la cuenta para desbloquear el dispositivo no es la cuenta profesional, sino una cuenta de consumidor (cuenta microsoft).

El PRT es necesario para el inicio de sesión único. Sin ella, a los usuarios se les pedirán credenciales cada vez que accedan a las aplicaciones. El PRT también contiene información sobre el dispositivo. Si tiene establecidas directivas de acceso condicional basadas en dispositivos en una aplicación, sin el acceso PRT se deniega.

Sugerencia

La clave de Windows Hello para empresas cumple Microsoft Entra requisitos de autenticación multifactor (MFA) y reduce el número de solicitudes de MFA que verán los usuarios al acceder a los recursos.

Para obtener más información, vea ¿Qué es un token de actualización principal?

cambios de Windows Hello para empresas y contraseña

El cambio de la contraseña de una cuenta de usuario no afecta al inicio de sesión ni al desbloqueo, ya que Windows Hello para empresas usa una clave o un certificado.

Pasos siguientes

Para adaptarse a la multitud de necesidades y requisitos de las organizaciones, Windows Hello para empresas ofrece diferentes opciones de implementación. Para obtener información sobre cómo planear una implementación de Windows Hello para empresas, consulte:

Planeamiento de una implementación de Windows Hello para empresas