Azure File Share with Azure File Sync - NTFS permissions via AADDS not working

Question

Hi,

We are tiering our on premise file server to an Azure storage account using Azure File Sync. We also have a WvD environment with a few application servers on Azure. We would like to mount the file share with the files synced from our on-premise file server from within WvD (in the same subscription). On-premise with have AD groups linked to NTFS permissions on the file server. These AD groups are synced to AAD DS.

We activated the AD DS authentication option in the storage account, mounting the drive in WvD works just fine with the AAD DS credentials. However all users have access to all folders despite the AD groups having been synced both to AAD DS and also via Azure File Sync to the storage account (we can see our groups from AD listed on the mounted file share in WvD). So for some reason the NTFS permissions are not enforced and we can't figure out why since this is clearly the use case described in this MS document: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-domain-service-enable

Does anyone have experience in applying this use case or solving similar issues with the NTFS permissions?

Thanks.

Kr,

Alexander

Answer 1

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

For better understanding: Can you please explain bit more what kind of permission issue are you facing?

Could you please elaborate on the scenario since I cannot understand the role of the syns service, maybe we are misunderstanding something here. If you are NTFS permission on the servers then the end user computers should be joined to Azure AD domain in order to have access to the file share on the file server.

There is a well explained video, please go through this article.

When using Azure AD for the authentication only 3 NTFS permission types can be granted:

Storage File Data SMB Share Reader allows read access in Azure Storage file shares over SMB.

Storage File Data SMB Share Contributor allows read, write, and delete access in Azure Storage file shares over SMB.

Storage File Data SMB Share Elevated Contributor allows read, write, delete and modify NTFS permissions in Azure Storage file shares over SMB.

https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-enable#2-assign-access-permissions-to-an-identity

Azure File Share level is using RBAC access.While for root,directory and file level uses NTFS. Do you have link on how to setup the NTFS permission? Here how to set up permission at folder level on the file share: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-domain-service-enable#configure-ntfs-permissions-with-windows-file-explorer

Azure File Sync service contains Sync Groups each Sync group has a File Share acting as a cloud endpoint and can contains several servers acting as a Server Endpoints (cache) so in this case the end users should access the file shares on the file servers (server endpoints). Remember that Azure File sync and Azure files are related products but with different goals. If you only have a Azure File Share then end users should map be file share directly as any other file share.

Additional information:

Using Azure File Share: the main goal of Azure Files is to be used as a serverless file server (PaaS) with Azure AD or on-prem AD authentication (preview).

You can user Azure file share with Azure AD authentication to replace a file server, for Azure AD authentication, the file share mounting is supported only on user sessions on a VMs running on Azure and joined to Azure AD domain. For on-prem AD domain authentication (preview) it can be mounted on any on-prem machine joined to the on-prem AD domain.

Using File Sync: The main goal of File Sync is to sync files between servers in different locations or replace a file server and have the file share as a backup (master copy of your files)

You can replace the on-prem file with a Azure VM or keep the on-prem server, either way file server can be joined to Azure AD or on-prem AD domain and will be the server endpoint in the file sync service and file server, at last the file share will be the master copy of your files who could be used as a backup, there is not object on provide access to the file share to end users in this scenari

• AAD DS is a hosted Active Directory instance that is slaved to Azure Active Directory. If you're lifting and shifting an application to the cloud, rather than direct end-user scenarios, because the SIDs of the user objects in AAD DS don't match the SIDs of the user objects in your on-premises AD, where you are presumably managing your user's identities.
• You can use Azure File Sync, either with an on-premises Windows file server or with a Windows file server hosted in an IaaS VM. Windows Server knows how to interact with AD already for Kerberos-based auth, and Azure File Sync preserves AD ACLs. This option sets you up for moving to using the native AD domain join feature I mentioned up front.

Note: We don't support the native AAD authentication scenario for now.

Hope this helps!

Kindly let us know if the above helps or you need further assistance on this issue.

---

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

Answer 2

Hi,

Thank you for the response, indeed the issue was related to having AAD DS joined VM's instead of on premise AD which resulted in the users (SID) not being recognized correctly and thus the NTFS rights not applied. We joined the Azure VM to our on premise AD over VPN and that resolved the issue.

The role of the sync service is actually to push the files on the on premise file server to an Azure storage account using tiering to retain "cold files" only in the online storage account and no longer in the on premise. We wanted to leverage the presence of all our files in an Azure storage account and also make them available to our Azure VM's which is when we stumbled on the NTFS issue.

Kr,

Alexander