Introducción a las opciones de autenticación basada en la identidad de Azure Files con el acceso SMB

En este artículo se explica la forma en que los recursos compartidos de archivos de Azure pueden usar los servicios de dominio, ya sea de forma local o en Azure, para admitir el acceso basado en la identidad a los recursos compartidos de archivos de Azure en SMB. La habilitación del acceso basado en identidad de los recursos compartidos de archivos de Azure permite reemplazar los servidores de archivos existentes por recursos compartidos de archivos de Azure sin reemplazar el servicio de directorio existente, con lo que se mantiene el acceso sin problemas de los usuarios a los recursos compartidos.

Glosario

Es útil comprender algunos términos clave relacionados con la autenticación basada en la identidad para recursos compartidos de archivos de Azure:

• Autenticación Kerberos

  Kerberos es un protocolo de autenticación que se utiliza para comprobar la identidad de un usuario o un host. Para más información sobre Kerberos, consulte Introducción a la autenticación Kerberos.

• Protocolo Bloque de mensajes del servidor (SMB)

  SMB es un protocolo de uso compartido de archivos de red estándar del sector. Para más información sobre SMB, consulte Microsoft SMB Protocol and CIFS Protocol Overview (Introducción a los protocolos CIFS y SMB de Microsoft).

• Microsoft Entra ID

  Microsoft Entra ID (anteriormente Azure AD) es el directorio multiinquilino basado en la nube y el servicio de administración de identidades de Microsoft. Microsoft Entra ID combina servicios de directorio fundamentales, administración del acceso a las aplicaciones y protección de identidades en una única solución.

• Servicios de dominio de Microsoft Entra

  Microsoft Entra Domain Services proporciona servicios de dominio administrados como, por ejemplo, unión a un dominio, directivas de grupo, LDAP y autenticación Kerberos/NTLM. Estos servicios son totalmente compatibles con Active Directory Domain Services. Para más información, consulte Microsoft Entra Domain Services.

• Active Directory Domain Services (AD DS) local

  La integración de Active Directory Domain Services (AD DS) local en Azure Files proporciona los métodos para almacenar datos de directorio y poner dichos datos a disposición de los usuarios y administradores de la red. La seguridad se integra en AD DS mediante la autenticación de inicio de sesión y el control de acceso a los objetos del directorio. Con un único inicio de sesión de red, los administradores pueden administrar los datos del directorio y la organización a través de su red, y los usuarios de red autorizados pueden tener acceso a los recursos en cualquier parte de la red. Normalmente, las que adoptan AD DS son empresas en entornos locales o en máquinas virtuales hospedadas en la nube, que usan las credenciales de AD DS para el control de acceso. Para obtener más información, consulte Introducción a Active Directory Domain Services.

• Control de acceso basado en roles de Azure (Azure RBAC)

  RBAC de Azure permite la administración detallada del acceso a Azure. Con Azure RBAC, puede administrar el acceso a los recursos mediante la concesión a los usuarios del menor número de permisos necesarios para realizar su trabajo. Para obtener más información, consulte ¿Qué es el control de acceso basado en rol de Azure (RBAC)?

• Identidades híbridas

  Las identidades de usuario híbridas son identidades de AD DS sincronizadas con Microsoft Entra ID mediante la aplicación de sincronización de Microsoft Entra Connect local o Microsoft Entra Connect Cloud Sync, un agente ligero que se puede instalar desde el Centro de Administración de Microsoft Entra.

Escenarios de autenticación admitidos

Azure Files admite la autenticación basada en la identidad en SMB mediante los métodos siguientes. Solo puede usar un método por cuenta de almacenamiento.

