Compartir vía


Configuración de los permisos de nivel de archivo o directorio para recursos compartidos de archivos de Azure

Se aplica a: ✔️ Recursos compartidos de archivos Azure SMB

Antes de comenzar este artículo, asegúrese de asignar permisos de nivel de recurso compartido a una identidad con el control de acceso basado en rol (RBAC) de Azure.

Después de asignar los permisos de los recursos compartidos, puede configurar listas de control de acceso (ACL) de Windows, también conocidas como permisos NTFS, en las raíces, los directorios o los archivos.

Importante

Para configurar las ACL de Windows para identidades híbridas, necesita una máquina cliente que ejecute Windows que tenga conectividad de red no impedida al controlador de dominio. Si autenticas con Azure Files mediante Active Directory Domain Services (AD DS) o Microsoft Entra Kerberos para identidades híbridas, necesitas conectividad de red sin restricciones al AD local. Si usa Microsoft Entra Domain Services, la máquina cliente debe tener conectividad de red no impedida a los controladores de dominio para el dominio administrado por Microsoft Entra Domain Services, que se encuentran en Azure. En el caso de las identidades solo en la nube (versión preliminar), no hay ninguna dependencia en los controladores de dominio, pero el dispositivo debe estar unido a Microsoft Entra ID.

Funcionamiento conjunto de ACL de Azure RBAC y Windows

Aunque los permisos de nivel de recurso compartido (RBAC) actúan como un guardián de alto nivel que determina si un usuario puede acceder al recurso compartido, las ACL de Windows (permisos NTFS) funcionan en un nivel más granular para controlar qué operaciones puede hacer el usuario en el nivel de directorio o archivo.

Cuando un usuario intenta acceder a un archivo o directorio, se aplican los permisos de nivel de recurso compartido y de nivel de archivo o directorio. Si hay una diferencia entre cualquiera de ellas, solo se aplica la más restrictiva. Por ejemplo, si un usuario tiene acceso de lectura y escritura en el nivel de archivo, pero solo de lectura en un nivel de recurso compartido, solo podrá leer ese archivo. La misma regla se aplica si los permisos se invierten: si un usuario tiene acceso de lectura y escritura en el nivel de compartición de recursos, pero solo acceso de lectura en el nivel de archivo, aún así solo puede leer el archivo.

En la tabla siguiente se muestra cómo funcionan conjuntamente la combinación de permisos de nivel de recurso compartido y ACL de Windows para determinar el acceso a un archivo o directorio en Azure Files.

Ningún rol RBAC RBAC: Lector de recursos compartidos de SMB RBAC: colaborador de recursos compartidos de SMB RBAC: colaborador con privilegios elevados de recurso compartido de SMB
NTFS: ninguno Acceso denegado Acceso denegado Acceso denegado Acceso denegado
NTFS - Lectura Acceso denegado Read Read Read
NTFS - Iniciar y ejecutar Acceso denegado Read Read Read
NTFS: carpeta de lista Acceso denegado Read Read Read
NTFS: escritura Acceso denegado Read Lectura, ejecución, escritura Lectura, escritura
NTFS: modificar Acceso denegado Read Leer, escribir, ejecutar, eliminar Leer, escribir, ejecutar, eliminar, aplicar permisos a sus propios archivos o carpetas
NTFS: completo Acceso denegado Read Leer, escribir, ejecutar, eliminar Leer, escribir, ejecutar, eliminar, aplicar permisos a las carpetas o archivos de cualquier persona

Nota:

La toma de posesión de carpetas o archivos para la configuración de ACL requiere un permiso RBAC adicional. Con el modelo de permisos de Windows para el administrador de SMB, puede otorgar este permiso asignando el rol RBAC integrado Storage File Data SMB Admin, que incluye el takeOwnership permiso.

ACL de Windows admitidas

Azure Files admite el conjunto completo de ACL de Windows básicas y avanzadas.

