Problem with access inheritance between Storage Account and SMB File Shares

Michalaz 20 Reputation points
2024-02-16T15:40:05.5366667+00:00

Hello, I need to grant access to only 1 SMB File share and keep other SMBs inside Storage Account inreachable for specific user, but I have no idea how to do it or is it even possible. I tried granting Contributor access to one SMB, but user wasn't even able to reach it, reader role prevents user from accessing files and few other combinations of roles, but result was always the same, insufficient or too much access. So is it even possible? Or am I doing it wrong? Thanks in advance,
Michał

Azure Files
Azure Files
An Azure service that offers file shares in the cloud.
1,213 questions
Azure Storage Accounts
Azure Storage Accounts
Globally unique resources that provide access to data management services and serve as the parent namespace for the services.
2,871 questions
Access
Access
A family of Microsoft relational database management systems designed for ease of use.
333 questions
0 comments
Accepted answer
  1. Anand Prakash Yadav 7,775 Reputation points Microsoft Vendor
    2024-02-19T10:41:52.96+00:00

    Hello Michalaz,

    Thank you for posting your query here!

    As explained in the official doc, enabling AD DS authentication for your Azure file shares allows you to authenticate to your Azure file shares with your on-prem AD DS credentials. Further, it allows you to better manage your permissions to allow granular access control. Doing this requires synching identities from on-prem AD DS to Azure AD with AD connect. You control the share level access with identities synced to Azure AD while managing file/share level access with on-prem AD DS credentials.

    So, you need to start with part 1 where after enabling the Active Directory Domain Services (AD DS) authentication feature, you must configure your storage account and your AD DS, to use AD DS credentials for authenticating to your Azure file share. To enable AD DS authentication over SMB for Azure file shares, you need to register your storage account with AD DS and then set the required domain properties on the storage account.

    You need to run Join-AzStorageAccount cmdlet which performs the equivalent of an offline domain join on behalf of the specified storage account.

    Refer : https://video2.skills-academy.com/en-us/azure/storage/files/storage-files-identity-ad-ds-enable

    To configure ACLs with superuser permissions, you must mount the share by using your storage account key from your domain-joined VM.

    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.

    Refer : https://video2.skills-academy.com/en-us/azure/storage/files/storage-files-identity-ad-ds-configure-permissions#supported-permissions
    https://video2.skills-academy.com/en-us/azure/storage/files/storage-files-identity-ad-ds-assign-permissions?tabs=azure-portal

    Also, as mentioned here, if you are not able to load the AD domain information correctly in Windows File Explorer, this is likely due to trust configuration in your on-prem AD environment. The client machine was not able to reach the AD domain controller registered for Azure Files authentication. In this case, use icacls for configurating Windows ACLs.

    This is a known issue and is documented in the below troubleshooting doc:
    https://video2.skills-academy.com/en-us/azure/storage/files/storage-troubleshoot-windows-file-connection-problems?tabs=azure-portal#unable-to-configure-directoryfile-level-permissions-windows-acls-with-windows-file-explorer

    The recommended solution is to use icacls tool to configure the directory/file level permissions as a workaround.

    If you wish you may leave your feedback in the below forum requesting a feature. All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.

    https://feedback.azure.com/d365community/forum/a8bb4a47-3525-ec11-b6e6-000d3a4f0f84

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

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

    0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Dillon Silzer 55,086 Reputation points
    2024-02-17T20:09:13.5933333+00:00

    Hi Michalaz,

    From my understanding you are trying to grant access to an Azure File Share:

    NOTE: 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 a Microsoft Entra 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.
    5. Storage File Data SMB Share Reader
    6. Storage File Data SMB Share Contributor
      1. Storage File Data SMB Share Elevated Contributor
    7. Leave Assign access to at the default setting: Microsoft Entra user, group, or service principal. Select the target Microsoft Entra identity by name or email address. The selected Microsoft Entra 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.
    8. Select Save to complete the role assignment operation.

    https://video2.skills-academy.com/en-us/azure/storage/files/storage-files-identity-ad-ds-assign-permissions?tabs=azure-portal

    Note the following roles:

    1. Storage File Data SMB Share Reader
    2. Storage File Data SMB Share Contributor
    3. Storage File Data SMB Share Elevated Contributor

    If this is helpful please accept answer.

    0 comments
  2. Pinaki Ghatak 2,795 Reputation points Microsoft Employee
    2024-02-18T11:07:58.9266667+00:00

    Hello Michalaz Here are the steps you can follow:

    1. Assign Share-Level Permissions: Once you’ve enabled an Active Directory (AD) source for your storage account, you must configure share-level permissions to get access to your file share. You can assign share-level permissions to specific Microsoft Entra 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.
    2. Configure Directory and File-Level Permissions: After assigning share-level permissions, you can configure Windows access control lists (ACLs), also known as NTFS permissions, at the root, directory, or file level. While share-level permissions act as a high-level gatekeeper that determines whether a user can access the share, Windows ACLs operate at a more granular level to control 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’s a difference between either of them, only the most restrictive one will be applied.

    Remember, most users should assign share-level permissions to specific Microsoft Entra 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. Please note that to configure Windows ACLs, you’ll need a client machine running Windows that has unimpeded network connectivity to the domain controller. If you’re authenticating with Azure Files using Active Directory Domain Services (AD DS) or Microsoft Entra Kerberos for hybrid identities, this means you’ll need unimpeded network connectivity to the on-premises AD. I hope this helps!

    If this information provided here helps solve your issue, please tag this as answered, so it helps further community readers, who may have similar questions.

    0 comments