• Autenticación AD DS local: Las máquinas Windows unidas a AD DS local o a Microsoft Entra Domain Services pueden acceder a los recursos compartidos de archivos de Azure con las credenciales de Active Directory local que se sincronizan con Microsoft Entra ID a través de SMB. El cliente debe tener conectividad de red no impedida a su AD DS. Si ya tiene AD DS configurado en el entorno local o en una máquina virtual en Azure donde los dispositivos están unidos a un dominio de AD, debe usar AD DS para la autenticación en los recursos compartidos de archivos de Azure.
• autenticación de Microsoft Entra Domain Services: máquinas virtuales basadas en la nube de Windows unidas a Microsoft Entra Domain Services pueden acceder a recursos compartidos de archivos de Azure con credenciales de Microsoft Entra. En esta solución, Microsoft Entra ID ejecuta un dominio de Windows Server Active Directory tradicional en nombre del cliente, que es un elemento secundario del inquilino de Microsoft Entra del cliente.
• Kerberos de Microsoft Entra para identidades híbridas: el uso de Microsoft Entra ID para la autenticación de identidades híbridas de usuario permite a los usuarios de Microsoft Entra acceder a recursos compartidos de archivos de Azure mediante la autenticación Kerberos. Esto significa que los usuarios finales pueden acceder a los recursos compartidos de archivos de Azure a través de Internet sin necesidad de tener conectividad de red a los controladores de dominio desde máquinas virtuales unidas a Microsoft Entra híbrido y a Microsoft Entra. Las identidades solo en la nube no se admiten actualmente.
• Autenticación Kerberos de AD para clientes Linux: los clientes Linux pueden usar la autenticación Kerberos a través de SMB para Azure Files mediante AD DS local o Microsoft Entra Domain Services.

Restricciones

• Ninguno de los métodos de autenticación admite la asignación de permisos de nivel de recurso compartido a cuentas de equipo (cuentas de máquina) mediante RBAC de Azure, ya que las cuentas de equipo no se pueden sincronizar con una identidad en Microsoft Entra ID. Si quiere permitir que una cuenta de equipo acceda a recursos compartidos de archivos de Azure mediante la autenticación basada en identidades, use un permiso de nivel de recurso compartido predeterminado o considere la posibilidad de usar una cuenta de inicio de sesión del servicio en su lugar.
• No se admite la autenticación basada en identidad con recursos compartidos de archivos de Network File System (NFS).

Casos de uso comunes

La autenticación basada en identidades con Azure Files puede ser útil en diversos escenarios:

Reemplazo de servidores de archivos locales

Dejar de usar y reemplazar servidores de archivos locales dispersos es un problema común que toda empresa encuentra en su recorrido de modernización de TI. Los recursos compartidos de archivos de Azure con la autenticación de AD DS local son los más idóneos aquí, cuando puede migrar los datos a Azure Files. Una migración completa le permitirá aprovechar las ventajas de alta disponibilidad y escalabilidad, a la vez que minimiza los cambios del lado cliente. Proporciona una experiencia de migración perfecta para los usuarios finales, para que puedan seguir accediendo a sus datos con las mismas credenciales mediante sus equipos unidos a un dominio existente.

Migración "lift-and-shift" de aplicaciones a Azure

Al aplicar migraciones "lift-and-shift" de aplicaciones a la nube, querrá mantener el mismo modelo de autenticación para los datos. A medida que se amplía la experiencia de control de acceso basado en identidad a los recursos compartidos de archivos de Azure, se elimina la necesidad de cambiar la aplicación a los métodos de autenticación modernos y acelerar la adopción de la nube. Los recursos compartidos de archivos de Azure ofrecen la opción de integrarse en Microsoft Entra Domain Services o AD DS local para la autenticación. Si tiene pensado pasarse un 100 % a la nube nativa y minimizar los esfuerzos de administración de infraestructuras en la nube, puede que Microsoft Entra Domain Services sea una mejor opción como servicio de dominio totalmente administrado. Si necesita compatibilidad total con las funcionalidades de AD DS, puede tener en cuenta la posibilidad de ampliar el entorno de AD DS a la nube mediante controladores de dominio autohospedados en máquinas virtuales. En cualquier caso, proporcionamos flexibilidad para elegir el servicio de dominio que mejor se adapte a sus necesidades empresariales.

Copia de seguridad y recuperación ante desastres (DR)

Si mantiene el almacenamiento de archivos principal en el entorno local, los recursos compartidos de archivos de Azure pueden servir como almacenamiento ideal para copias de seguridad o recuperación ante desastres, lo que mejora la continuidad empresarial. Puede usar recursos compartidos de archivos de Azure para realizar copias de seguridad de los datos a partir de servidores de archivos existentes, a la vez que conserva las listas de control de acceso discrecionales de Windows (DACL). En escenarios de recuperación ante desastres, puede configurar una opción de autenticación para admitir el cumplimiento adecuado del control de acceso en la conmutación por error.

