autenticación de Windows Hello para empresas
Windows Hello para empresas autenticación es una autenticación en dos fases sin contraseña. La autenticación con Windows Hello para empresas proporciona una experiencia de inicio de sesión cómoda que autentica al usuario en los recursos de Microsoft Entra ID y Active Directory.
Microsoft Entra dispositivos unidos se autentican para Microsoft Entra ID durante el inicio de sesión y, opcionalmente, pueden autenticarse en Active Directory. Microsoft Entra dispositivos unidos a híbridos se autentican en Active Directory durante el inicio de sesión y se autentican para Microsoft Entra ID en segundo plano.
Microsoft Entra unirse a la autenticación para Microsoft Entra ID
Nota
Todos los dispositivos unidos a Microsoft Entra se autentican con Windows Hello para empresas para Microsoft Entra ID de la misma manera. El tipo de confianza Windows Hello para empresas solo afecta al modo en que el dispositivo se autentica en AD local.
| Fase | Descripción |
|---|---|
| A | La autenticación comienza cuando el usuario descarta la pantalla de bloqueo, lo que desencadena Winlogon para mostrar el proveedor de credenciales de Windows Hello para empresas. El usuario proporciona su gesto de Windows Hello (PIN o biometría). El proveedor de credenciales empaqueta estas credenciales y las devuelve a Winlogon. Winlogon pasa las credenciales recopiladas a LSASS. LSASS pasa las credenciales recopiladas al proveedor de soporte técnico de seguridad de autenticación en la nube, lo que se conoce como proveedor de Cloud AP. |
| B | El proveedor de Cloud AP solicita un nonce de Microsoft Entra ID. Microsoft Entra ID devuelve un valor nonce. El proveedor de Cloud AP firma el nonce mediante la clave privada del usuario y devuelve el nonce firmado al Microsoft Entra ID. |
| C | Microsoft Entra ID valida el nonce firmado mediante la clave pública registrada de forma segura del usuario con la firma de nonce. Microsoft Entra ID, a continuación, valida el nonce firmado devuelto y crea un PRT con la clave de sesión que se cifra en la clave de transporte del dispositivo y la devuelve al proveedor de Cloud AP. |
| D | El proveedor de Cloud AP recibe el PRT cifrado con la clave de sesión. Con la clave de transporte privada del dispositivo, el proveedor de Cloud AP descifra la clave de sesión y protege la clave de sesión mediante el TPM del dispositivo. |
| E | El proveedor de Cloud AP devuelve una respuesta de autenticación correcta a LSASS. LSASS almacena en caché el PRT e informa a Winlogon de la autenticación correcta. Winlogon crea una sesión de inicio de sesión, carga el perfil del usuario e inicia explorer.exe. |
Microsoft Entra unir la autenticación a Active Directory mediante la confianza de Kerberos en la nube
| Fase | Descripción |
|---|---|
| A | La autenticación en Active Directory desde un dispositivo unido a Microsoft Entra comienza con el usuario que primero intenta usar un recurso que necesita autenticación Kerberos. El proveedor de soporte técnico de seguridad kerberos, hospedado en LSASS, usa metadatos de la clave de Windows Hello para empresas para obtener una sugerencia del dominio del usuario. Con la sugerencia, el proveedor usa el servicio DClocator para buscar un controlador de dominio. |
| B | Después de localizar un controlador de dominio, el proveedor kerberos envía un TGT parcial que recibió de Microsoft Entra ID de una autenticación de Microsoft Entra anterior al controlador de dominio. El TGT parcial solo contiene el SID de usuario y está firmado por Microsoft Entra Kerberos. El controlador de dominio comprueba que el TGT parcial es válido. Si se ejecuta correctamente, el KDC devuelve un TGT al cliente. |
Microsoft Entra unir la autenticación a Active Directory mediante una clave
| Fase | Descripción |
|---|---|
| A | La autenticación en Active Directory desde un dispositivo unido a Microsoft Entra comienza con el usuario que primero intenta usar un recurso que necesita autenticación Kerberos. El proveedor de soporte técnico de seguridad kerberos, hospedado en LSASS, usa metadatos de la clave de Windows Hello para empresas para obtener una sugerencia del dominio del usuario. Con la sugerencia, el proveedor usa el servicio DClocator para buscar un controlador de dominio. Una vez que el proveedor encuentra un controlador de dominio, el proveedor usa la clave privada para firmar los datos de autenticación previa de Kerberos. |
| B | El proveedor Kerberos envía los datos de autenticación previa firmados y su clave pública (en forma de certificado autofirmado) al servicio del Centro de distribución de claves (KDC) que se ejecuta en el controlador de dominio en forma de KERB_AS_REQ. El controlador de dominio determina que el certificado es un certificado autofirmado. Recupera la clave pública del certificado incluido en la KERB_AS_REQ y busca la clave pública en Active Directory. Valida el UPN para que la solicitud de autenticación coincida con el UPN registrado en Active Directory y valida los datos de autenticación previa firmados mediante la clave pública de Active Directory. Si se ejecuta correctamente, el KDC devuelve un TGT al cliente con su certificado en un KERB_AS_REP. |
| C | El proveedor kerberos garantiza que puede confiar en la respuesta del controlador de dominio. En primer lugar, garantiza que el certificado KDC se encadena a un certificado raíz de confianza para el dispositivo. A continuación, garantiza que el certificado está dentro de su período de validez y que no se ha revocado. A continuación, el proveedor Kerberos comprueba que el certificado tiene la autenticación KDC presente y que el nombre alternativo del firmante que aparece en el certificado del KDC coincide con el nombre de dominio al que se autentica el usuario. Después de pasar este criterio, Kerberos devuelve el TGT a LSASS, donde se almacena en caché y se usa para las solicitudes de vales de servicio posteriores. |
Nota
Es posible que tenga un dominio local federado con Microsoft Entra ID. Una vez que haya aprovisionado correctamente Windows Hello para empresas PIN/Bio en el dispositivo unido a Microsoft Entra, cualquier inicio de sesión futuro de Windows Hello para empresas (PIN/Bio) se autenticará directamente en Microsoft Entra ID para obtener PRT y desencadenar la autenticación en el controlador de dominio (si LOS a DC está disponible) para obtener Kerberos. Ya no usa AD FS para autenticarse en los inicios de sesión de Windows Hello para empresas.
Microsoft Entra unir la autenticación a Active Directory mediante un certificado
| Fase | Descripción |
|---|---|
| A | La autenticación en Active Directory desde un dispositivo unido a Microsoft Entra comienza con el usuario que primero intenta usar un recurso que necesita autenticación Kerberos. El proveedor de soporte técnico de seguridad kerberos, hospedado en LSASS, usa información del certificado para obtener una sugerencia del dominio del usuario. Kerberos puede usar el nombre distintivo del usuario que se encuentra en el firmante del certificado, o bien puede usar el nombre principal de usuario del usuario que se encuentra en el nombre alternativo del firmante del certificado. Con la sugerencia, el proveedor usa el servicio DClocator para buscar un controlador de dominio. Una vez que el proveedor encuentra un controlador de dominio activo, el proveedor usa la clave privada para firmar los datos de autenticación previa de Kerberos. |
| B | El proveedor kerberos envía los datos de autenticación previa firmados y el certificado del usuario, que incluye la clave pública, al servicio del Centro de distribución de claves (KDC) que se ejecuta en el controlador de dominio en forma de KERB_AS_REQ. El controlador de dominio determina que el certificado no es un certificado autofirmado. El controlador de dominio garantiza que las cadenas de certificados para el certificado raíz de confianza están dentro de su período de validez, se pueden usar para la autenticación y no se han revocado. Recupera la clave pública y el UPN del certificado incluido en el KERB_AS_REQ y busca el UPN en Active Directory. Valida los datos de autenticación previa firmados mediante la clave pública del certificado. Si se ejecuta correctamente, el KDC devuelve un TGT al cliente con su certificado en un KERB_AS_REP. |
| C | El proveedor kerberos garantiza que puede confiar en la respuesta del controlador de dominio. En primer lugar, garantiza que el certificado KDC se encadena a un certificado raíz de confianza para el dispositivo. A continuación, garantiza que el certificado está dentro de su período de validez y que no se ha revocado. A continuación, el proveedor Kerberos comprueba que el certificado tiene la autenticación KDC presente y que el nombre alternativo del firmante que aparece en el certificado del KDC coincide con el nombre de dominio al que se autentica el usuario. Después de pasar este criterio, Kerberos devuelve el TGT a LSASS, donde se almacena en caché y se usa para las solicitudes de vales de servicio posteriores. |
Nota
Es posible que tenga un dominio local federado con Microsoft Entra ID. Una vez que haya aprovisionado correctamente Windows Hello para empresas PIN/Bio activado, cualquier inicio de sesión futuro de Windows Hello para empresas (PIN/Bio) se autenticará directamente en Microsoft Entra ID para obtener PRT, así como autenticarse en el controlador de dominio (si LOS a DC está disponible) para obtener Kerberos como se mencionó anteriormente. La federación de AD FS solo se usa cuando se realizan llamadas PRT empresariales desde el cliente. Debe tener habilitada la escritura diferida de dispositivos para obtener "PRT empresarial" de la federación.
Microsoft Entra autenticación de unión híbrida mediante la confianza de Kerberos en la nube
| Fase | Descripción |
|---|---|
| A | La autenticación comienza cuando el usuario descarta la pantalla de bloqueo, lo que desencadena Winlogon para mostrar el proveedor de credenciales de Windows Hello para empresas. El usuario proporciona su gesto de Windows Hello (PIN o biometría). El proveedor de credenciales empaqueta estas credenciales y las devuelve a Winlogon. Winlogon pasa las credenciales recopiladas a LSASS. LSASS consulta Windows Hello para empresas directiva para comprobar si la confianza de Kerberos en la nube está habilitada. Si la confianza de Kerberos en la nube está habilitada, LSASS pasa las credenciales recopiladas al proveedor de soporte técnico de seguridad de autenticación en la nube o a Cloud AP. Cloud AP solicita un nonce de Microsoft Entra ID. Microsoft Entra ID devuelve un valor nonce. |
| B | Cloud AP firma el nonce con la clave privada del usuario y devuelve el nonce firmado para Microsoft Entra ID. |
| C | Microsoft Entra ID valida el nonce firmado mediante la clave pública registrada de forma segura del usuario con la firma de nonce. Después de validar la firma, Microsoft Entra ID valida el nonce firmado devuelto. Después de validar el nonce, Microsoft Entra ID crea un PRT con clave de sesión que se cifra en la clave de transporte del dispositivo y crea un TGT parcial a partir de Microsoft Entra Kerberos y los devuelve a Cloud AP. |
| D | Cloud AP recibe el PRT cifrado con la clave de sesión. Con la clave de transporte privado del dispositivo, Cloud AP descifra la clave de sesión y protege la clave de sesión mediante el TPM del dispositivo (si está disponible). Cloud AP devuelve una respuesta de autenticación correcta a LSASS. LSASS almacena en caché el PRT y el TGT parcial. |
| E | El proveedor de soporte técnico de seguridad kerberos, hospedado en LSASS, usa metadatos de la clave de Windows Hello para empresas para obtener una sugerencia del dominio del usuario. Con la sugerencia, el proveedor usa el servicio DClocator para buscar un controlador de dominio. Después de localizar un controlador de dominio activo, el proveedor kerberos envía el TGT parcial que recibió de Microsoft Entra ID al controlador de dominio. El TGT parcial solo contiene el SID de usuario y está firmado por Microsoft Entra Kerberos. El controlador de dominio comprueba que el TGT parcial es válido. Si se ejecuta correctamente, el KDC devuelve un TGT al cliente. Kerberos devuelve el TGT a LSASS, donde se almacena en caché y se usa para las solicitudes de vales de servicio posteriores. LSASS informa a Winlogon de la autenticación correcta. Winlogon crea una sesión de inicio de sesión, carga el perfil del usuario e inicia explorer.exe. |
Microsoft Entra autenticación de unión híbrida mediante una clave
| Fase | Descripción |
|---|---|
| A | La autenticación comienza cuando el usuario descarta la pantalla de bloqueo, lo que desencadena Winlogon para mostrar el proveedor de credenciales de Windows Hello para empresas. El usuario proporciona su gesto de Windows Hello (PIN o biometría). El proveedor de credenciales empaqueta estas credenciales y las devuelve a Winlogon. Winlogon pasa las credenciales recopiladas a LSASS. LSASS pasa las credenciales recopiladas al proveedor de soporte técnico de seguridad kerberos. El proveedor Kerberos obtiene sugerencias de dominio de la estación de trabajo unida al dominio para buscar un controlador de dominio para el usuario. |
| B | El proveedor kerberos envía los datos de autenticación previa firmados y la clave pública del usuario (en forma de certificado autofirmado) al servicio del Centro de distribución de claves (KDC) que se ejecuta en el controlador de dominio en forma de KERB_AS_REQ. El controlador de dominio determina que el certificado es un certificado autofirmado. Recupera la clave pública del certificado incluido en la KERB_AS_REQ y busca la clave pública en Active Directory. Valida el UPN para que la solicitud de autenticación coincida con el UPN registrado en Active Directory y valida los datos de autenticación previa firmados mediante la clave pública de Active Directory. Si se ejecuta correctamente, el KDC devuelve un TGT al cliente con su certificado en un KERB_AS_REP. |
| C | El proveedor kerberos garantiza que puede confiar en la respuesta del controlador de dominio. En primer lugar, garantiza que el certificado KDC se encadena a un certificado raíz de confianza para el dispositivo. A continuación, garantiza que el certificado está dentro de su período de validez y que no se ha revocado. A continuación, el proveedor Kerberos comprueba que el certificado tiene la autenticación KDC presente y que el nombre alternativo del firmante que aparece en el certificado del KDC coincide con el nombre de dominio al que se autentica el usuario. |
| D | Después de pasar este criterio, Kerberos devuelve el TGT a LSASS, donde se almacena en caché y se usa para las solicitudes de vales de servicio posteriores. |
| E | LSASS informa a Winlogon de la autenticación correcta. Winlogon crea una sesión de inicio de sesión, carga el perfil del usuario e inicia explorer.exe. |
| F | Mientras Windows carga el escritorio del usuario, LSASS pasa las credenciales recopiladas al proveedor de soporte técnico de seguridad de Cloud Authentication, lo que se conoce como proveedor de Cloud AP. El proveedor de Cloud AP solicita un nonce de Microsoft Entra ID. Microsoft Entra ID devuelve un valor nonce. |
| G | El proveedor de Cloud AP firma el nonce mediante la clave privada del usuario y devuelve el nonce firmado al Microsoft Entra ID. Microsoft Entra ID valida el nonce firmado mediante la clave pública registrada de forma segura del usuario con la firma de nonce. Después de validar la firma, Microsoft Entra ID valida el nonce firmado devuelto. Después de validar el nonce, Microsoft Entra ID crea un PRT con la clave de sesión que se cifra en la clave de transporte del dispositivo y la devuelve al proveedor de Cloud AP. El proveedor de Cloud AP recibe el PRT cifrado con la clave de sesión. Con la clave de transporte privada del dispositivo, el proveedor de Cloud AP descifra la clave de sesión y protege la clave de sesión mediante el TPM del dispositivo. El proveedor de Cloud AP devuelve una respuesta de autenticación correcta a LSASS. LSASS almacena en caché el PRT. |
Importante
En el modelo de implementación anterior, un usuario recién aprovisionado no podrá iniciar sesión con Windows Hello para empresas hasta que (a) Microsoft Entra Connect sincronice correctamente la clave pública con el Active Directory local y (b) el dispositivo tenga línea de visión al controlador de dominio por primera vez.
Microsoft Entra autenticación de unión híbrida mediante un certificado
| Fase | Descripción |
|---|---|
| A | La autenticación comienza cuando el usuario descarta la pantalla de bloqueo, lo que desencadena Winlogon para mostrar el proveedor de credenciales de Windows Hello para empresas. El usuario proporciona su gesto de Windows Hello (PIN o biometría). El proveedor de credenciales empaqueta estas credenciales y las devuelve a Winlogon. Winlogon pasa las credenciales recopiladas a LSASS. LSASS pasa las credenciales recopiladas al proveedor de soporte técnico de seguridad kerberos. El proveedor Kerberos obtiene sugerencias de dominio de la estación de trabajo unida al dominio para buscar un controlador de dominio para el usuario. |
| B | El proveedor kerberos envía los datos de autenticación previa firmados y el certificado del usuario, que incluye la clave pública, al servicio del Centro de distribución de claves (KDC) que se ejecuta en el controlador de dominio en forma de KERB_AS_REQ. El controlador de dominio determina que el certificado no es un certificado autofirmado. El controlador de dominio garantiza que las cadenas de certificados para el certificado raíz de confianza están dentro de su período de validez, se pueden usar para la autenticación y no se han revocado. Recupera la clave pública y el UPN del certificado incluido en el KERB_AS_REQ y busca el UPN en Active Directory. Valida los datos de autenticación previa firmados mediante la clave pública del certificado. Si se ejecuta correctamente, el KDC devuelve un TGT al cliente con su certificado en un KERB_AS_REP. |
| C | El proveedor kerberos garantiza que puede confiar en la respuesta del controlador de dominio. En primer lugar, garantiza que el certificado KDC se encadena a un certificado raíz de confianza para el dispositivo. A continuación, garantiza que el certificado está dentro de su período de validez y que no se ha revocado. A continuación, el proveedor Kerberos comprueba que el certificado tiene la autenticación KDC presente y que el nombre alternativo del firmante que aparece en el certificado del KDC coincide con el nombre de dominio al que se autentica el usuario. |
| D | Después de pasar este criterio, Kerberos devuelve el TGT a LSASS, donde se almacena en caché y se usa para las solicitudes de vales de servicio posteriores. |
| E | LSASS informa a Winlogon de la autenticación correcta. Winlogon crea una sesión de inicio de sesión, carga el perfil del usuario e inicia explorer.exe. |
| F | Mientras Windows carga el escritorio del usuario, LSASS pasa las credenciales recopiladas al proveedor de soporte técnico de seguridad de Cloud Authentication, lo que se conoce como proveedor de Cloud AP. El proveedor de Cloud AP solicita un nonce de Microsoft Entra ID. Microsoft Entra ID devuelve un valor nonce. |
| G | El proveedor de Cloud AP firma el nonce mediante la clave privada del usuario y devuelve el nonce firmado al Microsoft Entra ID. Microsoft Entra ID valida el nonce firmado mediante la clave pública registrada de forma segura del usuario con la firma de nonce. Después de validar la firma, Microsoft Entra ID valida el nonce firmado devuelto. Después de validar el nonce, Microsoft Entra ID crea un PRT con la clave de sesión que se cifra en la clave de transporte del dispositivo y la devuelve al proveedor de Cloud AP. El proveedor de Cloud AP recibe el PRT cifrado con la clave de sesión. Con la clave de transporte privada del dispositivo, el proveedor de Cloud AP descifra la clave de sesión y protege la clave de sesión mediante el TPM del dispositivo. El proveedor de Cloud AP devuelve una respuesta de autenticación correcta a LSASS. LSASS almacena en caché el PRT. |
Importante
En este modelo de implementación, un usuario recién aprovisionado no podrá iniciar sesión con Windows Hello para empresas a menos que el dispositivo tenga una línea de visión para el controlador de dominio.