Problema

Los administradores que gestionan entornos 100 % cloud suelen querer que los usuarios accedan a recursos de archivo compartido sin depender de un controlador de dominio on‑premise. En Azure Files, el acceso tradicional por SMB requiere una de tres opciones: claves de cuenta, Azure AD DS o Azure AD DS sincronizado con Kerberos. Cuando la organización usa exclusivamente Microsoft Entra ID (antes Azure AD) y los equipos están registrados o híbridos, la pregunta recurrente es si es posible montar un share SMB directamente desde el Explorador de archivos, que solicite el usuario y la contraseña de Entra ID, sin tocar scripts ni almacenar claves.

Causa

El bloqueo principal proviene de la forma en que SMB negocia la autenticación. En un dominio tradicional, el cliente Windows recibe tickets Kerberos del controlador de dominio y los usa para autenticarse contra el recurso. Azure Files expone un endpoint SMB que, por defecto, acepta:

  1. Credenciales de cuenta de almacenamiento (clave primaria o secundaria).
  2. Azure AD DS (requiere un dominio administrado por Azure).
  3. Azure AD DS sincronizado con Kerberos (requiere un controlador de dominio híbrido o Azure AD DS).

Si solo está presente Microsoft Entra ID, no hay un KDC (Key Distribution Center) que emita tickets Kerberos para el recurso SMB, por lo que el cliente no tiene nada que presentar. Además, el protocolo SMB de Windows no está preparado para usar tokens OAuth directamente; necesita Kerberos o NTLM. Por eso, intentar montar \\storageaccount.file.core.windows.net\share con usuario Entra ID falla con “Access denied”.

Solución

La forma viable de cumplir los requisitos sin AD on‑premise es habilitar Azure AD DS o Azure AD DS sincronizado con Kerberos y delegar la autenticación Kerberos a Azure Files. El proceso se resume en tres pasos:

  1. Crear Azure AD DS en la misma suscripción y zona DNS que el storage account.
  2. Habilitar Azure Files con Azure AD DS authentication (propiedad azureFilesIdentityBasedAuthentication).
  3. Unir los equipos Windows a Azure AD DS mediante Azure AD Join + Azure AD DS DNS o mediante Azure AD Hybrid Join si existe sincronización.

Una vez que los equipos forman parte del dominio gestionado, Windows obtiene tickets Kerberos automáticamente al iniciar sesión con Entra ID. Al abrir el Explorador y escribir la ruta UNC, el cliente envía el ticket Kerberos y el share se monta sin solicitar credenciales adicionales.

Alternativa ligera: Azure AD + Azure AD Application Proxy

Si crear Azure AD DS resulta demasiado pesado, se puede exponer Azure Files a través de Azure AD Application Proxy con autenticación basada en Azure AD y luego mapear el recurso como unidad de red usando la URL del proxy. Esta opción sigue requiriendo una pequeña capa de redirección, pero elimina la necesidad de un dominio gestionado. La desventaja es que el rendimiento SMB se ve afectado por la capa HTTP → SMB del proxy.

Cuándo aplicar esta solución

  • Entorno 100 % cloud: no existen controladores de dominio on‑premise y todos los usuarios están en Microsoft Entra ID.
  • Política de no uso de claves: la organización prohíbe almacenar o distribuir claves de cuenta de almacenamiento.
  • Necesidad de acceso vía Explorer: los usuarios deben poder montar el share con la interfaz gráfica, sin scripts.
  • Requisitos de seguridad: se prefiere Kerberos sobre NTLM por su resistencia a replay attacks.

No es apropiado cuando:

  • Sólo se necesita acceso puntual y se permite el uso de claves de cuenta.
  • La red no permite la creación de Azure AD DS (por ejemplo, limitaciones de suscripción).
  • Se requiere rendimiento máximo y la capa de Application Proxy introducirá latencia significativa.

Código

# 1. Crear Azure AD DS (ejemplo con Azure CLI)
az ad ds create \
  --name myaddomain \
  --resource-group rg-files \
  --location eastus \
  --sku Standard

# 2. Habilitar autenticación basada en Azure AD DS en el storage account
az storage account update \
  --name mystorageacct \
  --resource-group rg-files \
  --enable-files-aad-auth true

# 3. Asignar permisos de Azure RBAC al grupo de usuarios
az role assignment create \
  --assignee-object-id <object-id-del-grupo> \
  --role "Storage File Data SMB Share Contributor" \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-files/providers/Microsoft.Storage/storageAccounts/mystorageacct

# 4. En un equipo Windows unido a Azure AD DS, montar el share
net use Z: \\mystorageacct.file.core.windows.net\share /persistent:yes

Verificación

  1. En un equipo unido a Azure AD DS, abre una consola cmd y ejecuta klist. Debería aparecer un ticket TGT para el dominio myaddomain.onmicrosoft.com.
  2. Ejecuta net use sin parámetros; la unidad Z: debe aparecer como conectada.
  3. Abre el Explorador, navega a Z:\. Crea un archivo de prueba y verifica que se replica en Azure Files.
  4. En Azure Portal, revisa el registro de actividad del storage account; debe mostrarse “SMB authentication succeeded” con el UPN del usuario.

Notas adicionales

  • Sincronización de contraseñas: si la organización usa Azure AD Connect, asegúrese de que la opción “Password hash synchronization” está habilitada; de lo contrario, los equipos híbridos no podrán obtener tickets Kerberos.
  • Firewall y redes: Azure Files SMB requiere puertos 445 y 139 abiertos hacia *.file.core.windows.net. Si la red está detrás de un firewall restrictivo, añada una regla de salida explícita.
  • Límites de Azure AD DS: el número máximo de objetos y el rendimiento de Kerberos son menores que en un AD tradicional. Para cientos de usuarios concurrentes, monitorice la métrica “Kerberos authentication latency” en Azure Monitor.
  • Política de contraseñas: los usuarios siguen usando sus credenciales de Entra ID, por lo que cualquier política de expiración o MFA se aplica automáticamente al inicio de sesión, no al montaje del share.
  • Desmontaje automático: la opción /persistent:yes mantiene la conexión tras reinicios. Si necesita que la unidad desaparezca al cerrar sesión, omita el flag.

Con Azure AD DS como puente, los usuarios pueden montar Azure Files mediante SMB directamente desde el Explorador, manteniendo la experiencia familiar y cumpliendo con las restricciones de seguridad modernas.