Azure Files - AD permissions not working

Question

question

SenhorDolas-2197 asked Aug 11, '21 SenhorDolas-2197 commented Apr 27, '22

Azure Files - AD permissions not working

Hi
I would like to use my on-prem groups to manage AZ Files share folders permissions. I am hybrid and the groups have replicated up to AAD fine. I this is possible as listed storage-files-identity-ad-ds-assign-permissions

The problem is that the shares created in Azure Files are not honoring the AD DS NTFS permissions.

This is my work flow:

Share created in Azure File (storage account in AD DS)
Granted IAM > Storage File Data SMB Share Reader permissions to a synced AAD group (G-AZF-Share-X which my test account is a member of)
Permissions take a while to replicate to waited 30 mins > logged on to the VM as my test account > able to net use map the share
On my own VM mapped the share with storage account Access Keys and created a few folders > granted full control to AD group G-AZF-Share-X)
Logged on to VM as test user > can see the new folders > can browse thru the folder but unable to create or delete files inside these folders
The NTFS permissions are showing up fine and I can confirm that test user has access to Modify

Created another share:

But this time granted IAM > Storage File Data SMB Share Contirbuter permissions to a synced AAD group (G-AZF-Share-X which my test account is a member of)
Permissions take a while to replicate to waited 30 mins > logged on to the VM as my test account > able to net use map the new share
On my own VM mapped the share with storage account Access Keys and created a few folders > Did not set any NTFS permissions this time
Logged on to VM as test user > can see the new folders > can browse thru the folder but now I am able to create or delete files inside these folders
Check on folders and confirmed that the AD group G-AZF-Share-X has no permissions

The question now is why is the Share Permissions ruling the folder permissions and why I am unable to manage it from NTFS/AD DS?

Many thanks :)

azure-files

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Answer 1 · 2021-08-19T07:31:32.457Z

SumanthMarigowda-MSFT answered Aug 19, '21 deherman-MSFT commented Aug 19, '21

@SenhorDolas-2197 Firstly, apologies for the delay in responding here and any inconvenience this issue may have caused.

AD authentication for Azure Files is a hybrid setup. Permission has to be granted at share level(RBAC) and also NTFS(AD) level, we cannot override and use only NTFS(AD) which is what are you referring?
If you have traditional File Server in that case where you will have full control on the share and all permission goes via on-prem AD.

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://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-configure-permissions

Note: So both are needed and this is by design.

I assume your expectation of using NTFS(AD) only control might come up am I correct? If so I wish you may leave your feedback here All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.

Additional information: You can refer to this thread how RBAC works

If you still find any difficulties, I wish to engage with you offline for a closer look and provide a quick and specialized assistance, please send an email with subject line “Attn:subm” to AzCommunity[at]Microsoft[dot]com referencing this thread and the Azure subscription ID, I will follow-up with you. Once again, apologies for any inconvenience with this issue.

Thanks for your patience and co-operation.

· 2

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SenhorDolas-2197 · Aug 19, 2021 at 03:44 PM

@Sumarigo-MSFT
Please you don't have to apologise, your Team support is fantasting considering the range of software and I am happy with your support.
Regarding my case:
II am effectively trying to replicate my Windows File Server configuration with a share folder with Read to everyone and then manage NTFS permissions on the folders inside.
IBy the looks of it I can't have the same in Azure Files Storage as the share permissions replicate to the folders?
M

0 ·

deherman-MSFT SenhorDolas-2197 · Aug 19, 2021 at 06:18 PM

@SenhorDolas-2197
Yes, if the share levels are set to read only for the user then they will only be able to read, even though they have more permissions at the 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. In your case it seems like you should allow more permissive permissions at the share level then add more restrictive NTFS permissions.

0 ·

Answer 2 · 2021-08-11T19:52:22.503Z

deherman-MSFT answered Aug 11, '21 SenhorDolas-2197 commented Aug 18, '21

@SenhorDolas-2197
I believe this is working as intended. You are setting the share-level permissions to use Storage File Data SMB Share Reader and then assigning full permissions to the group at the file/directory 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. If you wish for your users to have full control you will need to give more permissions at the share level. The table in this section does a good job outlining this.

Hope this helps! Let us know if you have further questions or issues and I will do my best to assist.

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

· 2

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SenhorDolas-2197 · Aug 12, 2021 at 05:25 AM

Hi @deherman-MSFT
I might be missing something here but if the share permissions are controlling access on the folders inside the share then what is the value of setting NTFS permissions on the folders directly?
My idea is to create a share for a service and then create folders inside the share for each office and finally assign permissions to each office folder so that only the selected AD group have access to selected folders.
Is this at all possible?
Thanks M

0 ·

SenhorDolas-2197 · Aug 16, 2021 at 11:57 AM

@deherman-MSFT
@Sumarigo-MSFT
Little help here please...

0 ·

question