Usuarios Definición
BUILTIN\Administrators Grupo de seguridad integrado que representa a los administradores del servidor de archivos. Este grupo está vacío y no se puede agregar a nadie.
BUILTIN\Users Grupo de seguridad integrado que representa a los usuarios del servidor de archivos. Incluye NT AUTHORITY\Authenticated Users de manera predeterminada. En el caso de un servidor de archivos tradicional, puede configurar la definición de pertenencia por servidor. Para Azure Files, no hay un servidor de hospedaje, por lo que BUILTIN\Users incluye el mismo conjunto de usuarios que NT AUTHORITY\Authenticated Users.
NT AUTHORITY\SYSTEM La cuenta de servicio del sistema operativo del servidor de archivos. Esta cuenta de servicio no se aplica en el contexto de Azure Files. Se incluye en el directorio raíz para ser coherente con la experiencia de Windows Files Server para escenarios híbridos.
NT AUTHORITY\Authenticated Users Todos los usuarios de AD que pueden obtener un vale de Kerberos válido.
CREATOR OWNER Cada objeto, ya sea directorio o archivo, tiene un propietario para ese objeto. Si hay ACL asignadas a CREATOR OWNER en ese objeto, el usuario que es el propietario de este objeto tiene los permisos para el objeto definido por la ACL.

El directorio raíz de un recurso compartido de archivos incluye los siguientes permisos:

  • BUILTIN\Administrators:(OI)(CI)(F)
  • BUILTIN\Users:(RX)
  • BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
  • NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
  • NT AUTHORITY\SYSTEM:(OI)(CI)(F)
  • NT AUTHORITY\SYSTEM:(F)
  • CREATOR OWNER:(OI)(CI)(IO)(F)

Para obtener más información sobre estos permisos, consulte la referencia de la línea de comandos para icacls.

Montaje del recurso compartido de archivos con acceso de nivel de administrador

Antes de configurar las ACL de Windows, monte el recurso compartido de archivos con acceso de nivel de administrador. Puede adoptar dos enfoques:

  • Use el modelo de permisos de Windows para el administrador de SMB: asigne el rol RBAC integrado Storage File Data SMB Admin, que incluye los permisos necesarios para los usuarios que configuran ACL. A continuación, monte el recurso compartido de archivos mediante la autenticación basada en identidades y configure las ACL. Este enfoque es más seguro porque no requiere la clave de la cuenta de almacenamiento para montar la compartición de archivos.

  • Utilice la clave de la cuenta de almacenamiento (no recomendada): utilice su clave de cuenta de almacenamiento para montar el recurso compartido de archivos y, a continuación, configure las ACL. La clave de la cuenta de almacenamiento es una credencial confidencial. Por motivos de seguridad, use esta opción solo si no puede usar la autenticación basada en identidades.

Nota:

Si un usuario tiene la ACL de Control total y el rol de Colaborador elevado de recursos compartidos de datos de archivos SMB (o un rol personalizado con los permisos necesarios), puede configurar las ACL sin usar el modelo de permisos de Windows para administradores de SMB o la clave de la cuenta de almacenamiento.

Uso del modelo de permisos de Windows para el administrador de SMB

Se recomienda usar el modelo de permisos de Windows para el administrador de SMB en lugar de usar la clave de la cuenta de almacenamiento. Esta característica le permite asignar el rol RBAC integrado Administrador de datos de archivos de almacenamiento SMB a los usuarios, lo que les permite tomar posesión de un archivo o directorio con el fin de configurar ACL.

El rol RBAC de administrador de datos de archivos de almacenamiento SMB incluye las tres acciones de datos siguientes:

  • Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action
  • Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action
  • Microsoft.Storage/storageAccounts/fileServices/takeOwnership/action

Para usar el modelo de permisos de Windows para el administrador de SMB, siga estos pasos:

  1. Asigne la función Storage File Data SMB Admin de RBAC a los usuarios que configuran las ACL. Para obtener instrucciones sobre cómo asignar un rol, consulte Asignación de roles de Azure mediante Azure Portal.

  2. Permita que los usuarios monten el recurso compartido de archivos mediante su identidad de dominio. Siempre que la autenticación basada en identidad esté configurada para la cuenta de almacenamiento, puede montar el recurso compartido y configurar y editar las ACL de Windows sin usar la clave de la cuenta de almacenamiento.

    Inicie sesión en un dispositivo que pertenece a un dominio o en un dispositivo que tenga conexión de red sin restricciones a los controladores de dominio (como usuario de Microsoft Entra si el origen de AD es Microsoft Entra Domain Services). Abra una línea de comandos de Windows y monte el recurso compartido ejecutando el siguiente comando. Reemplace <YourStorageAccountName> y <FileShareName> con sus propios valores. Si Z ya está en uso, reemplácela por una letra de unidad disponible.

    Utilice el comando net use para montar el recurso compartido en esta fase, en lugar de usar PowerShell. Si usa PowerShell para montar el recurso compartido, el recurso compartido no es visible para el Explorador de archivos de Windows o cmd.exe, y tendrá dificultades para configurar las ACL de Windows.

    net use Z: \\<YourStorageAccountName>.file.core.windows.net\<FileShareName>
    

