Azure Files SMB Access with Windows AD allows you to access file shares in Azure with NTFS access control. By default, that access won’t extend to an on-prem network over VPN or Express Route. This video shows how to extend access to an Azure Files share with Windows AD to an on-premises network using Private Endpoints.
This video covers creating a Private Endpoint for an Azure Storage File Share, configuring DNS, enabling a Storage Firewall to secure access and test connectivity over a VPN connection to an Azure VNet.
9 thoughts on “Azure Files SMB Access On-premises with Private Endpoints”
Great Video and very heplful.
I deleted my privatedpoint, redeploy a new private endpoint, I keep getting failed deployment error due to conflict. Can you assist?
I have created SMB share as above, but would like to delete it. Can I just delete the storage account object in AD, and delete the file share (storage account) , or do i need to run a powershell command ?
I have created SMB share as above, but would like to delete it. Can I just delete the storage account object in AD, and delete the file share (storage account) , or do i need to run a powershell command ?
Hey Travis,
Couple question, Is there a way for me to set up a file share for external users who is not on my domain, My theory was I would create an account for the users on my AD DS, and they could just map the drive from where ever, this doesn’t seem to be the case, they would apparently need to be able to at the least contact the domain, so my second attempt was to set up a VPN that connected the users to my site so they could resolve the domain.
This has not worked, the third way I would assume to try is to set up a private endpoint and put them on a P2S Azure VPN but how would this work with the users not able to contact the domain?
Would I have to go two-fold and put a site-to-site VPN from my domain network to azure , then let my external users connect via P2S?
Bit stuck here
The user has to be a member of the domain and the solution requires line-of-sight to work correctly. You could try SMB without NTFS Permissions. Azure Storage supports SMB with a shared access key. Here is an article they may help. https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows
Hi, I follow your video and struggled in Azure Files with ADDS Auth SMB share over private link.
I build and destroy the environment 6 times yesterday and finally found a strange behavior of UPN path.
I was unable to get access to the Azure file share til this morning and the way to succession is a little strange.
My scenario is create an ADDS integrated storage account with file share over private link.
I can only establish the connection with the FQDN without privatelink (StorageAccountName.file.core.windows.net).
It complain with my credential if i try to use StorageAccountName.privatelink.file.core.windows.net.
The FQDN with privatelink was registered in my Domain’s DNS like your setting in video.
Please take a look at the image below
https://imgur.com/5z6RVaI
I’m ok with the result if it is the standard way to achieve the goal.
But somehow I don’t think it’s normal.
Wish you would have some time to look into my case and give me some hint what’s going wrong.
I watch your video again and suddenlly found that you establish the mapping drive with the FQDN without “privatelink”…
Seems I got something misunderstanding…
Travis,
Azure File is working properly when my VPN is configured to send all traffic to the corporate office. When I change the VPN to split VPN, the private endpoint is sometimes resolving to the public IP for the storage account. Is there a fix for this?
Great Post mate we have express route terminating into our azure vwan then peered out to vnets followed the video and bang everything worked access to Azure Files using ADDS from on-prem