Assign share-level permissions
Once you've enabled an Active Directory (AD) source for your storage account, you must configure share-level permissions in order to get access to your file share. There are two ways you can assign share-level permissions. You can assign them to specific Azure AD users/groups, and you can assign them to all authenticated identities as a default share-level permission.
Full administrative control of a file share, including the ability to take ownership of a file, requires using the storage account key. Full administrative control isn't supported with identity-based authentication.
|File share type||SMB||NFS|
|Standard file shares (GPv2), LRS/ZRS|
|Standard file shares (GPv2), GRS/GZRS|
|Premium file shares (FileStorage), LRS/ZRS|
Which configuration should you use
Share-level permissions on Azure file shares are configured for Azure Active Directory (Azure AD) users, groups, or service principals, while directory and file-level permissions are enforced using Windows access control lists (ACLs). You must assign share-level permissions to the Azure AD identity representing the same user, group, or service principal in your AD DS in order to support AD DS authentication to your Azure file share. Authentication and authorization against identities that only exist in Azure AD, such as Azure Managed Identities (MSIs), aren't supported.
Most users should assign share-level permissions to specific Azure AD users or groups, and then use Windows ACLs for granular access control at the directory and file level. This is the most stringent and secure configuration.
There are three scenarios where we instead recommend using a default share-level permission to allow contributor, elevated contributor, or reader access to all authenticated identities:
- If you are unable to sync your on-premises AD DS to Azure AD, you can use a default share-level permission. Assigning a default share-level permission allows you to work around the sync requirement because you don't need to specify the permission to identities in Azure AD. Then you can use Windows ACLs for granular permission enforcement on your files and directories.
- Identities that are tied to an AD but aren't synching to Azure AD can also leverage the default share-level permission. This could include standalone Managed Service Accounts (sMSA), group Managed Service Accounts (gMSA), and computer accounts.
- The on-premises AD DS you're using is synched to a different Azure AD than the Azure AD the file share is deployed in.
- This is typical when you're managing multi-tenant environments. Using a default share-level permission allows you to bypass the requirement for an Azure AD hybrid identity. You can still use Windows ACLs on your files and directories for granular permission enforcement.
- You prefer to enforce authentication only using Windows ACLs at the file and directory level.
Because computer accounts don't have an identity in Azure AD, you can't configure Azure role-based access control (RBAC) for them. However, computer accounts can access a file share by using a default share-level permission.
The following table lists the share-level permissions and how they align with the built-in Azure RBAC roles:
|Supported built-in roles||Description|
|Storage File Data SMB Share Reader||Allows for read access to files and directories in Azure file shares. This role is analogous to a file share ACL of read on Windows File servers. Learn more.|
|Storage File Data SMB Share Contributor||Allows for read, write, and delete access on files and directories in Azure file shares. Learn more.|
|Storage File Data SMB Share Elevated Contributor||Allows for read, write, delete, and modify ACLs on files and directories in Azure file shares. This role is analogous to a file share ACL of change on Windows file servers. Learn more.|
Share-level permissions for specific Azure AD users or groups
If you intend to use a specific Azure AD user or group to access Azure file share resources, that identity must be a hybrid identity that exists in both on-premises AD DS and Azure AD. For example, say you have a user in your AD that is firstname.lastname@example.org and you have synced to Azure AD as email@example.com using Azure AD Connect sync or Azure AD Connect cloud sync. For this user to access Azure Files, you must assign the share-level permissions to firstname.lastname@example.org. The same concept applies to groups and service principals.
Assign permissions by explicitly declaring actions and data actions as opposed to using a wildcard (*) character. If a custom role definition for a data action contains a wildcard character, all identities assigned to that role are granted access for all possible data actions. This means that all such identities will also be granted any new data action added to the platform. The additional access and permissions granted through new actions or data actions may be unwanted behavior for customers using wildcard.
In order for share-level permissions to work, you must:
- Sync the users and the groups from your local AD to Azure AD using either the on-premises Azure AD Connect sync application or Azure AD Connect cloud sync, a lightweight agent that can be installed from the Azure Active Directory Admin Center.
- Add AD synced groups to RBAC role so they can access your storage account.
Optional: Customers who want to migrate SMB server share-level permissions to RBAC permissions can use the
Move-OnPremSharePermissionsToAzureFileShare PowerShell cmdlet to migrate directory and file-level permissions from on-premises to Azure. This cmdlet evaluates the groups of a particular on-premises file share, then writes the appropriate users and groups to the Azure file share using the three RBAC roles. You provide the information for the on-premises share and the Azure file share when invoking the cmdlet.
You can use the Azure portal, Azure PowerShell, or Azure CLI to assign the built-in roles to the Azure AD identity of a user for granting share-level permissions.
The share-level permissions will take up to three hours to take effect once completed. Please wait for the permissions to sync before connecting to your file share using your credentials.
To assign an Azure role to an Azure AD identity, using the Azure portal, follow these steps:
- In the Azure portal, go to your file share, or create a file share.
- Select Access Control (IAM).
- Select Add a role assignment
- In the Add role assignment blade, select the appropriate built-in role from the Role list.
- Storage File Data SMB Share Reader
- Storage File Data SMB Share Contributor
- Storage File Data SMB Share Elevated Contributor
- Leave Assign access to at the default setting: Azure AD user, group, or service principal. Select the target Azure AD identity by name or email address. The selected Azure AD identity must be a hybrid identity and cannot be a cloud only identity. This means that the same identity is also represented in AD DS.
- Select Save to complete the role assignment operation.
Share-level permissions for all authenticated identities
You can add a default share-level permission on your storage account, instead of configuring share-level permissions for Azure AD users or groups. A default share-level permission assigned to your storage account applies to all file shares contained in the storage account.
When you set a default share-level permission, all authenticated users and groups will have the same permission. Authenticated users or groups are identified as the identity can be authenticated against the on-premises AD DS the storage account is associated with. The default share-level permission is set to None at initialization, implying that no access is allowed to files or directories in the Azure file share.
To configure default share-level permissions on your storage account using the Azure portal, follow these steps.
In the Azure portal, go to the storage account that contains your file share(s) and select Data storage > File shares.
You must enable an AD source on your storage account before assigning default share-level permissions. If you've already done this, select Active Directory and proceed to the next step. Otherwise, select Active Directory: Not configured, select Set up under the desired AD source, and enable the AD source.
After you've enabled an AD source, Step 2: Set share-level permissions will be available for configuration. Select Enable permissions for all authenticated users and groups.
Select the appropriate role to be enabled as the default share permission from the dropdown list.
What happens if you use both configurations
You could also assign permissions to all authenticated Azure AD users and specific Azure AD users/groups. With this configuration, a specific user or group will have whichever is the higher-level permission from the default share-level permission and RBAC assignment. In other words, say you granted a user the Storage File Data SMB Reader role on the target file share. You also granted the default share-level permission Storage File Data SMB Share Elevated Contributor to all authenticated users. With this configuration, that particular user will have Storage File Data SMB Share Elevated Contributor level of access to the file share. Higher-level permissions always take precedence.
Now that you've assigned share-level permissions, you can configure directory and file-level permissions. Remember that share-level permissions can take up to three hours to take effect.