Problema

En entornos híbridos cada vez más comunes, los equipos están registrados en Azure AD (Entra Joined) y gestionados por Intune. Los usuarios se conectan a recursos internos mediante una VPN (por ejemplo Cisco AnyConnect) y, aunque pueden acceder a los shares usando la ruta directa del servidor (\\server.domain.com\share), el acceso a través del DFS Namespace (\\domain.com\namespace) falla. El síntoma típico es un error de autenticación o “Network path not found”, mientras que los tickets Kerberos aparecen válidos con klist. Este patrón se repite en varias organizaciones que combinan Azure AD Join, Windows Hello for Business y DFS.

Causa

Los fallos de DFS Namespace en este escenario suelen deberse a una combinación de factores de resolución de nombres y de autenticación delegada:

  1. SPN incompleto o ausente
    DFS Namespace necesita que el Service Principal Name (SPN) del servidor de nombres incluya el FQDN (cifs/server.domain.com). Cuando los equipos están Azure AD Joined, el cliente prioriza el token de Azure AD y puede no solicitar el ticket Kerberos correcto si el SPN no está registrado.

  2. Uso de NetBIOS vs FQDN
    Si el cliente intenta resolver \\domain.com\namespace mediante NetBIOS, la petición puede terminar en un controlador de dominio que no está autorizado para delegar credenciales a los servidores de archivos, provocando un rechazo.

  3. Configuración de UseFQDN
    El parámetro del namespace (UseFQDN) controla si el cliente debe usar el FQDN del servidor de nombres. Si está desactivado o no se ha replicado correctamente, los clientes pueden seguir enviando peticiones basadas en el nombre corto.

  4. Política de Kerberos en VPN
    Algunas VPNs no transmiten los tickets Kerberos de forma transparente, o la ruta de red no está marcada como “trusted”. El cliente entonces recurre a NTLM, que DFS Namespace rechaza por defecto.

  5. Windows Hello for Business con Cloud Authentication
    Cuando la autenticación de WHfB se realiza contra Azure AD, el ticket Kerberos local puede no contener los grupos de dominio necesarios para acceder al namespace, especialmente si el recurso está protegido por ACL basadas en grupos de AD tradicionales.

Solución

La solución se basa en validar y alinear tres áreas: nombres, SPN y políticas de Kerberos. El proceso es reutilizable para cualquier entorno que combine Azure AD Join, VPN y DFS.

1. Verificar y registrar los SPN necesarios

En cada servidor que actúa como Namespace Server y como target de los folders, ejecuta:

Setspn -L server.domain.com

Busca entradas cifs/server.domain.com. Si faltan, añádelas:

Setspn -S cifs/server.domain.com server
Setspn -S host/server.domain.com server

Repite en todos los namespace servers y en los servidores de destino. Después, fuerza la replicación de AD si la infraestructura es multi‑site.

2. Forzar uso de FQDN en el cliente

Asegúrate de que la política de DFS Namespace está activada:

Set-DfsnRoot -Path "\\domain.com\namespace" -EnableRootTargetFQDN $true

En los clientes, desactiva la resolución NetBIOS para DFS:

reg add "HKLM\System\CurrentControlSet\Services\Dfs" /v "EnableRootTargetFQDN" /t REG_DWORD /d 1 /f

Reinicia el servicio Dfs o el equipo.

3. Ajustar la política de Kerberos en la VPN

En el servidor VPN, habilita el “Kerberos constrained delegation” para los servidores de archivos:

Set-ADComputer -Identity "vpnserver" -PrincipalsAllowedToDelegateToAccount "server$"

En la configuración del cliente VPN, marca la opción “Allow Kerberos tickets to be forwarded”. Si la VPN usa split‑tunnel, incluye la subred del dominio en la lista de rutas “trusted”.

4. Revisar las ACL y grupos de WHfB

Confirma que los usuarios están miembros de los grupos de dominio que tienen permiso en el namespace. En caso de usar grupos de Azure AD, crea equivalentes locales o asigna permisos a “Authenticated Users” temporalmente para probar.

5. Validar la resolución DNS

Asegúrate de que los clientes resuelven server.domain.com al IP interno correcto. En la VPN, verifica que la zona DNS interna está disponible y que la opción “Append parent suffixes” incluye domain.com.

nslookup server.domain.com

Si la respuesta es una IP pública o no se resuelve, corrige la zona DNS o agrega una zona de búsqueda secundaria en la configuración del cliente.

6. Probar con un cliente limpio

Crea una máquina virtual temporalmente Azure AD Joined sin políticas de Intune y sin WHfB. Conéctate a la VPN y prueba el acceso al namespace. Si funciona, el problema está en alguna política aplicada por Intune; revisa los perfiles de configuración de red y de Kerberos.

Cuándo aplicar esta solución

  • Síntomas: acceso directo al share funciona, pero el namespace falla; klist muestra tickets válidos; error “Network path not found” o “Access denied” al usar \\domain.com\namespace.
  • Entorno: equipos Azure AD Joined, gestión con Intune, VPN (Cisco AnyConnect, Pulse, etc.), DFS Namespace configurado con UseFQDN opcional.
  • No aplica: si el problema ocurre en equipos híbridos (on‑prem AD join) sin VPN, o si el namespace está configurado en modo “stand‑alone” sin dependencia de Kerberos.

Código

# 1. Listar SPN del servidor
Setspn -L server.domain.com

# 2. Añadir SPN faltantes
Setspn -S cifs/server.domain.com server
Setspn -S host/server.domain.com server

# 3. Habilitar uso de FQDN en el namespace (PowerShell)
Set-DfsnRoot -Path "\\domain.com\namespace" -EnableRootTargetFQDN $true

# 4. Forzar FQDN en cliente (registro)
reg add "HKLM\System\CurrentControlSet\Services\Dfs" /v "EnableRootTargetFQDN" /t REG_DWORD /d 1 /f

# 5. Verificar resolución DNS
nslookup server.domain.com

Verificación

  1. Ticket Kerberos: ejecuta klist y confirma que aparece cifs/[email protected].
  2. Acceso al namespace: abre \\domain.com\namespace\share desde el Explorador. Debería abrir sin solicitar credenciales.
  3. Comprobación de SPN: setspn -L server.domain.com muestra los SPN añadidos.
  4. Registro de eventos: revisa el visor de eventos en Microsoft‑Windows‑DFS‑Namespace/Operational para entradas “DFS Namespace access denied”.
  5. Prueba de VPN: desconecta y vuelve a conectar la VPN; repite los pasos 1‑3 para asegurarte de que la delegación persiste.

Notas adicionales

  • En entornos con varios domain controllers, la replicación de SPN puede tardar; usa repadmin /syncall para acelerar.
  • Si la VPN no soporta Kerberos, considera habilitar “Pass‑Through Authentication” en el servidor de archivos, aunque reduce la seguridad.
  • Cuando uses Windows Hello for Business con Cloud Authentication, verifica que la política “Use Windows Hello for Business on Azure AD joined devices” está alineada con los requisitos de Kerberos (se necesita la opción “Enable Kerberos authentication for Azure AD devices” en Intune).
  • Mantén una lista de los namespace servers y sus FQDN en la documentación interna; cualquier cambio de nombre o IP requiere actualizar los SPN y la política UseFQDN.