Additional to the above steps followed, you need to configure NTFS permission over SMB as explained in this article: storage-files-identity-auth-active-directory-domain-service-enable
Azure File Share - NTFS Permissions not working
Hi
I've had a look at the similarly asked questions previously but still can't fix mine.
So I've synced data files from my on premise server to Azure File Share - All Good.
I've connected my AD to Azure AD using AD Connect - All Good
I've set the File Share to authenticate using AD - All Good (followed the instructions on microsoft website)
I have a user which is on AD and is mapped correctly to AzureAD (Directory Synced: Yes). I've added that user to the Storage File Data SMB Share Contributor Group.
Logged on to a domain joined computer with that user. Added a mapped drive and authenticated fine.
Folders and Files show, try and access a restricted folder and I have access. FAIL!
That folder has NTFS permissions set to one group with only two users in. I know it works because I try to access the on premise version and I can't.
It seems the Share Level access is showing me everything which on its own is correct but then NTFS permissions should then stop access at folder/file level which it isn't doing.
Any ideas of what I can do?
Thanks in advance.
Azure Files
Azure Storage
Windows for business Windows Client for IT Pros Directory services Active Directory
Microsoft Security Microsoft Entra Microsoft Entra ID
2 answers
Sort by: Most helpful
-
Manu Philip 20,206 Reputation points MVP Volunteer Moderator
2021-12-09T13:28:53.817+00:00 -
Sumarigo-MSFT 47,466 Reputation points Microsoft Employee Moderator
2021-12-13T16:31:46.207+00:00 @AY Let me explain how Storage File Data SMB Share Contributor : Allows for read, write, and delete access on files and directories in Azure file shares. Learn more.
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 ******@onprem.contoso.com and you have synced to Azure AD as user1@Company portal .com using Azure AD Connect sync. For this user to access Azure Files, you must assign the share-level permissions to user1@Company portal .com. The same concept applies to groups or service principals. Because of this, you must sync the users and groups from your AD to Azure AD using Azure AD Connect sync.
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.
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.
Check this MSDN thread, it's bit old but it explains Cleary how RBAC works
Additional information: As of February 24th, 2020, new and existing ACLs tiered by Azure file sync will be persisted in NTFS format, and ACL modifications made directly to the Azure file share will sync to all servers in the sync group. Any changes on ACLs made to Azure Files will sync down via Azure file sync. When copying data to Azure Files, make sure you use a copy tool that supports the necessary "fidelity" to copy attributes, timestamps and ACLs into an Azure file share - either via SMB or REST. When using Azure copy tools, such as AzCopy, it is important to use the latest version. Check the file copy tools table to get an overview of Azure copy tools to ensure you can copy all of the important metadata of a file.
If you have enabled Azure Backup on your file sync managed file shares, file ACLs can continue to be restored as part of the backup restore workflow. This works either for the entire share or individual files/directories.
If you are using snapshots as part of the self-managed backup solution for file shares managed by file sync, your ACLs may not be restored properly to NTFS ACLs if the snapshots were taken prior to February 24th, 2020. If this occurs, consider contacting Azure Support.
Please let us know if you have any further queries. I’m happy to assist you further.
----------
Please do not forget to
and
wherever the information provided helps you, this can be beneficial to other community members.