Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: ✔️ Recursos compartidos de archivos Azure 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 del protocolo de bloque de mensajes del servidor (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.
La autenticación basada en identidades se admite a través de SMB para clientes Windows, Linux y MacOS. Sin embargo, actualmente no se admite con las particiones NFS (sistema de archivos en red).
Importante
Por motivos de seguridad, se recomienda utilizar la autenticación basada en identidades en lugar de la clave de la cuenta de almacenamiento para acceder a los recursos compartidos de archivos. Nunca comparta las claves de la cuenta de almacenamiento.
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, la fuente de 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 garantizar un cumplimiento adecuado del control de acceso durante el failover.
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 puede usar una única fuente de identidad para la autenticación de acceso a archivos por cuenta de almacenamiento, y se aplica a todas las comparticiones de archivos de la cuenta.
AD DS local: La cuenta de almacenamiento está unida a AD DS local y las identidades de AD DS pueden acceder de forma segura a recursos compartidos de archivos de Azure SMB desde un cliente unido a un dominio o un cliente que tenga conectividad ininterrumpida con el controlador de dominio. 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. Consulte la lista completa de requisitos previos.
Microsoft Entra Kerberos: Puede usar el identificador de Entra de Microsoft para autenticar identidades híbridas o solo en la nube (versión preliminar), lo que permite a los usuarios finales acceder a recursos compartidos de archivos de Azure. Si quiere autenticar identidades híbridas, necesitará una implementación de AD DS existente, que luego se sincroniza con el inquilino de Microsoft Entra. Consulte los 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. Consulte los 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 cualquier cliente no tiene conectividad de red sin restricciones al AD DS o si almacena perfiles de FSLogix en recursos compartidos de archivos de Azure para máquinas virtuales unidas a entornos de Microsoft Entra, elija Microsoft Entra Kerberos.
Si tiene un AD local existente, pero planea mover aplicaciones a la nube y quiere que sus identidades existan tanto en el entorno local como en la nube (híbrido), elija Microsoft Entra Kerberos.
Si desea autenticar identidades solo en la nube sin usar controladores de dominio, elija Microsoft Entra Kerberos. Esta característica actualmente está en su versión preliminar pública.
Si ya usa Microsoft Entra Domain Services, elija Microsoft Entra Domain Services como origen de identidad.
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, puede hospedar los controladores de dominio de AD en máquinas virtuales de Azure o en el entorno local. En cualquier caso, los clientes deben tener conectividad de red sin obstáculos al controlador de dominio, por lo que deben estar dentro de la red corporativa o la red virtual (VNET) del servicio de dominio. Se recomienda unir un dominio a las máquinas cliente o máquinas virtuales para que los usuarios no tengan que proporcionar credenciales explícitas cada vez que accedan al recurso compartido.
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 compartición 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 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
Habilitar y configurar el identificador de Entra de Microsoft para autenticar identidades híbridas o solo en la nube (versión preliminar) permite a los usuarios de Microsoft Entra acceder a los 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 recursos compartidos de archivos de Azure sin necesidad de conectividad de red a controladores de dominio.
Importante
Si desea usar Microsoft Entra Kerberos para autenticar identidades híbridas, se requiere una implementación tradicional de AD DS. Debe sincronizarse con Microsoft Entra ID mediante Microsoft Entra Connect Sync o Microsoft Entra Connect Cloud Sync. Los clientes deben estar vinculados a Microsoft Entra o vinculados a Microsoft Entra híbrido.
En el diagrama siguiente se representa el flujo de trabajo para la autenticación Kerberos de Microsoft Entra para identidades híbridas (es decir, que no son exclusivamente en la nube) por medio de SMB.
Para habilitar la autenticación Kerberos de Microsoft Entra, consulte Habilitación de la autenticación Kerberos de Microsoft Entra 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).
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.