Problemas de implementación conocidos de Windows Hello para empresas
El contenido de este artículo es para ayudar a solucionar problemas de implementación conocidos para Windows Hello para empresas.
Error de restablecimiento de PIN en dispositivos de unión a Microsoft Entra con No se puede abrir esa página en este momento
El restablecimiento de PIN en dispositivos unidos a Microsoft Entra usa un flujo denominado inicio de sesión web para autenticar al usuario anterior. El inicio de sesión web solo permite la navegación a dominios específicos. Si el inicio de sesión web intenta navegar a un dominio que no está permitido, muestra una página con el mensaje de error No se puede abrir esa página en este momento.
Identificar el problema de restablecimiento de PIN permitido de dominios
El usuario puede iniciar el flujo de restablecimiento de PIN desde la pantalla de bloqueo mediante el vínculo He olvidado mi PIN en el proveedor de credenciales de PIN. Al seleccionar el vínculo, se inicia una interfaz de usuario de pantalla completa para la experiencia de PIN en dispositivos de unión a Microsoft Entra. Normalmente, la interfaz de usuario muestra una página de autenticación, donde el usuario se autentica con las credenciales de Microsoft Entra y completa MFA.
En entornos federados, la autenticación puede configurarse para enrutarse a AD FS o a un proveedor de identidades que no sea de Microsoft. Si se inicia el flujo de restablecimiento de PIN e intenta navegar a una página de servidor del proveedor de identidades federado, se produce un error y se muestra el error We can't open that page right now si el dominio de la página del servidor no está incluido en una lista de permitidos.
Si es cliente de la nube de Azure US Government , el restablecimiento de PIN también intenta navegar a un dominio que no está incluido en la lista de permitidos predeterminada. El resultado es el mensaje No se puede abrir esa página en este momento.
Resolución del problema de restablecimiento de PIN de dominios permitidos
Para resolver el error, puede configurar una lista de dominios permitidos para el restablecimiento de PIN mediante la directiva ConfigureWebSignInAllowedUrls . Para obtener información sobre cómo configurar la directiva, consulte Configuración de direcciones URL permitidas para proveedores de identidades federados en dispositivos unidos a Microsoft Entra.
Inicio de sesión de confianza de clave híbrida interrumpido debido a la eliminación de la clave pública del usuario
Se aplica a:
- Implementaciones de confianza de clave híbrida
- Windows Server 2016, compila 14393.3930 a 14393.4048
- Windows Server 2019, compila 17763.1457 a 17763.1613
En las implementaciones de confianza de clave híbrida con controladores de dominio que ejecutan determinadas compilaciones de Windows Server 2016 y Windows Server 2019, la clave de Windows Hello para empresas del usuario se elimina después de iniciar sesión. Los inicios de sesión posteriores producirán un error hasta que se sincronice la clave del usuario durante el siguiente ciclo de sincronización delta de Microsoft Entra Connect.
Identificar el problema de eliminación de clave pública del usuario
Después de que el usuario aprovisiona una credencial de Windows Hello para empresas en un entorno de confianza de clave híbrida, la clave debe sincronizarse desde el identificador de Microsoft Entra a Active Directory durante un ciclo de sincronización de Microsoft Entra Connect. La clave pública del usuario se escribe en el msDS-KeyCredentialLink atributo del objeto de usuario.
Antes de que se sincronice la clave de Windows Hello para empresas del usuario, los inicios de sesión con Windows Hello para empresas producirán un error con el mensaje de error Esa opción no está disponible temporalmente. Por ahora, use un método diferente para iniciar sesión. Una vez que la clave se sincroniza correctamente, el usuario puede iniciar sesión y desbloquear con su PIN o biometría inscrita.
En entornos con el problema, una vez completado el primer inicio de sesión con Windows Hello para empresas y el aprovisionamiento, se produce un error en el siguiente intento de inicio de sesión. En entornos donde los controladores de dominio ejecutan una combinación de compilaciones, algunos usuarios pueden verse afectados por el problema y los intentos de inicio de sesión posteriores se pueden enviar a distintos controladores de dominio. El resultado son errores de inicio de sesión intermitentes.
Después del intento de inicio de sesión inicial, la clave pública de Windows Hello para empresas del usuario se elimina de msDS-KeyCredentialLink attribute. Para comprobar la eliminación, consulte el atributo de un usuario antes y después del msDS-KeyCredentialLink inicio de sesión. Puede consultar en msDS-KeyCredentialLink AD mediante Get-ADUser y especificar msds-keycredentiallink para el -Properties parámetro .
Resolución del problema de eliminación de claves públicas de usuario
Para resolver el problema, actualice los controladores de dominio de Windows Server 2016 y 2019 con las revisiones más recientes. Para Windows Server 2016, el comportamiento se corrige en la compilación 14393.4104 (KB4593226) y versiones posteriores. Para Windows Server 2019, el comportamiento se corrige en la compilación 17763.1637 (KB4592440).
Acceso a dispositivos unidos a Microsoft Entra a recursos locales mediante la confianza de clave y la entidad de certificación (CA) que no son de Microsoft
Se aplica a:
- Implementaciones de confianza clave unidas a Microsoft Entra
- Entidad de certificación (CA) que no es de Microsoft que emite certificados de controlador de dominio
Windows Hello para empresas usa la autenticación basada en tarjeta inteligente para muchas operaciones. Este tipo de autenticación tiene directrices especiales al usar una entidad de certificación que no es de Microsoft para la emisión de certificados, algunas de las cuales se aplican a los controladores de dominio. No todos los tipos de implementación de Windows Hello para empresas requieren estas configuraciones. El acceso a recursos locales desde un dispositivo unido a Microsoft Entra requiere una configuración especial cuando se usa una CA que no es de Microsoft para emitir certificados de controlador de dominio.
Para obtener más información, lea Directrices para habilitar el inicio de sesión de tarjeta inteligente con entidades de certificación que no son de Microsoft.
Identificación de problemas de acceso a recursos locales con CA que no son de Microsoft
El problema se puede identificar mediante seguimientos de red o registro de Kerberos desde el cliente. En el seguimiento de red, el cliente no puede realizar una TGS_REQ solicitud cuando un usuario intenta acceder a un recurso. En el cliente, se puede observar en el registro de eventos de la operación Kerberos en Application and Services/Microsoft/Windows/Security-Kerberos/Operational. Los registros están deshabilitados de forma predeterminada. El evento de error para este caso incluye la siguiente información:
Log Name: Microsoft-Windows-Kerberos/Operational
Source: Microsoft-Windows-Security-Kerberos
Event ID: 107
GUID: {98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1}
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Description:
The Kerberos client received a KDC certificate that does not have a matched domain name.
Expected Domain Name: ad.contoso.com
Error Code: 0xC000006D
Resolución del problema de acceso a recursos local con CA que no son de Microsoft
Para resolver el problema, los certificados de controlador de dominio deben actualizarse para que el firmante del certificado contenga la ruta de acceso del directorio del objeto de servidor (nombre distintivo).
Asunto de ejemplo: CN=DC1,OU=Domain Controllers,DC=ad,DC=contoso,DC=com
Como alternativa, puede establecer el nombre alternativo del firmante (SAN) del certificado de controlador de dominio para que contenga el nombre de dominio completo del objeto de servidor y el nombre NETBIOS del dominio. Nombre alternativo del firmante de ejemplo:
dns=dc1.ad.contoso.com
dns=ad.contoso.com
dns=ad
Se ha roto la autenticación de confianza clave para Windows Server 2019
Se aplica a:
- Windows Server 2019
- Implementaciones de confianza de clave híbrida
- Implementaciones de confianza de claves locales
Los controladores de dominio que ejecutan versiones anteriores de Windows Server 2019 tienen un problema que impide que la autenticación de confianza clave funcione correctamente. Los seguimientos de redes notifican KDC_ERR_CLIENT_NAME_MISMATCH.
Identificar el problema de autenticación de confianza clave de Windows Server 2019
En el cliente, se produce un error en la autenticación con Windows Hello para empresas con el mensaje de error Esa opción no está disponible temporalmente. Por ahora, use un método diferente para iniciar sesión.
El error se presenta en dispositivos unidos a Microsoft Entra híbrido en implementaciones de confianza clave después de aprovisionar Windows Hello para empresas, pero antes de que la clave de un usuario se sincronice desde el identificador de Microsoft Entra a Active Directory. Si la clave de un usuario no se sincroniza desde el identificador de Microsoft Entra y el msDS-keycredentiallink atributo en el objeto de usuario de AD se rellena para NGC, es posible que se produzca el error.
Otro indicador del error se puede identificar mediante seguimientos de red. Si captura seguimientos de red para un evento de inicio de sesión de confianza de clave, los seguimientos muestran un error de Kerberos con el error KDC_ERR_CLIENT_NAME_MISMATCH.
Resolución del problema de autenticación de confianza clave de Server 2019
El problema se resuelve en Windows Server 2019, compilación 17763.316 (KB4487044). Actualice todos los controladores de dominio de Windows Server 2019 a la compilación 17763.316 o posterior para resolver el problema.
Aprovisionamiento de confianza de certificados con AD FS interrumpido en Windows Server 2019
Se aplica a:
- Windows Server 2019
- Implementaciones de confianza de certificados híbridos
- Implementaciones de confianza de certificados locales
AD FS que se ejecuta en Windows Server 2019 no puede completar la autenticación del dispositivo debido a una comprobación no válida de los ámbitos entrantes en la solicitud. La autenticación de dispositivos en AD FS es un requisito para que Windows Hello para empresas inscriba un certificado mediante AD FS. El cliente bloquea el aprovisionamiento de Windows Hello para empresas hasta que la autenticación se realiza correctamente.
Identificar la confianza del certificado con el problema de inscripción de AD FS 2019
La experiencia de aprovisionamiento de Windows Hello para empresas se inicia si las comprobaciones de requisitos previos se realizan correctamente. El resultado de las comprobaciones de provisioningAdmin está disponible en los registros de eventos en Registro de dispositivos microsoft-windows-user. Si el aprovisionamiento está bloqueado porque la autenticación del dispositivo no se realiza correctamente, se registra el identificador de evento 362 que indica que el usuario se ha autenticado correctamente en el STS de la empresa: No.
Log Name: Microsoft-Windows-User Device Registration/Admin
Source: Microsoft-Windows-User Device Registration
Date: <Date and time>
Event ID: 362
Task Category: None
Level: Warning
Keywords:
User: <User SID>
Computer: <Computer name>
Description:
Windows Hello for Business provisioning will not be launched.
Device is Azure Active Directory-joined ( AADJ or DJ++ ): Yes
User has logged on with Azure Active Directory credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Not Tested
Enterprise user logon certificate template is : No ( 1 : StateNoPolicy )
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.
Si un dispositivo se unió recientemente a un dominio, puede haber un retraso antes de que se produzca la autenticación del dispositivo. Si el estado de error de esta comprobación de requisitos previos persiste, puede indicar un problema con la configuración de AD FS.
Si el problema de ámbito de AD FS está presente, los registros de eventos en el servidor de AD FS indican un error de autenticación del cliente. El error se registra en los registros de eventos en AD FS/Admin como identificador de evento 1021 y el evento especifica que el cliente tiene prohibido el acceso al recurso http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope con el ámbito ugs:
Log Name: AD FS/Admin
Source: AD FS
Date: <Date and time>
Event ID: 1021
Task Category: None
Level: Error
Keywords: AD FS
User: <ADFS service Account>
Computer: <Date and time>
Description:
Encountered error during OAuth token request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received invalid OAuth request. The client '38aa3b87-a06d-4817-b275-7a316988d93b' is forbidden to access the resource 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' with scope 'ugs'.
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String scopeParameter, String clientId, String relyingPartyId)
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()
Resolución de la confianza del certificado con el problema de inscripción de AD FS 2019
Este problema se ha corregido en Windows Server, versión 1903 y posteriores. Para Windows Server 2019, el problema se puede corregir agregando manualmente el ámbito de ugs.
Inicie la consola de administración de AD FS. Vaya a Descripciones de ámbito de servicios>.
Haga clic con el botón derecho en Descripción del ámbito y seleccione Agregar descripción del ámbito.
En Nombre, escriba ugs y seleccione Aplicar > Aceptar.
Inicie PowerShell como administrador.
Obtenga el objeto ObjectIdentifier del permiso de aplicación con el parámetro ClientRoleIdentifier igual a "38aa3b87-a06d-4817-b275-7a316988d93b":
(Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifierEjecute el comando
Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.Reinicie el servicio AD FS.
En el cliente: reinicie el cliente. Se debe pedir al usuario que aprovisione Windows Hello para empresas.