Problema

En entornos híbridos o 100 % cloud, muchos equipos intentan montar Azure Files mediante SMB 3.0 con autenticación Kerberos gestionada por Azure AD Domain Services (Azure AD DS). La configuración funciona cuando se asignan permisos a usuarios individuales, pero los grupos creados exclusivamente en Azure AD (cloud‑only groups) no se reflejan en las listas de control de acceso (ACL) del recurso compartido. El resultado es un acceso denegado aunque la pertenencia al grupo sea correcta.

Este patrón se repite en varias suscripciones: se habilita Cloud Kerberos, se marca la cuenta de almacenamiento como Premium en una región compatible y, aun así, los SID de los grupos cloud‑only no aparecen en la evaluación de permisos. La frustración radica en que la documentación menciona la necesidad de habilitar una etiqueta (kdc_enable_cloud_group_sids) pero no detalla los pasos posteriores ni los posibles bloqueos.

Causa

  1. Etiqueta no propagada
    La etiqueta kdc_enable_cloud_group_sids debe estar presente tanto en el registro de la aplicación (App Registration) como en la cuenta de almacenamiento. Si solo se actualiza el manifiesto de la app y la cuenta sigue sin la etiqueta, Azure AD DS no traduce los SID de grupos cloud‑only.

  2. Región y nivel de rendimiento
    Cloud Kerberos con soporte de grupos cloud‑only está limitado a ciertas regiones y a SKU Premium. Un despliegue en una región no soportada o en una cuenta Standard hace que el KDC ignore los grupos.

  3. Sincronización de Azure AD DS
    Azure AD DS necesita tiempo para replicar los objetos de Azure AD, incluidos los grupos cloud‑only. Si se crean o modifican grupos justo antes de montar el share, el KDC puede usar una versión incompleta del directorio.

  4. Configuración de la ACL
    Las ACL de Azure Files deben incluir explícitamente los SID de los grupos. Si se usan comandos que solo añaden usuarios, los grupos quedan fuera del árbol de permisos.

  5. Cache de Kerberos
    Los tickets Kerberos pueden quedar en caché con información de SID incompleta. Un ticket viejo impide que el cliente reciba la lista actualizada de grupos.

Solución

Una estrategia robusta combina tres acciones: (a) aplicar la etiqueta en ambos recursos, (b) validar la replicación de Azure AD DS y (c) crear las ACL usando los SID de los grupos cloud‑only. Los pasos siguientes funcionan tanto en despliegues nuevos como en entornos ya existentes.

1. Aplicar la etiqueta kdc_enable_cloud_group_sids

En la App Registration

az ad app update --id <app-object-id> --set tags='["kdc_enable_cloud_group_sids"]'

En la cuenta de almacenamiento

az storage account update \
  --name <storage-account> \
  --resource-group <rg> \
  --set tags.kdc_enable_cloud_group_sids=true

La clave es usar el mismo nombre de etiqueta en ambos lados; Azure valida la coincidencia antes de habilitar la traducción de SID.

2. Verificar la región y el SKU

az storage account show \
  --name <storage-account> \
  --resource-group <rg> \
  --query "{location:location, sku:sku.name}"

Asegúrese de que location sea una de las regiones listadas como compatibles (por ejemplo, westcentralus) y que sku.name sea Premium_LRS o Premium_ZRS.

3. Forzar la sincronización de Azure AD DS

Azure AD DS no permite un “force sync” directo, pero se puede acelerar creando un objeto temporal y eliminándolo:

az ad group create --display-name "temp-sync-$(date +%s)" --mail-nickname tempsync
az ad group delete --group <temp-group-object-id>

Esto dispara una replicación inmediata que incluye los grupos cloud‑only.

4. Añadir los SID de los grupos a la ACL del share

Obtener el SID del grupo:

az ad group show --group "<grupo-cloud-only>" --query "securityIdentifier" -o tsv

Aplicar la ACL:

az storage directory set-permission \
  --account-name <storage-account> \
  --share-name <share> \
  --path "" \
  --acl "default:group:<SID>:rwx"

Repetir para cada grupo que necesite acceso. La opción default: asegura que los archivos creados hereden los permisos.

5. Limpiar la caché Kerberos en los clientes

En Windows:

klist purge

En Linux (samba‑client):

kdestroy -A

Luego volver a montar el share para obtener un ticket nuevo que incluya los SID actualizados.

Cuándo aplicar esta solución

  • Síntomas: acceso a Azure Files funciona para usuarios individuales pero falla para miembros de grupos cloud‑only; los logs de SMB muestran “Access denied (0x5)”.
  • Entorno: uso de Azure Files con SMB 3.0, Cloud Kerberos habilitado, y grupos creados exclusivamente en Azure AD (sin on‑prem AD sync).
  • Región compatible: la cuenta está en una de las regiones listadas para Cloud Kerberos con soporte de grupos.
  • No aplica: si se utilizan grupos sincronizados desde AD on‑prem (estos ya funcionan sin la etiqueta) o si el share está configurado con NFS en lugar de SMB.

Código

# 1. Etiqueta en App Registration
az ad app update --id <app-object-id> --set tags='["kdc_enable_cloud_group_sids"]'

# 2. Etiqueta en la cuenta de almacenamiento
az storage account update \
  --name <storage-account> \
  --resource-group <rg> \
  --set tags.kdc_enable_cloud_group_sids=true

# 3. Verificar región y SKU
az storage account show \
  --name <storage-account> \
  --resource-group <rg> \
  --query "{location:location, sku:sku.name}"

# 4. Forzar replicación de Azure AD DS (temp group)
az ad group create --display-name "temp-sync-$(date +%s)" --mail-nickname tempsync
az ad group delete --group <temp-group-object-id>

# 5. Obtener SID del grupo cloud‑only
GROUP_SID=$(az ad group show --group "<grupo-cloud-only>" --query "securityIdentifier" -o tsv)

# 6. Aplicar ACL al share
az storage directory set-permission \
  --account-name <storage-account> \
  --share-name <share> \
  --path "" \
  --acl "default:group:${GROUP_SID}:rwx"

# 7. Limpiar caché Kerberos (Windows)
klist purge

# 8. Limpiar caché Kerberos (Linux)
kdestroy -A

Verificación

  1. Comprobar la ACL

    az storage directory show-permission \
  --account-name <storage-account> \
  --share-name <share> \
  --path ""

    La salida debe listar el SID del grupo bajo la columna group.

  2. Probar acceso con un miembro del grupo
    En una máquina cliente, iniciar sesión con una cuenta que pertenezca al grupo y montar el share:

    New-PSDrive -Name Z -PSProvider FileSystem -Root \\<storage-account>.file.core.windows.net\<share> -Credential (Get-Credential)

    Crear un archivo y verificar que el propietario sea el SID del grupo.

  3. Revisar logs de Azure Monitor
    Buscar eventos SMBFileShareAccessDenied que incluyan AccessDenied y confirmar que el SID del grupo aparece en la lista de “Denied SIDs”.

Si el archivo se crea sin errores y el propietario corresponde al SID del grupo, la configuración está operativa.

Notas adicionales

  • La etiqueta kdc_enable_cloud_group_sids es sensible a mayúsculas; cualquier error tipográfico impide la activación.
  • En entornos con múltiples suscripciones, la replicación de Azure AD DS puede tardar hasta 15 min; planifique una ventana de validación después de crear o modificar grupos.
  • Cuando se usan políticas de retención de tickets Kerberos largas, los clientes pueden seguir usando tickets antiguos. Automatizar la purga de caché como parte del script de montaje reduce este riesgo.
  • Si se necesita compatibilidad con versiones de Windows anteriores a 2019, considere que el soporte de Cloud Kerberos con grupos cloud‑only está disponible solo a partir de esas versiones.