Some time ago, I wrote an article about replacing on-premises file shares with Azure file shares. A file share hosted on Azure storage that is available using Entra joined Windows devices.
That solution comes with some limitations. Azure file share uses the SMB protocol. SMB uses firewall port 445 which is blocked by some ISPs. So, you might have people working from home who cannot reach the file shares.
Besides that, the file share is by default reachable from every network location. Even though access to the file share is secured by a Conditional Access policy (for example only access is allowed from a compliant device).
We can work around these two limitations by only allowing access to the Azure storage from a selected virtual network and using Microsoft Entra Private Access.
In this case, the storage account firewall is configured to limit access to the storage account. We configure the firewall to only allow access from a virtual network as described in the Microsoft documentation Networking considerations for Azure Files | Microsoft Learn.
The storage account firewall restricts access to the public endpoint for a storage account. Using the storage account firewall, you can restrict access to certain IP addresses/IP address ranges, to specific virtual networks, or disable the public endpoint entirely.
But this means we must route SMB traffic from our Windows clients, through that ‘allowed’ virtual network to allow access. This is where Entra Private Access comes into play.
Entra Private Access is a Zero Trust Network Access (ZTNA) solution from Microsoft, currently available in public preview.
Copilot describes this solution in short:
Microsoft Entra Private Access is a new identity-centric Zero Trust Network Access (ZTNA) solution that securely connects users to private applications from any device and any network. Built on Zero Trust principles, it removes risk while enhancing user productivity by allowing quick and secure access to private apps—whether they are on-premises or across any cloud.
Private resources are made available via App Proxy Connectors that run on a Windows server on the same network as the resource you want to make available. You can compare it with how Azure Application Proxy uses such a connector to make web applications available. These solutions both make use of the same connector, Microsoft Entra private network connector.
In our situation, this would mean we create an Azure virtual machine (actually two servers) and install the App Proxy Connector on the server. If we configure these servers and storage account in the same virtual network, traffic can be forwarded from the proxy to the storage without allowing access from the public network. And that’s it, in short.
This is what this solution would look like in a scheme.
As Entra Private Access is in preview and under development, I hope that in the future we can just spin up some instances of an App Proxy in an Azure virtual network without the need to create a VM. But running a VM in Azure doesn’t cost that much, as the connector doesn’t take a lot of resources. And maybe you already have some servers running in Azure that you can (miss) use for this.
I assume you have already set up a file share on Azure storage, if not please first read this blog post.
And I assume you already have a virtual network and Windows server running in Azure on which we can install the App Proxy connector. Setting up a virtual network and server in Azure is out of the scope of this post.
Change Azure storage network settings
If you have followed my previous post and set up an Azure file share, the Public network access, found on the Networking tab, is most likely configured to Enabled from all networks.
We need to change Public network access to Disabled.
To make the storage account reachable via the App Proxy connectors, we need to make sure the storage account gets an IP address in the same network as where the servers are located.
To configure this, we assign the storage account its own (private) IP address. This is done by assigning a Private endpoint to the storage account.
On the Private endpoint connections tab choose +Private endpoint.
Create the private endpoint in the same virtual network where the VMs run (on which we will later install the proxy connector).
On the next tab, we need to select the Target sub-resource, that is in our case file.
We need to select a Subnet. And assign a static IP address.
Make sure Integrate with private DNS is set to Yes.
And hit the create button.
We now have a network interface connected to our Azure storage account.
Note down the IP address and both FQDNs, as we need that information later in our Entra Private Access configuration.
Set up Entra Private Access
Entra Private Access is part of Global Secure Access. A license can be purchased as part of the Entra Suite or an add-on license.
Global Secure Access is managed via the Entra portal.
Signed in to the Entra portal, browse to the Global Secure Access section. We first need to enable Global Secure Access for our tenant by selecting Activate.
To provide access from our (Windows) clients to our Azure storage account, we need to have online App Proxy connectors. The client to install the connector can be downloaded from the Connectors tab.
The server on which the connector runs needs to have access to the backend application, in this case, our server needs to have access to our Azure storage. By taking the previous steps, we have already made sure this requirement is in place.
The installation itself is straightforward.
When the installation of the connector is finished, we need to sign in.
This requires authentication with a Global Admin account as described in the documentation.
Soon after the connector is installed and you have finished the configuration, the first connector shows up in the Entra portal in the default connector group.
For redundancy, it is best practice to have at least two connectors per connector group. We can create multiple connector groups. For example, an additional connector group to provide access to on-premises resources.
Open the Traffic forwarding tab and switch on Private access profile to enable traffic forwarding to Global Secure Access.
Click OK to confirm.
Configure Global Secure Access Enterprise application
Now that we have enabled Entra Private Access and connectors are online in the virtual network that allows access to our Azure storage account, it’s time to create a forwarding profile. Such a forwarding profile is a Global Secure Access application, created in Azure. In such a profile we specify which traffic (FQDN or ip address and firewall port) is forwarded via Global Secure access and who is allowed to use this profile/ application.
On the tab Enterprise Applications click +New application.
Enter a name for the new application (1) and click +Add application segment (2).
If you have multiple connector Groups, select the correct group.
We need to add multiple application segments.
We need to add the (private) IP address of the private endpoint of the storage account. And we need to add the firewall port, in this case, 445 (SMB).
We repeat this for the fully qualified domain names of the Azure storage account, both the ‘default’ and private link DNS name.
Next, we add a group with users that is allowed access to the Azure files share and thus allowed to use this forwarding profile.
You can’t choose any other role as the default User role.
As you can see, we can secure this application with a Conditional Access policy.
Configure this to your needs, for example, allow access from compliant devices.
We now have everything set up, to allow access to the Azure file share only from the virtual network using Entra Private access.
End-user experience
I have made the Global Secure Access client available with Microsoft Intune. The client can be downloaded from the Entra portal.
When the Global Secure Access client is installed, a tray icon is shown. As an (local) administrator, you have access to Advanced Diagnostics.
The active forwarding profile details are listed on the Profile forwarding tab. We see a few default rules, and the rules we just added to the new Enterprise application. It shows the destination, protocol, and port.
As this user is allowed to access the Azure file share and use the application, the user can open the Azure file share in Explorer.
If we switch back to the advanced diagnostics (and we start collecting data), we can see the hostname acquisition. We can see the FQDN resolves to an IP address in the 6.6.0.0 range which is the GSA IP range.
On the traffic tab, we can see an active connection to the mentioned FQDN, over the specified SMB port 445. Which shows the data is running through the GSA tunnel as expected.
That’s it for this blog post. We made our Azure file share implementation more secure and available for users whose ISP blocks SMB traffic.
We configured the Azure storage account to only allow access from one virtual network.
In that network, we installed an App Proxy connector and configured Entra Private Access to forward data through this connector.
Thank you for reading!
2 Comments
*sigh* Another Microsoft ‘cloud’ solution that requires Windows Server(s). They just need to implement SMB over QUIC on Azure Files and be done with it.
I like your article! Very easy to understand and follow.