Ventajas de la autenticación basadas en identidad

La autenticación basada en identidad para Azure Files ofrece varias ventajas respecto al uso de la autenticación de clave compartida:

• Ampliar la experiencia tradicional de acceso compartido de archivos basada en identidad en la nube
  Si tiene previsto realizar una migración "lift-and-shift" de su aplicación a la nube, mediante el reemplazo de los servidores de archivos tradicionales con recursos compartidos de archivos de Azure, tal vez quiera que la aplicación se autentique con las credenciales de AD DS local o Microsoft Entra Domain Services para acceder a los datos de los archivos. Azure Files admite el uso de credenciales de AD DS local o de Microsoft Entra Domain Services para tener acceso a los recursos compartidos de archivos de Azure a través de SMB desde VM unidas a un dominio de AD DS local o Microsoft Entra Domain Services.

• Aplicar el control de acceso granular en recursos compartidos de archivos de Azure
  Puede conceder permisos a una identidad específica en el nivel de recurso compartido, directorio o archivo. Por ejemplo, suponga que tiene varios equipos que utilizan un solo recurso compartido de archivos de Azure para la colaboración en proyectos. Puede conceder a todos los equipos acceso a directorios no confidenciales, al tiempo que limita el acceso a directorios que contienen datos financieros confidenciales únicamente a su equipo de financiero.

• Realizar copias de seguridad de ACL de Windows (también conocidas como permisos NTFS) junto con los datos
  Puede usar recursos compartidos de archivos de Azure para realizar copias de seguridad de los recursos compartidos de archivos locales existentes. Azure Files conserva las listas de control de acceso junto con los datos cuando se hace una copia de seguridad de un recurso compartido de archivos en recursos compartidos de archivos de Azure sobre SMB.

Funcionamiento

Los recursos compartidos de archivos de Azure utilizan el protocolo Kerberos para la autenticación con un origen de AD. Cuando una identidad asociada con un usuario o una aplicación que se ejecuta en un cliente intenta acceder a los datos de recursos compartidos de archivos de Azure, la solicitud se envía al origen de AD para autenticar la identidad. Si la autenticación es correcta, devuelve un token de Kerberos. El cliente envía una solicitud que incluye el token de Kerberos, y los recursos compartidos de archivos de Azure usan ese token para autorizar la solicitud. Los recursos compartidos de archivos de Azure solo reciben el token de Kerberos, no las credenciales de acceso del usuario.

Puede habilitar la autenticación basada en la identidad en las cuentas de almacenamiento nuevas y existentes mediante uno de los tres orígenes de AD: AD DS, Microsoft Entra Domain Services y Kerberos de Microsoft Entra (solo para las identidades híbridas). Solo se puede usar un origen de AD para la autenticación de acceso a archivos en la cuenta de almacenamiento, lo que se aplica a todos los recursos compartidos de archivos de la cuenta. Para poder habilitar la autenticación basada en identidades en la cuenta de almacenamiento, primero debe configurar el entorno del dominio.

AD DS

En el caso de la autenticación de AD DS local, primero debe configurar los controladores de dominio de AD y unir el dominio de sus máquinas o máquinas virtuales. Puede hospedar los controladores de dominio en máquinas virtuales de Azure o en un entorno local. En cualquier caso, los clientes unidos a un dominio deben tener una conectividad de red no impedida al controlador de dominio, por lo que deben estar en la red corporativa o en la red virtual (VNet) del servicio de dominio.

En este diagrama se muestra la autenticación de AD DS local en recursos compartidos de archivos de Azure a través de SMB. El AD DS local debe sincronizarse con Microsoft Entra ID mediante Microsoft Entra Connect Sync o la sincronización en la nube de Microsoft Entra Connect. Solo se pueden autenticar y autorizar a las identidades de los usuarios híbridos que existen en el AD DS local y en Microsoft Entra ID para el acceso a recursos compartidos de archivos de Azure. Esto se debe a que el permiso de nivel de recurso compartido se configura con respecto a la identidad representada en Microsoft Entra ID, mientras que el permiso de nivel de archivo o directorio se aplica con el de AD DS. Asegúrese de configurar los permisos correctamente con el mismo usuario híbrido.

