Compartir a través de


Introducción a la autenticación basada en identidades de Azure Files para el acceso con SMB

En este artículo, se explica cómo puede usar la autenticación basada en identidades, ya sea local o en Azure, para habilitar el acceso basado en identidades a recursos compartidos de archivos de Azure a través de SMB. Al igual que en los servidores de archivos de Windows, puede conceder permisos a una identidad en el nivel del recurso compartido, directorio o archivo. No hay ningún cargo adicional por servicio por habilitar la autenticación basada en la identidad en la cuenta de almacenamiento.

Actualmente, no se admite la autenticación basada en identidades con recursos compartidos de archivos de Network File System (NFS). Sin embargo, está disponible a través de SMB para los clientes de Windows y Linux.

Por motivos de seguridad, se recomienda usar la autenticación basada en identidades para acceder a los recursos compartidos de archivos mediante la clave de la cuenta de almacenamiento.

Importante

Nunca comparta las claves de la cuenta de almacenamiento. En su lugar, use la autenticación basada en identidades.

Funcionamiento

Los recursos compartidos de archivos de Azure utilizan el protocolo Kerberos para la autenticación con un origen de identidad. 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 la identidad para autenticarla. Si la autenticación se realiza correctamente, el origen de la identidad devuelve un vale de Kerberos. Luego, el cliente envía una solicitud que incluye el vale de Kerberos y Azure Files lo usa para autorizar la solicitud. El servicio Azure Files solo recibe el vale de Kerberos, no las credenciales de acceso del usuario.

Casos de uso comunes

La autenticación basada en identidades con recursos compartidos de archivos de Azure a través de SMB puede resultar útil en diversos escenarios:

Reemplazo de servidores de archivos locales

Reemplazar los servidores de archivos locales dispersos es un desafío que cada organización enfrenta durante su recorrido de modernización de TI. El uso de la autenticación basada en identidades con Azure Files proporciona una experiencia de migración sin problemas, lo que permite a los usuarios finales seguir accediendo a sus datos con las mismas credenciales.

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

Al migrar aplicaciones a la nube mediante lift-and-shift, es probable que deba mantener el mismo modelo de autenticación para el acceso al recurso compartido de archivos. La autenticación basada en identidades elimina la necesidad de cambiar el servicio de directorio, lo que acelera la adopción de la nube.

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

Si mantendrá el almacenamiento de archivos principal en el entorno local, Azure Files es una solución ideal para la copia de seguridad y la recuperación ante desastres con el objetivo de mejorar la continuidad empresarial. Puede usar recursos compartidos de archivos de Azure para realizar copias de seguridad de los servidores de archivos, 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.

Elección de un origen de identidad para la cuenta de almacenamiento

Antes de habilitar la autenticación basada en identidades en la cuenta de almacenamiento, debe saber qué origen de identidad va a usar. Es probable que ya tenga uno, ya que la mayoría de las empresas y organizaciones tienen algún tipo de entorno de dominio configurado. Consulte a su administrador de Active Directory (AD) o de TI para asegurarse de ello. Si aún no tiene un origen de identidad, deberá configurar uno para poder habilitar la autenticación basada en identidades.

Escenarios de autenticación admitidos

