Problema

Muchas organizaciones están migrando a Microsoft Entra ID y gestionando equipos con Intune, pero aún necesitan compartir archivos de forma estructurada: configuraciones de software en unidades fijas, repositorios de medios de gran tamaño y acceso rápido desde varios sitios. El reto es encontrar una solución que:

  • Proporcione autenticación basada en Entra ID o AD híbrido sin requerir cuentas locales.
  • Permita montar unidades de red automáticamente al iniciar sesión.
  • Ofrezca caché local o aceleración para evitar que todo el tráfico I/O atraviese la WAN.
  • Escale a varios centros sin perder rendimiento.

En la práctica, los administradores evalúan Azure File Share con Azure File Sync, SMB tradicional sobre un NAS QNAP y la herramienta Qsync de QNAP. Cada opción tiene ventajas y limitaciones que dependen del modelo de identidad, la topología de red y los requisitos de disponibilidad.

Causa

Los síntomas típicos provienen de tres áreas clave:

  1. Modelo de identidad incompleto – Cuando solo se usa Entra ID, los recursos SMB que dependen de Kerberos requieren un dominio AD híbrido o Azure AD DS. Sin esa capa, la autenticación falla o se recurre a credenciales locales.
  2. Falta de caché local – Azure File Share “solo cloud” envía cada operación de lectura/escritura al datacenter, lo que genera latencia alta en conexiones WAN. La ausencia de un agente de sincronización local elimina la posibilidad de trabajar offline.
  3. Arquitectura de red monolítica – Un único NAS en una sede actúa como cuello de botella para usuarios remotos. Sin replicación o balanceo de carga, el ancho de banda disponible se consume rápidamente con archivos multimedia.

Estos factores aparecen con frecuencia cuando se combina una infraestructura on‑premises ligera (VMs, NAS) con una estrategia de identidad basada exclusivamente en la nube.

Solución

Una arquitectura híbrida que combine Azure File Sync (AFS) con SMB tradicional y, opcionalmente, Qsync para casos locales, cubre la mayoría de los requisitos.

1. Azure File Sync como capa de caché

AFS permite registrar servidores Windows on‑premises como endpoints que sincronizan carpetas con un Azure File Share. El flujo es:

  • Los usuarios se autentican con Entra ID → Azure AD DS (si se habilita) → Kerberos/NTLM sobre SMB.
  • El endpoint local mantiene una copia caché de los archivos más accedidos. Las lecturas posteriores se sirven localmente; solo los cambios se replican al cloud.
  • La sincronización es bidireccional, por lo que los archivos creados en la nube aparecen automáticamente en los endpoints.

Requisitos

  • Azure AD DS o un dominio AD híbrido (Azure AD Connect). No es necesario desplegar controladores de dominio completos; Azure AD DS provee Kerberos y LDAP sin infraestructura física.
  • Un servidor Windows Server 2016+ como host de AFS. La carga de trabajo de sincronización es ligera; el hardware existente suele ser suficiente.

2. SMB tradicional para aplicaciones que exigen rendimiento local

Algunos paquetes de software requieren rutas de acceso fijas (por ejemplo, Z:\Config). Montar un recurso SMB desde el endpoint de AFS o directamente desde el NAS QNAP garantiza la compatibilidad con rutas estáticas y permisos NTFS granulares.

Implementación rápida

  • Crear un script de inicio de sesión (Intune PowerShell) que ejecute New-PSDrive o net use con la cuenta de usuario.
  • Configurar ACLs en el share para “ReadOnly” a grupos de usuarios y “FullControl” a administradores.

3. Qsync como complemento local

Qsync es útil cuando la mayor parte del tráfico proviene de la sede donde está el QNAP. Se puede habilitar SSO mediante Azure AD DS, pero la integración no cubre SMB; Qsync funciona sobre su propio cliente y mantiene una carpeta sincronizada en el equipo.

