En un evento reciente me toco ver algunos equipos con Windows Hello for Business habilitados por Device Manager de Azure AD en un ambiente de sincronización de directorios, en los cuales al momento de realizar el registro o activar algún método de autenticación para WHfB se realizaba con éxito, pero luego el usuario no podía iniciar sesión con ninguno de los métodos registrados. Solo permitía al usuario ingresar con sus credenciales del dominio.
Al intentar iniciar sesión con los métodos de WHfB seleccionados se obtiene el siguiente error.
+Al validar internamente en las configuración de WHfB dentro de Windows nos indica que los métodos no están disponibles.
Entre muchos Workaround se realizó lo siguentes :
- Revisión de REGEDIT.
- Deshabilitación y habilitación de GPO’s relacionadas.
- Forzar por politicas locales los metodos biometricos en windows.
Finalmente, se le dio una revisión hacia la cuenta y a no a la configuración de WHfB o Windows como tal. Al analizar los Logs de Seguridad dentro del equipo, se detecta al iniciar sesión con los métodos registrados de WHfB el evento 4625 como autenticación fallida.
Lo interesante de este error es que la autenticación es denegada por que la cuenta no existe o la contraseña es incorrecta, cuando sabemos que ambos son correctos, pero el detalle importante es el id. de seguridad con el valor “NULL SID”.
Al realizar el registro de algunos métodos de WHfB como el PIN, se realiza una conexión hacia Azure AD para almacenar información relevante a la cuenta y al equipo. Parte de esta información es el atributo de Active Directory msDs-KeyCredentialLink el cual es sincronizado desde AD Connect hacia nuestro AD on premises por Azure AD Connect.
Al validar la cuenta de Active Directory de un usuario con WHfB funcionando con normalidad, el campo msDs-KeyCredentialLink se encuentra poblado correctamente, pero al mirar el usuario del ejemplo con problemas este campo se encuentra vacío.
Este es un indicador de que la cuenta tiene algún problema de sincronización desde Azure AD hacia nuestro Active Directory On premises. Así que para saber si efectivamente se trata de esto, vamos a nuestro servidor de Azure AD Connect y validamos las ultimas sincronizaciones ejecutadas.
AL mirar el resultado del export desde Azure AD hacia AD on premises, encontramos que hay cuentas con problemas de sincronización por permisos. (Permission-issue).
Esto quiere decir que la cuenta que realiza la sincronización por alguna razón no tiene los privilegios necesarios para escribir esos atributos. En el caso de la cuenta de ejemplo, se había creado en una OU que no tenía herencia activada desde el dominio, por lo cual la cuenta de sincronización no tenia todos los permisos necesarios, así que se modificaron las configuración de herencia de la cuenta para que obtuviera los permisos delegados desde el dominio.
Luego al realizar una nueva sincronización del directorio, la cuenta no tiene problemas para actualizarse y ahora el campo msDs-KeyCredentialLink está poblado.
Una vez resulto este problema los usuarios pueden iniciar sesión en WHfB sin problemas con cualquier método seleccionado.
Saludos,
Samuel.
