Problema

Muchas organizaciones han migrado la identidad a Azure Entra (ex‑Azure AD) y gestionan sus dispositivos con Intune. Quieren que los usuarios autenticados con Windows Hello for Business (WHfB) accedan a recursos on‑premises — por ejemplo, un NAS, un servidor de archivos o una aplicación legacy — sin volver a usar contraseñas ni crear un Active Directory tradicional. El reto es lograr esa confianza password‑less cuando solo se dispone de Azure Entra Domain Services (Azure AD DS) y no de un controlador de dominio Windows on‑premise.

Causa

  1. Kerberos sin DC tradicional – WHfB depende de tickets Kerberos para recursos on‑prem. Azure AD DS expone un KDC, pero por defecto no está configurado para confiar en claves derivadas de WHfB.
  2. Ausencia de “Hybrid Azure AD Join” – Los dispositivos deben estar registrados tanto en Azure Entra como en Azure AD DS. Si se omite el join, el cliente no solicita tickets al KDC de Azure AD DS.
  3. Política de autenticación – WHfB necesita que la política de “Passwordless authentication” esté habilitada y que los métodos de clave pública (asymmetric key) se sincronicen al KDC. Sin la política adecuada, el KDC solo acepta NTLM/Kerberos con contraseña.
  4. Configuración de SPN y delegación – Los servicios on‑prem deben exponer Service Principal Names (SPN) compatibles con Kerberos y permitir delegación constrained cuando se usan credenciales de WHfB.
  5. Redes aisladas – Si el tráfico entre la VNet donde está Azure AD DS y la red on‑prem no pasa por una VPN o ExpressRoute, los tickets nunca llegan al recurso.

Solución

La solución se basa en tres pilares: (1) preparar Azure AD DS como KDC “passwordless”, (2) asegurar que los dispositivos estén Azure‑joined y Azure AD DS‑joined, y (3) exponer los recursos on‑prem con SPN y delegación correctos. A continuación se describe un flujo reutilizable que funciona tanto en entornos de laboratorio como en producción.

1. Configurar Azure Entra Domain Services para Kerberos passwordless

  1. Activar la característica “Passwordless authentication” en Azure Entra → Security → Authentication methods → Passwordless. Marca Windows Hello for Business y habilita la opción Allow passwordless authentication for Azure AD DS.

  2. Sincronizar claves públicas: Azure AD DS necesita la clave pública del certificado de WHfB. Ejecuta en un dispositivo Azure‑joined con WHfB:

    dsregcmd /status

    Verifica que DeviceId y TenantId estén presentes. Luego, en Azure Portal, bajo Azure AD DS → Authentication, habilita Enable password hash sync for passwordless.

  3. Actualizar el KDC: En la VM que actúa como “Azure AD DS DNS forwarder” (opcional, pero recomendado), ejecuta:

    # Reinicia el servicio Kerberos para cargar la nueva configuración
sudo systemctl restart kdc

    En entornos Windows, simplemente reinicia el servicio Kerberos Key Distribution Center:

    net stop kdc
net start kdc

2. Unir dispositivos a Azure AD DS

  1. Azure‑join: Todos los equipos deben estar registrados en Azure Entra. En Intune, configura Enrollment restrictions para forzar Azure AD Join.

  2. Azure AD DS‑join: En cada dispositivo, abre una consola de PowerShell con privilegios de administrador y ejecuta:

    $domain = "<yourdomain>.onmicrosoft.com"
$ou = "OU=Devices,DC=<yourdomain>,DC=onmicrosoft,DC=com"
Add-Computer -DomainName $domain -OUPath $ou -Credential (Get-Credential) -Restart

    El proceso solicita credenciales de Azure AD; el usuario ya tiene WHfB configurado, por lo que la autenticación será passwordless.

  3. Comprobar el join: Después del reinicio, verifica con:

    dsregcmd /status | findstr /i "AzureAdJoined"
dsregcmd /status | findstr /i "DomainJoined"

    Ambas líneas deben devolver YES.

