Azure File Share Permissions without Azure AD

Question

Hello all,

I am trying to setup a secure Azure File Share, not connected to Azure AD, only to AD DS where:

• Specific users have Write/Full Control permissions (admins)
• Specific users have Read access
• Every other domain user is denied access

I have set up and connected the Share successfully, but I have a few doubts:

• From the documentation, I can see I need to use "default share-level permissions". But which should be the default for my scenario? "None, StorageFileDataSmbShareContributor, StorageFileDataSmbShareReader, StorageFileDataSmbShareElevatedContributor".
• The instructions for setting the default share-level permissions seem to set default storage account permissions, not share-level permissions. I can't see any setting specific to existing shares (the share name is never specified). Can this be done?
• Can ACL permissions be set directly on \myaccount.file.core.windows.net\myshare, or do I have to create at least one subdirectory and then set ACLs on that directory?

Thanks for any additional information that you can provide!

Best regards,

Joerg.

Answer 1

@Joerg Aldinger Welcome to Microsoft Q&A Forum, Thank you for posting your query here!

Firstly let me explain Why and How share-level permissions are used: Once either Azure AD DS or on-premises AD DS authentication is enabled, you can use Azure built-in roles or configure custom roles for Azure AD identities and assign access rights to any file shares in your storage accounts. The assigned permission allows the granted identity to get access to the share only, nothing else, not even the root directory. You still need to separately configure directory or file-level permissions for Azure file shares. (You can enable the feature on a new or existing on-premises AD DS environment. Identities used for access must be synced to Azure AD or use a default share-level permission. The Azure AD tenant and the file share that you are accessing must be associated with the same subscription.)

• Configure directory or file-level permissions for Azure Files
  Azure file shares enforce standard Windows file permissions at both the directory and file level, including the root directory. Configuration of directory or file-level permissions is supported over both SMB and REST. Mount the target file share from your VM and configure permissions using Windows File Explorer, Windows icacls, or the Set-ACL command.

Example, user A has rights to go into a storage account and into the file share (that is previously integrated with Active Directory) and add user B as Storage File Data SMB Share Reader. But this same user A can’t go to the IAM of the storage account itself and add user B, or change any properties of the storage account.

Please take a look at “share-level permissions” here: Control access to Azure file shares - on-premises AD DS authentication | Microsoft Learn
You should be able to then use Azure RBAC Scope and have role assignment scope set at the share level so that it is limited to the share related operations.

For Azure Files, ACLs (file security permissions) are only enforced when a user mounts using their domain identity (Kerberos via AD or AADDS). So the documentation link for ACLs only applies to access via these domain identities. In the case of a user mounting using storage account key, this user has “superuser” level of access and ACLs are not used. Accessing using storage account key essentially gives 100% access to all files in the share regardless of the ACL permission of the file or directory.

In Windows computers you can choose to modify the BUILTIN\Users group beyond the default value. The default value for domain-joined computers is to have “NT AUTHORITY\Authenticated Users” as the only member. Azure Files operates using this default value and we do not offer any way for customers to modify it. This means that for Azure Files, the default BUILTIN\Users and NT AUTHORITY\Authenticated Users are the same group. For both groups the members are any user that can successfully mount the share (which is done through successful Kerberos authentication as well as proper share-level permission

• After you assign share-level permissions with Azure RBAC, you must configure proper Windows ACLs at the root, directory, or file level, to take advantage of granular access control. Think of the Azure RBAC share-level permissions as the high-level gatekeeper that determines whether a user can access the share. While the Windows ACLs operate at a more granular level to determine what operations the user can do at the directory or file level. Both share-level and file/directory level permissions are enforced when a user attempts to access a file/directory, so if there is a difference between either of them, only the most restrictive one will be applied. For example, if a user has read/write access at the file-level, but only read at a share-level, then they can only read that file. The same would be true if it was reversed, and a user had read/write access at the share-level, but only read at the file-level, they can still only read the file.
  For more information refer to this article: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-configure-permissions

Please let us know if you have any further queries. I’m happy to assist you further.

----------

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.