Problema

En entornos híbridos donde los dispositivos están Hybrid Azure AD Joined y se utiliza Windows Hello for Business (WHfB) con Cloud Kerberos Trust, es frecuente que algunos usuarios no puedan iniciar sesión con el PIN recién creado. El proceso de registro del PIN y la generación de la clave NGC (NGC = Next Generation Credentials) finalizan sin errores, pero al intentar el logon Windows muestra inmediatamente un fallo y escribe en el registro de eventos:

  • Event 7001 – Provisioning Type: Cloud Trust – Authentication failure, status 0xC000005E.
  • Event 214 – LSA authentication package not found – Package: CloudAP – “The implementation cannot perform the request”.

Los dispositivos aparecen como AzureAdJoined: YES, DomainJoined: YES, con todos los tickets (PRT, CloudTGT, OnPremTGT) presentes, y el contenedor NGC está presente en el CSP. Sin embargo, la autenticación local basada en PIN nunca llega a completarse.

Este patrón se repite en varios clientes, mientras que otros equipos con la misma configuración funcionan sin problemas.

Causa

Los errores 7001 y 214 suelen estar ligados a la desincronización entre el objeto de credencial en AD y la representación local del contenedor NGC. Las causas más habituales son:

  1. Sincronización interrumpida de Azure AD Connect mientras los usuarios completaban el enrolamiento de WHfB.

    • La pausa impide que el atributo msDS-KeyCredentialLink se escriba en AD antes de que el cliente intente validar la clave.
    • Cuando la sincronización se reanuda, el contenedor local ya está creado pero el registro en AD sigue faltando o está corrupto, provocando que CloudAP no encuentre el paquete de autenticación.

  2. Inconsistencias de CloudAP en el registro de Windows.

    • El paquete CloudAP se registra durante la primera fase de enrolamiento. Si la escritura del enlace de credencial falla, el paquete queda “huérfano”, lo que genera el Event 214.

  3. Política de Intune que fuerza el uso de Cloud Trust sin que el dispositivo haya completado la fase de “Key Trust”.

    • En dispositivos donde la política se aplica antes de que el objeto de AD exista, el cliente intenta usar Cloud Trust inmediatamente y falla.

  4. Problemas de TPM o del CSP que impiden que la clave se firme correctamente contra el certificado de la autoridad de confianza.

    • Aunque el TPM esté presente, una actualización de firmware o un driver desalineado puede dejar al CSP sin la capacidad de firmar, resultando en un error de autenticación que se refleja como 0xC000005E.

En la práctica, el factor crítico es la desincronización del atributo msMS-KeyCredentialLink entre Azure AD y AD on‑premises, combinada con la presencia de un paquete CloudAP incompleto.

Solución

El objetivo es restablecer la cadena de confianza entre AD, Azure AD y el cliente. El proceso se puede dividir en tres fases: diagnóstico, corrección del enlace de credencial y re‑provisionado del PIN.

1. Verificar el estado de sincronización y el atributo en AD

# 1.1 Comprobar que Azure AD Connect está sincronizando
Get-ADSyncScheduler | Select-Object -Property SyncCycleEnabled,SyncCycleInterval

# 1.2 Obtener el atributo msDS-KeyCredentialLink del usuario problemático
Get-ADUser -Identity <samAccountName> -Properties msDS-KeyCredentialLink |
  Select-Object -ExpandProperty msDS-KeyCredentialLink
  • Si el atributo está vacío o contiene una referencia a un contenedor que no existe, la causa es la sincronización interrumpida.

2. Forzar una re‑escritura del atributo

  1. Eliminar manualmente el enlace dañado (solo si está presente pero corrupto):
Set-ADUser -Identity <samAccountName> -Clear msDS-KeyCredentialLink
  1. Ejecutar una sincronización delta para que Azure AD Connect vuelva a escribir el enlace:
Start-ADSyncSyncCycle -PolicyType Delta
  1. Confirmar que el atributo se ha repoblado con el comando del paso 1.2.

3. Regenerar el contenedor NGC en el cliente

En el equipo afectado:

# 3.1 Eliminar el contenedor existente
certutil -DeleteHelloContainer

# 3.2 Reiniciar el servicio de CloudAP
net stop CloudAP
net start CloudAP

# 3.3 Volver a crear el PIN (interfaz gráfica > Configuración > Cuentas > Opciones de inicio de sesión)

# 3.4 Verificar que el contenedor se ha creado
certutil -csp "Microsoft Passport Key Storage Provider" -key

4. Validar la política de Intune

  • Asegurarse de que la política UseCloudTrustForOnPremAuth = 1 se aplica después de que el atributo msDS-KeyCredentialLink exista.
  • Si la política se está aplicando prematuramente, crear una regla de asignación que dependa del estado de registro (deviceCompliancePolicy) o retrasar la aplicación mediante un script de PowerShell que verifique la presencia del atributo antes de habilitar la política.

5. Re‑registrar el dispositivo en Azure AD (opcional)

Si los pasos anteriores no resuelven el problema, re‑registrar el dispositivo puede limpiar cualquier referencia residual:

dsregcmd /leave
dsregcmd /join

Después de la unión, ejecutar:

dsregcmd /status

para confirmar que DeviceAuthStatus : SUCCESS y NgcSet : YES.

Cuándo aplicar esta solución

  • Síntomas: Fallos de logon con PIN, eventos 7001 (0xC000005E) y 214 (CloudAP) en el visor de eventos, NgcSet : YES pero DeviceAuthStatus : SUCCESS sin posibilidad de iniciar sesión.
  • Entorno: Hybrid Azure AD Join, WHfB con Cloud Kerberos Trust, Intune gestionando la política, Azure AD Connect activo.
  • No aplicar: Si el error ocurre en dispositivos que nunca han creado un contenedor NGC (por ejemplo, equipos sin TPM) o si el atributo msDS-KeyCredentialLink está correctamente poblado y la sincronización está activa; en esos casos el problema suele estar en el CSP o en la configuración de TPM, lo que requiere reinstalación de drivers o firmware.

Código

# Verificar estado de registro del dispositivo
dsregcmd /status

# Forzar refresco del PRT (si está presente pero caducado)
dsregcmd /refreshprt

# Eliminar contenedor NGC y volver a crear PIN
certutil -DeleteHelloContainer
certutil -csp "Microsoft Passport Key Storage Provider" -key

# Reiniciar servicios críticos
net stop CloudAP
net start CloudAP

Verificación

  1. Eventos: Después de la corrección, el visor de eventos ya no debe registrar Event 7001 ni Event 214.
  2. Logon: El usuario debe poder iniciar sesión con el PIN recién creado sin que el proceso se interrumpa.
  3. Estado del dispositivo: dsregcmd /status muestra DeviceAuthStatus : SUCCESS y NgcSet : YES.
  4. AD: Get-ADUser … -Properties msDS-KeyCredentialLink devuelve una cadena válida que apunta a un contenedor existente.

Repetir la prueba en al menos dos dispositivos de muestra para confirmar que la solución es reproducible.

Notas adicionales

  • Cuando se trabaja con Cloud Kerberos Trust, es buena práctica habilitar la auditoría de sincronización en Azure AD Connect (-Verbose) para detectar pausas inesperadas.
  • En entornos con alta rotación de usuarios, automatizar la verificación del atributo msDS-KeyCredentialLink mediante un script de PowerShell reduce el tiempo de detección de este tipo de desalineación.
  • Si el problema persiste después de los pasos anteriores, revisar los logs de CloudAP en %ProgramData%\Microsoft\Windows\DeviceManagement\Logs\CloudAP.log puede revelar errores de firma de TPM o problemas de certificado de la autoridad de confianza.

Con este enfoque se cubren los escenarios más habituales que provocan fallos de PIN login y Windows Hello for Business en configuraciones híbridas, ofreciendo una ruta clara para restablecer la autenticación sin necesidad de reinstalar el sistema operativo.