3. Preparar el recurso on‑prem (ejemplo: Synology NAS)

  1. Crear una cuenta de servicio en Azure AD DS que represente al recurso. En Azure Portal → Azure AD DS → LDAP/AD Users, crea nas_service y asigna una contraseña temporal (solo para el primer bind).

  2. Configurar SPN: En la VM que actúa como controlador de dominio (Azure AD DS), abre PowerShell y ejecuta:

    Set-ADComputer -Identity "NAS-01" -ServicePrincipalNames @("HOST/NAS-01","cifs/NAS-01")

  3. Delegación constrained: Permite que la cuenta de usuario que usará WHfB delegue al SPN del NAS:

    Set-ADUser -Identity "[email protected]" -PrincipalsAllowedToDelegateToAccount "NAS-01$"

  4. Configurar el NAS para aceptar Kerberos: En la interfaz del Synology, habilita Kerberos authentication y apunta al dominio Azure AD DS (IP del controlador de dominio). Usa la cuenta nas_service para el bind LDAP.

4. Verificar el flujo de autenticación

  1. En un dispositivo con WHfB, abre una sesión de PowerShell y solicita un ticket:

    klist get cifs/[email protected]

    Debería aparecer un ticket con Encryption type: AES256-CTS-HMAC-SHA1-96 y Auth method: Passwordless.

  2. Accede al recurso, por ejemplo:

    net use Z: \\NAS-01\share /user:NAS-01$

    La conexión debe establecerse sin solicitar contraseña.

Cuándo aplicar esta solución

  • Escenarios válidos

    • Infraestructura cloud‑native donde Azure AD DS es la única fuente de Kerberos.
    • Dispositivos gestionados con Intune y ya usan Windows Hello for Business.
    • Recursos on‑prem que pueden aceptar Kerberos (NAS, servidores SMB, aplicaciones legacy).

  • Señales de que funciona

    • klist muestra tickets con Auth method: Passwordless.
    • Accesos SMB o LDAP se completan sin prompt de credenciales.

  • Casos donde NO aplicar

    • Entornos que requieren autenticación basada en certificados de cliente X.509 externos.
    • Recursos que solo soportan NTLM y no pueden configurarse para Kerberos.
    • Redes sin conectividad segura (VPN/ExpressRoute) entre Azure VNet y la red on‑prem.

Código

# Paso 1: Habilitar passwordless en Azure AD DS (ejecutar en Azure Cloud Shell)
az ad ds update --resource-group MyRG --name myaddomain --enable-passwordless true

# Paso 2: Unir equipo a Azure AD DS
$domain = "myaddomain.onmicrosoft.com"
Add-Computer -DomainName $domain -Credential (Get-Credential) -Restart

# Paso 3: Configurar SPN y delegación en el controlador de dominio
Set-ADComputer -Identity "NAS-01" -ServicePrincipalNames @("HOST/NAS-01","cifs/NAS-01")
Set-ADUser -Identity "[email protected]" -PrincipalsAllowedToDelegateToAccount "NAS-01$"

# Paso 4: Verificar ticket Kerberos
klist get cifs/[email protected]

Verificación

  1. Comprobar estado del join

    dsregcmd /status | findstr /i "AzureAdJoined"
dsregcmd /status | findstr /i "DomainJoined"

    Ambas deben devolver YES.

  2. Listar tickets Kerberos

    klist

    Busca entradas con cifs/NAS-01 y verifica que el campo Auth method indique Passwordless.

  3. Probar acceso al recurso

    net use Z: \\NAS-01\share

    La unidad debe mapearse sin solicitar credenciales. Revisa el registro del NAS para confirmar que la autenticación fue Kerberos.

Notas adicionales

  • Sincronización de tiempo: Kerberos falla silenciosamente si la diferencia de reloj supera 5 min. Asegúrate de que todos los equipos (Azure AD DS, dispositivos y recursos on‑prem) usen NTP con la misma fuente.
  • Política de expiración de claves: WHfB renueva la clave cada 90 días. Azure AD DS sincroniza automáticamente, pero un reinicio del servicio KDC ayuda a evitar “invalid ticket” después de la rotación.
  • Depuración: Usa el visor de eventos en el controlador de dominio bajo Security → Kerberos para ver por qué un ticket es rechazado. Mensajes como KDC_ERR_PREAUTH_REQUIRED indican que la clave pública no se registró correctamente.
  • Escalado: En entornos con cientos de dispositivos, automatiza el join con Intune Device Configuration → Custom OMA-URI que ejecuta el script de Add-Computer.
  • Fallback: Mantén una cuenta de servicio con contraseña tradicional como último recurso; así, si el flujo passwordless falla, los usuarios aún pueden acceder mediante credenciales clásicas.