Advertencia

Si es posible, use el modelo de permisos de Windows para el administrador de SMB para montar el recurso compartido en lugar de usar la clave de la cuenta de almacenamiento.

Inicie sesión en un dispositivo que pertenece a un dominio o en un dispositivo que tenga conexión de red sin restricciones a los controladores de dominio (como usuario de Microsoft Entra si el origen de AD es Microsoft Entra Domain Services). Abra una ventana de comandos de Windows y monte el recurso compartido de archivos mediante la ejecución del siguiente comando. Reemplace <YourStorageAccountName>, <FileShareName> y <YourStorageAccountKey> con sus propios valores. Si Z ya está en uso, reemplácela por una letra de unidad disponible. Para encontrar la clave de la cuenta de almacenamiento en Azure Portal, vaya a la cuenta de almacenamiento y seleccione Seguridad y redes>Claves de acceso, o bien puede usar el cmdlet Get-AzStorageAccountKey de PowerShell.

Utilice el comando net use para montar el recurso compartido en esta fase, en lugar de usar PowerShell. Si usa PowerShell para montar el recurso compartido, el recurso compartido no es visible para el Explorador de archivos de Windows o cmd.exe, y tendrá dificultades para configurar las ACL de Windows.

net use Z: \\<YourStorageAccountName>.file.core.windows.net\<FileShareName> /user:localhost\<YourStorageAccountName> <YourStorageAccountKey>

Configuración de ACL de Windows

El proceso de configuración de ACL de Windows es diferente en función de si se autentican identidades híbridas o solo en la nube.

  • En el caso de las identidades solo en la nube (versión preliminar), debe usar Azure Portal o PowerShell. El Explorador de archivos de Windows e icacls no se admiten actualmente para identidades de solo nube.

  • En el caso de las identidades híbridas, puede configurar las ACL de Windows mediante icacls o puede usar el Explorador de archivos de Windows. También puede usar el comando Set-ACL de PowerShell. Si tiene directorios o archivos en servidores de archivos locales con ACL de Windows configuradas en las identidades de AD DS, puede copiarlos en Azure Files a la vez que conserva las ACL mediante herramientas de copia de archivos tradicionales como Robocopy o la versión más reciente de Azure AzCopy. Si escalona directorios y archivos en Azure Files por medio de Azure File Sync, las ACLs se transfieren y conservan en su formato nativo.

Importante

Si usa Microsoft Entra Kerberos para autenticar identidades híbridas, las identidades híbridas deben sincronizarse con el identificador de Entra de Microsoft para que se apliquen las ACL. Puede establecer ACL de nivel de archivo y directorio para identidades que no están sincronizadas con el identificador de Microsoft Entra. Sin embargo, estas ACL no se aplican porque el ticket Kerberos usado para autenticación y autorización no contiene identidades no sincronizadas. Si usa AD DS local como origen de AD, puede incluir identidades no sincronizadas en las ACL. AD DS coloca esos SID en la incidencia de Kerberos y se aplican las ACL.

Configuración de ACL de Windows mediante Azure Portal

Si tiene Microsoft Entra Kerberos configurado como origen de identidad, puede configurar las ACL de Windows por usuario o grupo de Entra mediante Azure Portal. Este método funciona tanto para identidades híbridas como para identidades de solo nube, únicamente cuando Microsoft Entra Kerberos se utiliza como fuente de identidad.

  1. Inicie sesión en Azure Portal con esta dirección URL específica: https://aka.ms/portal/fileperms

  2. Vaya al recurso compartido de archivos para el que desea configurar las ACL de Windows.

  3. En el menú del servicio, seleccione Examinar. Si desea establecer una ACL en la carpeta raíz, seleccione Administrar acceso en el menú superior.

    Captura de pantalla de Azure Portal en la que se muestra cómo administrar el acceso para la carpeta raíz de un recurso compartido de archivos.

  4. Para establecer una ACL para un archivo o directorio, haga clic con el botón derecho en el archivo o directorio y seleccione Administrar acceso.

    Captura de pantalla de Azure Portal en la que se muestra cómo establecer las ACL de Windows para un archivo o directorio.

  5. Ahora debería ver los usuarios y grupos disponibles. Opcionalmente, puede agregar un nuevo usuario o grupo. Seleccione el icono de lápiz situado en el extremo derecho de cualquier usuario o grupo para agregar o editar permisos para que el usuario o grupo acceda al archivo o directorio especificados.

    Captura de pantalla de Azure Portal en la que se muestra una lista de usuarios y grupos de Entra.

  6. Edite los permisos. Denegar siempre tiene prioridad sobre Permitir cuando se establecen ambos. Cuando no se establecen ninguno, se heredan los permisos predeterminados.

    Captura de pantalla de Azure Portal en la que se muestra cómo agregar o editar permisos para un usuario o grupo de Entra.

  7. Seleccione Guardar para establecer la ACL.

Configuración de ACL de Windows para identidades solo en la nube mediante PowerShell

Si necesita asignar ACLs de forma masiva a usuarios solo en la nube, puede usar el módulo RestSetAcls de PowerShell para automatizar el proceso mediante la API REST de Azure Files.

Por ejemplo, si desea establecer una ACL raíz que permita que el usuario testUser@contoso.com solo en la nube tenga acceso de lectura:

$AccountName = "<storage-account-name>" # replace with the storage account name 
$AccountKey = "<storage-account-key>" # replace with the storage account key 
$context = New-AzStorageContext -StorageAccountName $AccountName -StorageAccountKey $AccountKey 
Add-AzFileAce -Context $context -FileShareName test -FilePath "/" -Type Allow -Principal "testUser@contoso.com" -AccessRights Read,Synchronize -InheritanceFlags ObjectInherit,ContainerInherit 

Configuración de ACL de Windows con icacls

Importante

El uso de icacls no funciona para identidades solo en la nube.

Para conceder permisos completos a todos los directorios y archivos del recurso compartido de archivos, incluido el directorio raíz, ejecute el siguiente comando de Windows desde una máquina que tenga conectividad de red no impedida al controlador de dominio de AD. No olvide reemplazar los valores del marcador de posición en el ejemplo por los suyos propios. Si el origen de AD es Microsoft Entra Domain Services, entonces <user-upn> es <user-email>.

icacls <mapped-drive-letter>: /grant <user-upn>:(f)

Para más información sobre cómo usar icacls para establecer ACL de Windows, así como sobre los distintos tipos de permisos admitidos, vea la referencia de línea de comandos de icacls.

Configuración de ACL de Windows con el Explorador de archivos de Windows

Si ha iniciado sesión en un cliente windows unido a un dominio, puede usar el Explorador de archivos de Windows para conceder permiso completo a todos los directorios y archivos del recurso compartido de archivos, incluido el directorio raíz. El uso del Explorador de archivos solo funciona para identidades híbridas; no funciona para identidades solo en la nube.

Importante

El uso del Explorador de archivos de Windows no funciona para identidades solo en la nube. Si el cliente no está unido a un dominio o si el entorno tiene varios bosques de AD, no use el Explorador de Windows para configurar las ACL. En su lugar, use icacls. Esta restricción existe porque la configuración de ACL del Explorador de archivos de Windows requiere que el cliente esté unido al dominio de AD al que está unida la cuenta de almacenamiento.

Siga estos pasos para configurar las ACL mediante el Explorador de archivos de Windows.

  1. Abra el Explorador de archivos de Windows, haga clic con el botón derecho en el archivo o directorio y seleccione Propiedades.
  2. Seleccione la pestaña Seguridad .
  3. Para cambiar los permisos, seleccione Editar.
  4. Cambie los permisos de los usuarios existentes o seleccione Agregar... para conceder permisos a los nuevos usuarios.
  5. En la ventana del símbolo del sistema para agregar nuevos usuarios, escriba el nombre de usuario de destino al que quiera conceder permisos en el cuadro Escriba los nombres de objeto que desea seleccionar y seleccione Comprobar nombres para buscar el nombre UPN completo del usuario de destino. Es posible que tenga que especificar el nombre de dominio y el GUID de dominio para AD local. Esta información la pueden proporcionar un administrador de dominio o de cliente unido a una instancia local de AD.
  6. Seleccione Aceptar.
  7. En la pestaña Seguridad, seleccione todos los permisos que desea conceder al nuevo usuario.
  8. Seleccione Aplicar.

Paso siguiente

Después de configurar los permisos de directorio y de nivel de archivo, puede montar el recurso compartido de archivos SMB en Windows o Linux.