Escenario recomendado

  • Usa Qsync para distribuir archivos de configuración que cambian raramente y que deben estar disponibles incluso sin conexión a la red corporativa.
  • Para grandes medios, delega la distribución a AFS + SMB, ya que Qsync no está optimizado para archivos de varios gigabytes.

4. Redundancia y escalabilidad multi‑sitio

Para organizaciones con varias sedes:

  1. Despliega un endpoint AFS por sitio. Cada sitio mantiene su caché local, reduciendo la latencia WAN.
  2. Configura Azure File Sync Cloud Tiering (si está disponible) para que los archivos menos usados permanezcan solo en la nube, liberando espacio en los discos locales.
  3. Opcionalmente, habilita Azure File Share Private Endpoint para evitar tráfico por internet y usar la red de Azure ExpressRoute o VPN.

Cuándo aplicar esta solución

Señal Solución adecuada
Necesidad de montar unidades fijas en el arranque del usuario SMB sobre Azure File Sync endpoint
Usuarios distribuidos en varias regiones con ancho de banda limitado AFS con caché local por sitio
Archivos de configuración estáticos que deben estar disponibles offline Qsync cliente + SSO (Azure AD DS)
Requerimiento de control de versiones y auditoría centralizada Azure File Share (integrado con Azure Monitor)
No se dispone de AD híbrido y la única identidad es Entra ID Implementar Azure AD DS (sin servidores físicos) antes de usar AFS

No aplicar si:

  • La carga de trabajo es exclusivamente de archivos temporales que no requieren persistencia.
  • La infraestructura no permite instalar un servidor Windows (por ejemplo, solo Linux). En ese caso, evalúe soluciones NFS con Azure Files Premium.

Código

# Montar el share sincronizado en el inicio de sesión (Intune PowerShell script)
$share = "\\filesync.company.local\deptshare"
$drive = "Z:"
$cred = Get-Credential -Message "Credenciales de dominio"
New-PSDrive -Name $drive.TrimEnd(":") -PSProvider FileSystem -Root $share -Credential $cred -Persist

Verificación

  1. Autenticación – Inicia sesión con una cuenta Entra ID, verifica que whoami /upn muestra el UPN correcto y que klist contiene un ticket Kerberos para el share.
  2. Caché local – En el endpoint AFS, abre el Explorador de archivos, accede a un archivo grande y revisa la carpeta C:\Program Files\AzureFileSync\SyncCache. La presencia del archivo indica caché.
  3. Sincronización bidireccional – Copia un archivo desde el endpoint a Azure Files y confirma que aparece en otro endpoint después de unos minutos.
  4. Rendimiento – Ejecuta robocopy entre dos equipos del mismo sitio y compara la velocidad con una transferencia entre sitios. La diferencia debe reflejar la ventaja del caché local.

Notas adicionales

  • Azure AD DS cobra por hora y por número de objetos sincronizados. En entornos pequeños, el coste suele ser inferior al de mantener controladores de dominio on‑premises.
  • Cuando se usa Cloud Tiering, los archivos marcados como “cold” aparecen como placeholders en el endpoint. Acceder a ellos genera una llamada a Azure, lo que puede sorprender a usuarios que esperan acceso instantáneo.
  • En QNAP, la función Real‑time Remote Replication solo replica a otro QNAP y no ofrece consolidación de cambios como AFS. Úsela solo para copias de seguridad entre sedes, no como mecanismo de distribución de archivos activos.
  • Mantenga los grupos de seguridad en Azure AD sincronizados con los grupos locales de AD DS para evitar desalineaciones de permisos. Un script de PowerShell que ejecute Add-ADGroupMember contra Azure AD DS simplifica la gestión.

Con esta combinación de Azure File Sync, SMB tradicional y Qsync, se cubren los casos de uso más comunes: rutas fijas de configuración, distribución de medios de gran tamaño y disponibilidad offline, todo bajo un modelo de identidad basado en Entra ID y sin necesidad de desplegar un dominio AD completo en cada sede.