Para más información sobre cómo habilitar la autenticación de AD DS, primero lea Introducción: autenticación de Active Directory Domain Services local en SMB para recursos compartidos de archivos de Azure y, después, Habilitar la autenticación de AD DS para los recursos compartidos de archivos de Azure.

Servicios de dominio de Microsoft Entra

En el caso de la autenticación de Microsoft Entra Domain Services, debe habilitar Microsoft Entra Domain Services y unir a un dominio las VM desde las que tiene pensado obtener acceso a los datos de los archivos. La VM unida a un dominio debe residir en la misma red virtual (Vnet) que la instancia de Microsoft Entra Domain Services.

Este diagrama representa el flujo de trabajo para la autenticación de Microsoft Entra Domain Services en recursos compartidos de archivos de Azure a través de SMB. Sigue un patrón similar a la autenticación de AD DS local, pero hay dos diferencias principales:

1. No es necesario crear la identidad en Microsoft Entra Domain Services para representar la cuenta de almacenamiento. Esto lo realiza el proceso de habilitación en segundo plano.

2. Todos los usuarios que existen en Microsoft Entra ID se pueden autenticar y autorizar. El usuario puede ser híbrido o estar solo en la nube. La plataforma administra la sincronización de Microsoft Entra ID a Microsoft Entra Domain Services sin necesidad de ninguna configuración de usuario. Sin embargo, el cliente debe estar unido al dominio hospedado de Microsoft Entra Domain Services. No se puede estar unido ni registrado a Microsoft Entra. Microsoft Entra Domain Services no admite los clientes que no son de Azure (es decir, los equipos portátiles de usuario, las estaciones de trabajo, las máquinas virtuales en otras nubes, etc.) que se unan a al dominio hospedado de Microsoft Entra Domain Services. Sin embargo, es posible montar un recurso compartido de archivos desde un cliente no unido a un dominio proporcionando credenciales explícitas como DOMAINNAME\username o mediante el nombre de dominio completo (username@FQDN).

Para aprender a habilitar la autenticación de Microsoft Entra Domain Services, consulte Habilitación de la autenticación de Microsoft Entra Domain Services en Azure Files.

Microsoft Entra Kerberos para identidades híbridas

La habilitación y configuración de Microsoft Entra ID para autenticar identidades de usuarios híbridas permite a los usuarios de Microsoft Entra acceder a recursos compartidos de archivos de Azure mediante la autenticación Kerberos. Esta configuración usa Microsoft Entra ID para emitir los vales de Kerberos necesarios para acceder al recurso compartido de archivos con el protocolo SMB estándar del sector. Esto significa que los usuarios finales pueden acceder a los recursos compartidos de archivos de Azure a través de Internet sin necesidad de tener conectividad de red a los controladores de dominio desde máquinas virtuales unidas a Microsoft Entra híbrido y a Microsoft Entra. Sin embargo, la configuración de permisos de nivel de archivo y directorio de usuarios y grupos requiere conectividad de red no impedida al controlador de dominio local.

Importante

La autenticación Kerberos de Microsoft Entra solo admite las identidades de usuario híbridas; no admite identidades solo en la nube. Se necesita una implementación tradicional de AD DS y debe sincronizarse con Microsoft Entra ID mediante Microsoft Entra Connect Sync o la sincronización en la nube de Microsoft Entra Connect. Los clientes deben estar unido a Microsoft Entra o a Microsoft Entra híbrido. Kerberos de Microsoft Entra no se admite en clientes unidos a Microsoft Entra Domain Services o unidos solo a AD.

Para aprender a habilitar la autenticación Kerberos de Microsoft Entra para identidades híbridas, consulte Activación de la autenticación Kerberos de Microsoft Entra para identidades híbridas en Azure Files.

También puede usar esta característica para almacenar perfiles de FSLogix en recursos compartidos de archivos de Azure para máquinas virtuales unidas a Microsoft Entra. Para obtener más información, consulte Creación de un contenedor de perfil con Azure Files y Microsoft Entra ID.

Control de acceso

Azure Files aplica la autorización en el acceso del usuario tanto a nivel del recurso compartido como a los niveles de directorio o archivo. La asignación de permisos de nivel de recurso compartido se puede llevar a cabo en usuarios o grupos de Microsoft Entra administrados con Azure RBAC. Con Azure RBAC, las credenciales que se usan para el acceso a archivos deben estar disponibles o sincronizadas con Microsoft Entra ID. Para conceder acceso a un recurso compartido de archivos de Azure, puede asignar roles integrados de Azure, como el de lector de recursos compartidos de SMB de datos de archivos de almacenamiento, a usuarios o grupos en Microsoft Entra ID.

En el nivel de directorio o archivo, Azure Files admite la conservación, la herencia y la aplicación de listas ACL de Windows, igual que cualquier servidor de archivos de Windows. Si lo desea, puede mantener las listas ACL de Windows al copiar datos a través de SMB entre su recurso compartido de archivos y los recursos compartidos de archivos de Azure. Independientemente de que se tenga previsto aplicar la autorización o no, se pueden usar los recursos compartidos de archivos de Azure para hacer copias de seguridad de las ACL junto con los datos.

Configuración de los permisos de nivel de recurso compartido para Azure Files

Una vez que haya habilitado un origen de AD en la cuenta de almacenamiento, debe realizar una de las siguientes acciones para acceder al recurso compartido de archivos:

• Establecer un permiso de nivel de recurso compartido predeterminado que se aplique a todos los usuarios y grupos autenticados
• Asignación de roles RBAC de Azure integrados a usuarios y grupos, o
• Configurar roles personalizados para las identidades de Microsoft Entra y asignar derechos de acceso a los recursos compartidos de archivos en la cuenta de almacenamiento.

El permiso de nivel de recurso compartido asignado permite a la identidad concedida obtener acceso solo al recurso compartido, a nada más, ni siquiera al directorio raíz. Aún es necesario configurar por separado los permisos de nivel de directorio y de archivo.

Configuración de los permisos de nivel de archivo o directorio para Azure Files

Los recursos compartidos de archivos de Azure aplican listas de control de acceso estándar de Windows en el nivel de archivo y directorio, incluido el directorio raíz. La configuración de permisos de nivel de archivo o directorio se admite sobre SMB y REST. Monte el recurso compartido de archivos de destino de la VM y configure los permisos mediante el Explorador de archivos de Windows, o el comando de Windows icacls o Set-ACL.

Uso de la clave de cuenta de almacenamiento para los permisos de superusuario

Un usuario con la clave de cuenta de almacenamiento puede acceder a los recursos compartidos de archivos de Azure con permisos de superusuario. Los permisos de superusuario omiten todas las restricciones de control de acceso.

Importante

Nuestro procedimiento recomendado de seguridad es evitar el uso compartido de las claves de cuenta de almacenamiento y aprovechar la autenticación basada en identidad siempre que sea posible.

Conservación de las listas de control de acceso de archivos y directorios al importar datos a recursos compartidos de archivos de Azure

Azure Files admite la conservación de las listas de control de acceso de directorios o archivos al copiar datos a recursos compartidos de archivos de Azure. Puede copiar listas de control de acceso de un directorio o archivo en recursos compartidos de archivos de Azure mediante Azure File Sync o conjuntos de herramientas comunes para mover archivos. Por ejemplo, puede usar robocopy con la marca /copy:s para copiar tanto los datos como las listas de control de acceso en un recurso compartido de archivos de Azure. Las listas de control de acceso se conservan de forma predeterminada, no es necesario habilitar la autenticación basada en la identidad en la cuenta de almacenamiento para conservarlas.

Precios

No hay ningún cargo adicional por servicio por habilitar la autenticación basada en la identidad en SMB en la cuenta de almacenamiento. Para obtener más información sobre los precios, consulte Precios de Azure Files y Precios de Microsoft Entra Domain Services.

Pasos siguientes

Para obtener más información sobre Azure Files y la autenticación basada en identidad a través de SMB, consulte estos recursos:

• Introducción: autenticación de Active Directory Domain Services local en SMB para recursos compartidos de archivos de Azure
• Habilitación de la autenticación de Microsoft Entra Domain Services en Azure Files
• Habilitación de la autenticación Kerberos de Microsoft Entra para identidades híbridas en Azure Files
• Habilitar la autenticación Kerberos de AD para clientes Linux
• P+F