Tilbakemeldinger Rediger

Part two: assign share-level permissions to an identity

  • Artikkel
  • 8 minutter å lese

Before you begin this article, make sure you've completed the previous article, Enable AD DS authentication for your account.

Once you've enabled Active Directory Domain Services (AD DS) authentication on your storage account, you must configure share-level permissions in order to get access to your file shares. There are two ways you can assign share-level permissions. You can assign them to specific Azure AD users/user groups and you can assign them to all authenticated identities as a default share level permission.

Important

Full administrative control of a file share, including the ability to take ownership of a file, requires using the storage account key. Administrative control is not supported with Azure AD credentials.

Applies to

File share type SMB NFS
Standard file shares (GPv2), LRS/ZRS Yes No
Standard file shares (GPv2), GRS/GZRS Yes No
Premium file shares (FileStorage), LRS/ZRS Yes No

Which configuration should you use

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 default share-level permissions assigned to all authenticated identities:

  • If you are unable to sync your on-premises AD DS to Azure AD, you can alternatively use a default share-level permission. Assigning a default share-level permission allows you to work around the sync requirement as 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 DS can also leverage the default share-level permission. This could include standalone Managed Service Accounts (sMSA), group Managed Service Accounts (gMSA), and computer service 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 are managing multi-tenant environments. Using the default share-level permission allows you to bypass the requirement for a 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.

Share-level permissions

The following table lists the share-level permissions and how they align with the built-in 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 user1@onprem.contoso.com and you have synced to Azure AD as user1@contoso.com using Azure AD Connect sync. For this user to access Azure Files, you must assign the share-level permissions to user1@contoso.com. The same concept applies to groups or service principals.

Important

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. To mitigate any unintended future impact, we highly recommend declaring actions and data actions explicitly as opposed to using the 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 Azure AD Connect sync
  • Add AD synced groups to RBAC role so they can access your storage account

Share-level permissions must be assigned to the Azure AD identity representing the same user or group in your AD DS 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), are not supported with AD DS authentication.

You can use the Azure portal, Azure PowerShell module, or Azure CLI to assign the built-in roles to the Azure AD identity of a user for granting share-level permissions.

Important

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:

  1. In the Azure portal, go to your file share, or create a file share.
  2. Select Access Control (IAM).
  3. Select Add a role assignment
  4. In the Add role assignment blade, select the appropriate built-in role from the Role list.
    1. Storage File Data SMB Share Reader
    2. Storage File Data SMB Share Contributor
    3. Storage File Data SMB Share Elevated Contributor
  5. 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.
  6. 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 & directories in Azure file share.

You can't currently assign permissions to the storage account with the Azure portal. Use either the Azure PowerShell module or the Azure CLI, instead.

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.

Next steps

Now that you've assigned share-level permissions, you must configure directory and file-level permissions. Continue to the next article.

Part three: configure directory and file-level permissions over SMB