This article will show you how to set and configure Windows ACLs (also known as NTFS permissions) on Azure File Shares.
This scenario is useful when you are migrating your data to Azure Files and you want to keep maintaining the full set of basic and advanced Windows ACLs for your file shares.
Table of Contents
Introduction
Azure Files offers shared storage for applications using the standard SMB 3.0 protocol and the Network File System (NFS) protocol. Azure virtual machines and cloud services can share file data across application components via mounted shares, and on-premises applications can access file data in a share via the File storage API. Applications running on Azure virtual machines can also mount a File storage share to access file data, just as a desktop application would mount a typical SMB share. Any number of Azure virtual machines or roles can mount and access the file storage share simultaneously.
One of the confusing questions that customers often ask is, how to configure Windows ACLs (NTFS) permissions if we move our file server(s) to Azure Files.
The answer is very simple, you do exactly what you used to do for traditional file servers by setting up the NTFS permissions on the file share.
However, they are a couple of steps that you need to be aware of, so you can take advantage of the granular access control that Azure Files offers, which we will illustrate in this article.
Prerequisites
To follow this article, you need to have the following:
1) Azure subscription – If you don’t have an Azure subscription, you can create a free one here.
2) Azure Resource Group obviously.
3) Azure storage v2 account – To create a general-purpose v2 storage account, you can follow the instructions described here.
4) You also need to create one Azure file share in your storage account, you can follow the instructions described here.
5) You need to have some folders and files in your Azure file share.
6) You need to join your Azure storage account to your local Active Directory to enable SMB authentication for Azure Files. You can follow the instructions described here to integrate Azure file share with your local AD DS over SMB.
7) Lastly, the Azure PowerShell (Az module) is installed locally on your machine. You can use the following PowerShell command to install and update the “Az module”.
# Make sure you have the latest version of PowerShellGet installed
Install-Module -Name PowerShellGet -Force
# Install and update to the latest Az PowerShell module
Install-Module -Name Az -AllowClobber -ForceAssuming you have all the prerequisites in place, take now the following steps:
Mount Azure file share
First, make sure to log on to a domain-joined virtual machine.
Now before we start configuring Windows ACLs on an Azure file share, you need to mount the share on your domain-joined machine. This step is very important. Because if you tried to access the file share directly as follows:
\\<storage-account-name>.file.core.windows.net\<share-name>If you tried to set the NTFS permissions on any folder/file, you will get random access denied error messages such as (Failed to enumerate objects in the container), sometimes it works but it’s inconsistent.
Option 1
To mount an Azure file share using the storage account keys, you can run the following PowerShell commands. Remember to replace the placeholder values in this example with your own values.
# Mount Azure File Share with storage account access keys
$resourceGroupName = "resource-group-name"
$storageAccountName = "storageaccountname"
$fileShareName = "existing-azfileshare-name"
$connectTestResult = Test-NetConnection -ComputerName $("$storageAccountName.file.core.windows.net") -Port 445
if ($connectTestResult.TcpTestSucceeded) {
Login-AzAccount
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName
$storageAccountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName
$fileShare = Get-AzStorageShare -Context $storageAccount.Context | Where-Object { $_.Name -eq $fileShareName -and $_.IsSnapshot -eq $false }
If ($fileShare -eq $null) { throw [System.Exception]::new("Azure file share not found") }
$password = ConvertTo-SecureString -String $storageAccountKeys[0].Value -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential -ArgumentList "AZURE\$($storageAccount.StorageAccountName)", $password
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\$($fileShare.ShareClient.Uri.Host)\$($fileShare.Name)" -Credential $credential -Persist
}
else {
Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}Personally, I don’t recommend using storage account access keys for security reasons, please check option 2 below.
Option 2
Mounting the Azure file shares with the Active Directory identity of the user is the preferred way. Since the Azure storage account is domain-joined to your on-premises AD, you can leverage this option.
To mount an Azure file share with Active Directory (identity-based), you can run the following PowerShell commands. Remember to replace the placeholder values in this example with your own values.
But before doing so, you want to make sure that the user who’ll mount the share is a member of the Storage File Data SMB Share Elevated Contributor role (please check this article for more details). Only the users who are assigned this Azure AD role will be able to manage Windows ACLs (NTFS) permissions for Azure File Share.
# Mount Azure File Share with Active Directory (identity-based)
$connectTestResult = Test-NetConnection -ComputerName <storage-account-name>.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
# Mount the drive
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-name>.file.core.windows.net\<share-name>" -Persist
} else {
Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}Reset SMB Connections
Please note that if you’ve previously connected directly to the Azure file share and then tried to mount the file share using one of the two options noted above, you will receive the following error message:
System error 1219 has occurred. Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.
To disconnect all previous connections to the Azure file share, you need to run the following commands and then try to mount the file share again:
net use /delete \\<storage-account-name>.file.core.windows.net\<share-name>
net stop workstation /y
net start workstation
Configure Windows ACLs
Once your file share has been mounted with the storage account key as described in the previous step, you can start configuring Windows ACLs (NTFS permissions).
Azure Files supports the full set of basic and advanced Windows ACLs. To can configure the Windows ACLs, you can use either Windows File Explorer, Windows icacls command, or the Set-ACL PowerShell command.
Configure Windows ACLs with Set-ACL
You can use the following Windows PowerShell command to grant full permissions to all directories and files for the current logged-in username under a specific file share in Azure. Remember to replace the placeholder values in this example with your own values:
# Configure Windows ACLs on Azure File Share
$CurTgt = "Z:\Azure Share\Marketing"
$CurUsr = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$acl = Get-Acl $CurTgt
$AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($CurUsr,"FullControl","ContainerInherit,ObjectInherit","None","Allow")
$acl.SetAccessRule($AccessRule)
$acl | Set-Acl $CurTgt
# Remove Windows ACLs on Azure File Share
$CurTgt = "Z:\Azure Share\Marketing"
$CurUsr = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$acl = Get-Acl $CurTgt
$usersid = New-Object System.Security.Principal.Ntaccount ($CurUsr)
$acl.PurgeAccessRules($usersid)
$acl | Set-Acl $CurTgt
For more information on how to use Set-ACL to change and set Windows ACLs and on the different types of supported permissions, please see the official module reference for Microsoft.PowerShell.Security here.
Configure Windows ACLs with icacls
You can use the following Windows command to grant full permissions to all directories and files under the file share, including the root directory. Remember to replace the placeholder values in this example with your own values.
# Mounted drive letter is Z in this example
icacls Z: /grant <user-email>:(f)For more information on how to use icacls to set Windows ACLs and on the different types of supported permissions, please see the official command-line reference for icacls here.
Configure Windows ACLs with Windows File Explorer
You can use Windows File Explorer to grant full permission to all directories and files under the file share, including the root directory.
Please note that if you are not able to load the Active Directory (AD) domain information correctly in Windows File Explorer, this is likely due to trust configuration in your on-premises Active Directory (AD) environment. In this case, the client machine was not able to reach the AD domain controller registered for Azure Files authentication. In this case, you can use Set-ACL or icacls for configuring Windows ACLs as described above.
From the domain-joined machine where you mounted the Azure file share, take the following steps:
1) Open Windows File Explorer and right-click on the file/directory and select Properties.
2) Select the Security tab.
3) Select Edit.. to change the NTFS permissions as shown in the figure below.
4) You can change the permissions of existing users or select Add… to grant permissions to new users. You can also remove the permissions of existing users by selecting Remove.
5) In the prompt window for adding new users, enter the target username or security group you want to grant permissions to in the Enter the object names to select box, and then select Check Names to find the full UPN name of the target user or group.
6) Select OK.
7) In the Security tab, choose and select the permissions you want to grant your new user or security group as shown in the figure below. Always make sure to follow the principle of the least privilege.
8) Finally, select Apply and then click OK.
That’s it there you have it. Happy Azure File Share NTFS Configuration!
Summary
In this article, we showed you how to set and configure Windows ACLs on Azure File Share. This scenario is useful when you are migrating your data to Azure Files and you want to keep maintaining the full set of basic and advanced Windows ACLs for your file shares.
Do you want to learn more about Azure Storage including Azure Blobs and Azure File Shares? Make sure to check my recently published online course here: Azure Storage Essential Training.
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
Hi, one thing I don’t quite get:
Consider my on-premises file server where I have a structure of folders to which I granted permissions to many users and groups. I add all IT Dept users in the AD group and then assigned the “Storage File Data SMB Share Reader” RBAC permissions to the AD group.
Inside one of those folders, I created a new folder called “Private” in which I block inheritance and only grant permissions to 3 x managers users (for example).
Will the users’ members of “Storage File Data SMB Share Reader” RBAC permissions still be able to read inside the “Private” folder?
Am I missing something obvious here?
Hope this makes sense…
Hello Mike, thanks for the comment!
I assume that you are syncing your local AD objects to Azure AD and the storage account is domain-joined, right?
If you blocked the inheritance, then the users which are members of “Storage File Data SMB Share Reader” should not be able to read/access the private folder.
Please make sure the NTFS permissions are assigned correctly.
After you assigned the share-level permissions with RBAC, you must assign proper NTFS permissions at the root, directory, or file level.
Think of share-level permissions as the high-level gatekeeper that determines whether a user can access the share.
Whereas NTFS permissions act at a more granular level to determine what operations the user can do at the directory or file level.
Hope it helps!
Hi! Quick question, say you have multiple VMs that map a drive to access the same file share or shares. If you need to make changes to NTFS permissions by RDPing into one of the VMs and changing it in file explorer will this replicate the same permissions across all VMs that have the shares mapped?
Hello Mike, thanks for the comment!
Yes, your understanding is correct.
If you make changes to NTFS permissions by RDPing into one of the VMs and changing it in file explorer, the same permissions will replicate across all VMs that have the shares mapped.
The target is the same Azure file share(s).
Can I add forest B domain users and assign NTFS permission for a folder that is configured using the forest A Domain?
If yes, please tell the procedure Note: I am able to access file share from forest B users, but not able to add users of forest B in NTFS folder permissions.
Hello Manish, thanks for the comment!
I’m fairly sure that the scenario you described above should work without any issue.
Could you please confirm that you follow the exact steps documented in the official Microsoft Azure Files documentation ==> (Azure Files add multiple forests)?
On-premises AD DS authentication for Azure file shares supports integration with an AD DS environment using multiple forests.
To support authentication/NTFS permissions from another forest, your environment must have a forest trust configured correctly.
Waiting for your feedback?
A couple of questions about a project I’m researching. First, what is the dependency of the AD DS domain on the AAD Tenant?
In my scenario, my customer is hosting a separate AD DS domain in a customer-dedicated subscription. This is not in any way associated with their tenant. This domain trusts the customer’s on-premises domain.
Can I join this AzFileShare to that interim domain?
Second, as far as NTFS permissions go, I am trying to remember what they allow/disallow.
We are trying to prevent ransomware from being able to move laterally from the customer’s environment into Azure, so I am hoping that if I can give them write permissions but not modify that will effectively create a WORM from a customer persona.
Thoughts?
Thanks, Erik
Hello Erik, thanks for the comment!
There is no dependency of the local AD DS domain on the AAD Tenant unless you are synchronizing the local AD DS domain to Azure AD, where you can use the same synched users and groups for Azure file share permissions and NTFS permissions.
In your scenario, you can join this AzFileShare to that interim domain. There is no problem at all.
Second about NTFS permissions, yes you can give them Write permissions without Modify, so they can add new files and update, but they cannot modify or delete files.
If you are using Azure File Sync, you can use the File Server Resource Manager feature on the local share to prevent ransomware.
Hope it helps!
Is it possible to use Azure group as a security for the folder I mounted from Azure blob Storage to Windows? We would like to use Azure Blob as a storage at the same time Azure group as a security, but also the files will be accessible in file explorer just like what you had in your article it is very helpful :) Just wondering about the Azure group security for this folder.
Hello Teb, thanks for your comment!
As of today, Azure Files supports identity-based authentication for Windows file shares over Server Message Block (SMB) using the Kerberos authentication protocol through the following 3 methods only – using only Microsoft Entra ID is not supported yet:
1) On-premises Active Directory Domain Services (AD DS).
2) Microsoft Entra Domain Services (formerly Azure Active Directory Domain Services).
3) Microsoft Entra Kerberos for hybrid user identities. This option doesn’t currently support user accounts that you create and manage solely in Microsoft Entra ID. User accounts must be hybrid user identities, which means you’ll also need AD DS and either Microsoft Entra Connect or Microsoft Entra Connect cloud sync. You must create these accounts in Active Directory and sync them to Microsoft Entra ID. To assign Azure Role-Based Access Control (RBAC) permissions for the Azure file share to a user group, you must create the group in Active Directory and sync it to Microsoft Entra ID.
You can use Microsoft Entra Security Group as a security as long as you are using one of the authentication methods above.
Hope it helps!