Puede habilitar la autenticación basada en identidades a través de SMB mediante uno de los tres orígenes de identidad: Active Directory Domain Services (AD DS) local, Microsoft Entra Domain Services o Microsoft Entra Kerberos (solo para identidades híbridas). Solo puede usar un origen de identidad por cuenta de almacenamiento para la autenticación de acceso a archivos y se aplica a todos los recursos compartidos de archivos de la cuenta.

  • AD DS local: los clientes de AD DS local y las máquinas virtuales (VM) pueden acceder a recursos compartidos de archivos de Azure con credenciales de Active Directory local. El entorno de AD DS local debe estar sincronizado con Microsoft Entra ID mediante la aplicación local de Microsoft Entra Connect o la sincronización en la nube de Microsoft Entra Connect, un agente ligero que se puede instalar desde el Centro de administración de Microsoft Entra. Para usar este método de autenticación, el cliente debe estar unido a un dominio o tener conectividad de red no impedida a AD DS. Consulte la lista completa de requisitos previos.

  • Kerberos en Microsoft Entra para identidades híbridas: puede usar Microsoft Entra ID para autenticar identidades de usuarios híbridos, lo que permite a los usuarios finales acceder a recursos compartidos de archivos de Azure sin necesidad de conectividad de red a controladores de dominio. Esta opción requiere una implementación de AD DS existente, que luego se sincroniza con el inquilino de Microsoft Entra para que Microsoft Entra ID pueda autenticar las identidades híbridas. Actualmente, no se admiten identidades solo en la nube con este método. Consulte la lista completa de requisitos previos.

  • Microsoft Entra Domain Services: las VM basadas en la nube 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 tradicional de Windows Server AD que es un elemento secundario del inquilino de Microsoft Entra del cliente. Microsoft Entra Domain Services es actualmente la única opción para autenticar identidades solo en la nube. Consulte la lista completa de requisitos previos.

Use las instrucciones siguientes para determinar qué origen de identidad debe elegir.

  • Si su organización ya tiene un AD local, que no está listo para mover identidades a la nube, y si los clientes, las VM y las aplicaciones están unidos a un dominio o tienen conectividad de red no impedida a esos controladores de dominio, elija AD DS.

  • Si algunos o todos los clientes no tienen conectividad de red no impedida al AD DS o si almacena perfiles de FSLogix en recursos compartidos de archivos de Azure para VM unidas a Microsoft Entra, elija Microsoft Entra Kerberos.

  • Si tiene un AD local, pero planea mover aplicaciones a la nube y desea que sus identidades existan tanto en el entorno local como en la nube, elija Microsoft Entra Kerberos.

  • Si no tiene un origen de identidad existente, si necesita autenticar identidades solo en la nube o si ya usa Microsoft Entra Domain Services, elija Microsoft Entra Domain Services. Si aún no tiene un servicio de dominio implementado en Azure, verá un nuevo cargo en la factura de Azure por este servicio.

Habilitación de un origen de identidad

Una vez que haya elegido un origen de identidad, debe habilitarlo en la cuenta de almacenamiento.

AD DS

Para la autenticación de AD DS, debe unir a un dominio las máquinas cliente o las VM. Puede hospedar los controladores de dominio de AD en VM de Azure o en el 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.

Diagrama en el que se describe la autenticación de AD DS local en recursos compartidos de archivos de Azure a través de SMB.

Para 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.

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 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 sin necesidad de tener conectividad de red a los controladores de dominio desde VM 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. No se admite Kerberos en Microsoft Entra en clientes unidos a Microsoft Entra Domain Services o unidos solo a AD.

Diagrama de configuración de la autenticación Kerberos de Microsoft Entra para identidades híbridas a través de SMB.

Para habilitar la autenticación de Kerberos en 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.

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 Vnet que el dominio hospedado 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:

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

  • Todos los usuarios que existen en Microsoft Entra ID se pueden autenticar y autorizar. Los usuarios pueden ser híbridos 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).

Diagrama de configuración de la autenticación de Microsoft Entra Domain Services con Azure Files a través de SMB.

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

Control de autorización y acceso

Independientemente del origen de identidad que elija, una vez que lo habilite, deberá configurar la autorización. Azure Files implementa la autorización en el acceso del usuario tanto a nivel del recurso compartido como a nivel de directorio o archivo.

Puede asignar permisos de nivel de recurso compartido a usuarios o grupos de Microsoft Entra administrados a través de RBAC de Azure. 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, puede asignar roles integrados de Azure, como el de lector de recursos compartidos de SMB de datos de archivos de Storage, 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. 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 permisos de nivel de recurso compartido

Una vez que haya habilitado un origen de identidad 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.

Nota:

No puede asignar 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.

Configuración de permisos de nivel de directorio o archivo

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.

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

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.

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

    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.

Paso siguiente

Para más información, vea: