Entra - Private Access for Windows (A first look)
Dear, VPNs - Thank you for everything, but as of today, no thank you!
Introducing Microsoft Entra Private Access, dubbed as the modern alternative to Virtual Private Networks and the replacement solution that we've been holding out for, and it's finally here - At least in Public Preview at the time of writing.
This blog post is the first in a three-part series where we will be taking a first look into the different components of the new Microsoft Global Secure Access (SSE) solution: -
1. Entra Private Access (You're here now)
3. Entra Internet Access for Microsoft 365 (Coming soon)
If you didn't know already, Microsoft's newly announced SSE solution comprises two fundamental components, one being Microsoft Entra Private Access and the other being Microsoft Entra Internet Access, the prior offering a modern cloud-based replacement to VPN connections to provide remote access into internal and on-premises resources, and the latter offering a cloud-centric proxy service for the wider Internet and Microsoft 365. The SSE solution also encompasses Defender for Cloud Apps and bridges that previously treacherous gap between Network Access and Identities by fully integrating with Microsoft Entra and Conditional Access. Additionally, as we've grown to expect with anything Microsoft cloud-oriented, the solution also leverages a single-pane-of-glass and zero-trust approach to securing, validating, and managing Network Access alongside the Identities accessing those encompassing private & public resources.
Entra Private Access tunnels all internally scoped traffic through the SSE solution via the Global Secure Access agent, which in turn must be present across end-user clients. Alternatively, the traffic could also be tunnelled through the remote networks capability which represents on-premises networks that have been directed through the Global Secure Access endpoint. However, the latter alone wouldn't support a remote working scenario of course, due to its dependency on an on-premises network, but it would at least enable Conditional Access controls to be placed in front of the targeted internal resource. It's highly recommended that the Global Secure Access agent is adopted and installed on endpoints where possible.
The technology behind traditional VPNs, which has long enabled workforces to conduct their work activities remotely outside of the Local Area Network and away from physical offices has, in the context of technology, served us a fair and commendable amount of time. However, with the inevitable advent of time, as organisations have started to migrate their applications, data, users, and devices to the cloud, the requirement for such a capability has declined, but the need hasn't subsided completely for everyone - Yes, we're talking about those dreaded printers, that last line-of-business application, or that nest of a file server that nobody dares entertain for migration.
There's no doubt that VPNs have served an invaluable purpose to date, that's for sure. We only need to look at the Work From Home movement during the COVID-19 pandemic to find solid proof of this. With that being said, no matter how well the technology served us previously, we can't be blinded to its flaws. VPNs are usually ambiguous in terms of access, as they are typically deployed in a non-granular fashion due to their limitations, so rather than scoping the connection to a specific service or application only, rather, they provide network-wide access, much as if the end-user was sat in the office on the LAN. Additionally, aside from perhaps enforcing a method of multi-factor authentication for the VPN connection itself, the controls are far less comprehensive, to the point of being incomparable when compared to Conditional Access's offerings.
Speaking of Conditional Access, with the added ability to integrate seamlessly with Entra Private Access, we can significantly secure access to internal and private resources on both an ambiguous and granular scale. If we consider Entra (Azure) App Proxy for a moment, which publishes internal web applications to the cloud, we can target Conditional Access policies to these very published applications. Well, the same concept applies to Entra Private Access, but with extended support for additional resources such as SMB access to File Servers, which we can now place MFA and Compliance requirements in front of, for example.
Finally, if you've ever had the delight of implementing a VPN solution, you'll know that the technology isn't always straightforward depending on the solution and environment you're working within. As you'll see within this blog post, Microsoft Entra Private Access greatly simplifies the work & upkeep required to provide remote access to on-premises and internal resources for end-users, all whilst improving security.
All sounds cutting edge, right?
Let's jump into Microsoft Entra Private Access: -
Prerequisites
Licensing Whilst Entra Private Access is in Public Preview, only Microsoft Entra ID P1 licenses are required. At the time of writing, we are still uncertain about how the licensing model will look once the solution transitions into general availability, so watch this space.
Device
At the time of writing, devices must be running a 64-bit version of Windows 10/11, and must either be Hybrid Entra ID Joined or Fully Entra ID Joined.
Servers destined to host the Private Access Network Connectors must be running Server 2012 R2 at minimum.
Network There are ample URLs that need to be accessible from the servers destined to host the Private Access Network Connectors, on an outbound basis using ports 80 and 443. You can find a list of them here: - How to configure connectors for Microsoft Entra Private Access - Global Secure Access | Microsoft Learn
Other
To take advantage of the Single Sign On capability for internal & on-premises resources (such as an NTFS File Share) from an Entra ID Joined endpoint, the relevant user objects must be in-scope for Entra Connect (Azure AD Connect) synchronization. How SSO to on-premises resources works on Microsoft Entra joined devices - Microsoft Entra ID | Microsoft Learn
Provisioning the Service
The first step within the process oversees the initial enablement of the wider Global Secure Access service within the tenant.
1. Within the Microsoft Entra blade, navigate to Global Secure Access, and then click "Get started". Alternatively, if the service hasn't already been enabled, you can also browse to the "Connect" component and then click "Connectors" within. Once greeted by the "Welcome to Global Secure Access" page, verify you meet the defined prerequisites within Section 1, and then click "Activate" under Section 2.
2. Once the service has been activated, navigate to Global Secure Access again, expand "Connect", and then click "Traffic Forwarding". Within the Traffic forwarding page, enable the "Microsoft 365 access profile" and the "Private access profile".
3. To benefit from full Conditional Access integration with Entra Private Access, as well as integration with Continuous Access Evaluation and Identity Protection, all of which are highly recommended and fundamental components & benefits of the SSE solution, Source IP Restoration will need to be enabled.
Source IP restoration restores the source IP addresses from the original egress IP, which in turn improves security logs such as those in Entra ID sign-in logs, and upholds integration with Conditional Access components such as Named Locations, as well as Identity Protection elements such as location-oriented risks.
To enable Source IP restoration, still within the Entra blade, navigate to Global Secure Access, expand "Global Settings", and then click "Session Management". Once within the Session Management page, select the "Adaptive Access" tab, toggle to "Enable Global Secure Access signalling in Conditional Access", and then click Save.
Deploying a Private Network Connector
Now that the service is provisioned, it's time to deploy our first Private Network Connector. These connectors are essentially lightweight agents that reside on your on-premises Windows servers and provide that much-needed outbound connectivity to the Global Secure Access Service which facilitates & brokers any remote connectivity to internal resources. It's important to understand that the server/s destined to host the agent must have visibility & access to the backend service / server destined for remote access.
If you've ever deployed Entra (Azure) Application Proxy, you'll already be somewhat familiar with this process. The agent is a later and more feature-rich version of the original Application proxy one. If you already have a previous Entra (Azure) Application proxy agent installed, simply reinstall it to get the latest version that supports Entra Private Access (At the time of writing, you'll also need to manually delete any corresponding folders when uninstalling the older version, before installing the later one.)
The service supports the installation of multiple connectors but also works with just one. In a production environment, we do recommend having multiple connectors spread across multiple connector groups. Not only do multiple connectors instil resilience by introducing an element of redundancy if another connector fails, but groups also allow you to handle & segregate traffic between different internal resources, such as applications.
Purely for this blog post and initial Proof-of-Concept walk-through, we'll use the default connector group along with one single connector installation. Please note, however, that this isn't generally recommended for production deployments where multiple connectors and connector groups should be adopted.
1. Within the Microsoft Entra blade, navigate to Global Secure Access, expand "Connect", and then click "Connectors". Within the Private Network connectors page, click "Download connector service" to download the first connector / agent.
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AppProxyOverviewBlade/fromNav/globalSecureAccess
When prompted within the fly-out window pane, digest the provided information and once happy, click "Accept terms & Download".
3. Once the connector setup has been downloaded, run the installer as an administrator, and follow the instructions within the setup wizard to complete the installation.
During the installation process, when prompted, authenticate with a Microsoft 365 account that has the relevant administrator privileges (Global Administrator or Application Administrator)
4. Once the installation process has been completed successfully, verify the presence of the connector within the Private Network connectors page, where we first downloaded the connector setup. Please note that it may take a few minutes for the connector/server to appear.
5. As a side note, if you did want to install additional connectors, you'd simply repeat steps 1 - 4 as many times as required. Additionally, if you'd like to implement connector groups, simply select "New Connector Group" from the menu bar, define a name for the group, specify which connectors should be bound to the group, and then review the available regional settings.
Publishing Applications & Services for Private Access
In this section, we'll be defining, configuring, and publishing the applications & services, being the relevant internal on-premises resource, that we want to provide remote access to for our end-users via Entra Private Access.
In this example, we will create two applications: -
Application 1 (Private Access - File Server) = Will facilitate SMB and RDP access to an internal and on-premises file server.
Application 2 (Private Access - App Server) = Will facilitate HTTP access to an internal and on-premises web application on an application server.
This means that Application 1 will provide access to ports 445 and 3389, whereas Application 2 will provide access to port 80.
Just before we delve any further, it's important to note that there are two options available to publish access to internal resources, one being via the "Quick Access" function and the other being via the "Enterprise applications" function.
The "Quick Access" method is tailored towards hosting a foundational group of FQDNs and/or IP Addresses that you may want to secure and provide access to on an underlying basis, and by foundational we are referring to those baseline resources which you always want to direct through the SSE service in a "blanket" fashion for all users & devices using the same security and access settings. Thinking ahead to the future, Quick Access would likely accommodate items such as Private DNS, which would reflect a "one for all" type policy.
The Enterprise Application method, on the other hand, is tailored towards providing a much more detailed & granular approach to securing, managing, and granting access to internal resources as multiple per-app / private access policies and different sets of Conditional Access policies can be created and then scoped to different subsets of users thereafter.
For this technical demonstration, we will continue with the Enterprise Application method as the technical configuration follows the same concept as the Quick Access configuration at the time of writing but also enables us to be more flexible later in the process, thus offering a fuller illustration of the wider process. Essentially, if you can configure one, you will be able to configure the other.
1. Within the Microsoft Entra blade, navigate to Global Secure Access, expand "Applications", and then click "Enterprise applications". Within the Enterprise applications page, click "New application".
2. Enter a name for the Enterprise Application you are configuring, preferably something that correlates & makes sense with the service or application you are providing access to. In this first example, as we're configuring SMB and RDP access to an on-premises and internal file server, we'll call the application "Private Access - File Server" for ease.
Once a name has been defined, the next step is to choose the connector group for the application. As previously mentioned in the Deploying a Private Network Connector section, for this demonstration and Proof-of-Concept exercise, we are only utilising the default connector group and one single connector, but in a production environment, multiple connectors should be adopted where appropriate along with multiple connector groups to handle and segregate traffic between different internal resources when it makes sense.
Once defined, ensure that "Enable access with Global Secure Access client" is checked, and then click "Add application segment" to start defining the connection configuration.
3. Within the "Create application segment" fly-out pane, define the Destination type, its corresponding value/s, and then finally, the ports that you want to grant access to.
The current options for the destination type field are: -
IP Address = Reflects the internal IP Address of the resource/s, i.e., 10.1.130.20.
Fully Qualified Domain Name = Reflects the internal FQDN of the resource/s, i.e., servername.domain.com
IP Address Range (CIDR) = Reflects the internal IP Address range of the resource/s in CIDR format using a network mask, i.e., 10.1.130.20/28
IP Address Range (IP) = Reflects the internal IP Address range of the resource/s in IP format using a starting IP address and ending IP address, i.e., 10.1.130.20 - 10.1.130.30
In this example, we have opted to use the Fully qualified domain name destination type and have qualified it with our internal File server FQDN: - tst-serv01.threesixtythrive365.com.
Once the destination type and corresponding value/s have been populated, the next step is to define the network ports that you want to facilitate access to within the defined destination. In this example, we're providing access to SMB and RDP, with their retrospective ports being 445 and 3389. For multiple ports, simply separate them using a comma (,).
Once all fields have been configured accordingly, click "Apply" to save the application segment.
4. If required, you can then repeat steps 2-3 to add any additional application segments to this particular enterprise application. Once completed, review and confirm your configuration before clicking "Save".
5. Next, open the newly created Application by navigating back to the "Enterprise applications" page and by clicking the application in question to open it. Further configuration is required within the application to grant & control access for end-users.
6. If you've ever dealt with Enterprise Applications before, such as those directly configured and managed within Entra ID, this will all be very familiar to you already.
Within the "Properties" tab, notable controls around access are: -
Assignment required? = Determines whether the application should require users to be specifically assigned to grant access, or whether all users should have access by default. If set to "Yes" to require user scoping, this is configured within the "Users and groups" tab.
Visible to users? = Determines whether the application should be visible to the in-scope users, i.e., from within the My Apps portal (https://myapps.microsoft.com/). For this use case, there is no real requirement to, or purpose in having the application visible to users.
In this example, we have opted to scope the application to specific users only.
7. As we chose to configure "Assignment required" to "Yes" within the previous step, we now need to specify the users/groups we want to grant access to the Enterprise Application. To do this, simply open the "Users and groups" tab followed by clicking "Add user/group".
As we can see from the below screenshot, we have granted access to one test user.
8. Finally, if any additional applications require publishing & configuring, repeat steps 1-7 as many times as required to meet the organisations' needs. We've repeated these same steps for an internal Application Server that hosts a HTTP (Port 80) web application with the internal IP address of 192.168.130.10.
Deploying the Global Secure Access client
The final step before we can test & prove our Private Access implementation is to deploy the Global Secure Access client to our end-user endpoints.
Much like most clients and applications, the Global Secure Access client is no different in that it can be downloaded and installed manually per device but also deployed centrally via tooling such as Group Policy, Microsoft Endpoint Configuration Manager (MECM), and Intune.
In this example, we are going to use Intune along with the Win32 Application Management & packaging capability to deploy the Global Secure Access client to our test device.
1. First, within the Microsoft Entra blade, source the Global Secure Access client for Windows by navigating to Global Secure Access, expanding "Connect", and then clicking "Client download". Within the Client download page, expand "Windows" and click to download the listed client.
2. Once downloaded, use the Win32 Application Management capability to package the downloaded client executable. If you're unsure of how to use the Win32 Application Management tool, please refer to Microsoft's documentation here: - Prepare a Win32 app to be uploaded to Microsoft Intune | Microsoft Learn
3. Once successfully packaged, upload & add the newly bundled .intunewin file to Intune as a Win32 Application. Again, if you're unsure how to do this, please refer to Microsoft's documentation here: - Add and assign Win32 apps to Microsoft Intune | Microsoft Learn
Within Intune, navigate to the Windows Apps page and click "Add".
4. Within the fly-out pane, select "Windows app (Win32)" as the application type.
5. Next, upload the newly bundled .intunewin file to the application by clicking "Select app package file" and then using the fly-out pane to browse and upload the file in question.
6. Within the "Program" tab, enter the following as your commands: -
Install command = GlobalSecureAccessClient.exe /quiet
Uninstall command = GlobalSecureAccessClient.exe /uninstall /passive /quiet
Additionally, set "Allow available uninstall" to "No".
If you'd like to specify any other supported arguments within either command, please refer to the below: -
7. Within the "Detection rules" tab, specify the following: -
Rules format = Manually configure detection rules
And then add a new rule using the following information: -
Rule type = File
Path = C:\Program Files\Global Secure Access Client
File or folder = GlobalSecureAccessTunnelingService.exe
Detection method = File or folder exists
Associated with a 32-bit app on 64-bit clients = No
8. Finally, populate any other required/optional tabs & fields as per requirements and then assign & deploy the application to the desired users or devices accordingly.
Upon a successful deployment and installation, the end-user will be prompted to authenticate with their M365 Credentials. These credentials should already be populated if the endpoint is either Entra ID or Hybrid Entra ID joined, so the user will just simply need to click the relevant pre-authenticated account. This will only occur upon the initial completion of the installation.
9. Finally, we can further verify a successful install by navigating to the Quick Access tray and verifying that the client is present and running.
Testing Remote Access
Now to prove the concept, the moment of truth! In this demonstration, we have an Entra ID (Azure AD) Joined endpoint, no Hybrid, and no ADDS domain join, and our test user is directory synchronized via Entra (Azure AD) Connect. For peace of mind, however, I also ran a side-by-side test with a Hybrid Entra ID Joined endpoint, and the same results were observed.
1. First, we'll open the "Advanced diagnostics" component of the Global Secure Access client on the end user's machine.
Once opened, we'll navigate to the "Forwarding profile" tab and verify that the relevant rules we previously created are present.
2. The test device is currently connected to the LAN and as we can see below, we get a ping response from our internal file server.
3. We'll now disconnect the device from the LAN and connect it to a completely separate network, replicating a remote access & work scenario. As we can see, the server can no longer be contacted via ping / ICMP.
4. However, with the Global Access Secure client operational and the previously defined configuration present, we can confidently use the Fully Qualified Domain Name of the File Server to access internal File Shares via File Explorer.
As we can see below, the internal & on-premises File Share is remotely accessible, all through the Entra Private Access solution - No VPN's here!
We can also then map a drive on the device using the FQDN of the File Server, which from my testing, proves to automatically connect upon user login.
Looks like our first test was a success!
Just before we move on to the next test, I do just want to clarify one nuance that currently exists at the time of writing, which is that this test device has been logged into using the test user's Microsoft 365 username and password, and not Windows Hello for Business. If the latter is used currently, authentication fails, with a similar experience to that if you don't have Cloud Kerberos Trust implemented. This nuance will hopefully be accounted for in the future and has already been hinted at in a recent Microsoft Mechanics video where they demonstrate Private DNS and Kerberos capabilities.
5. Now, onto the next test, accessing the File Server via a Remote Desktop connection (RDP). Again, as per our previously configured Application segments, we must use the servers FQDN.
Seems promising...
And there we have it, another successful test for Entra Private Access.
6. Now for our last test, which relates to the second Enterprise Application that we defined for the Internal Web Application, mapped via IP Address, rather than FQDN.
Let's open the application...
And just like that, the web application opens successfully - 3 out of 3!
Conditional Access
Let's now look at another key benefit of the Entra Private Access solution, aside from its ability to provide remote access, which is its seamless integration into and support for Conditional Access.
Yes, you read that right, when using Entra Private Access to facilitate remote access to on-premises and internal resources, we can implement Conditional Access to enforce controls around this access, such as Grant Controls like Multi-Factor authentication and ensuring device compliance, as well as Session Controls, such as sign-in frequencies.
In this example, we are going to require that users who are connecting to the on-premises & internal File Server via Entra Private Access must be using a compliant (enrolled) device and must have also satisfied MFA. This can be achieved by scoping the new Conditional Access policy to the Enterprise Application we created earlier, called "Private Access - File Server".
Now, when attempting to access the on-premises File Server remotely via Entra Private Access from a non-compliant device, we are subsequently blocked and greeted with the following message.
As with any other sign-in activity, we can review this failed access attempt within Entra ID's sign-in logs.
Reporting & Logs
There are two locations where we can find reporting & log components for Entra Private Access, one being client-side, and the other being service-side.
Client Logs
Within the "Advanced diagnostics" component of the Global Secure Access client, if we browse to the "Traffic" tab, we gain an overview of all traffic that has recently traversed the Global Secure Access client and solution for this individual endpoint only. From here, we can review the data, collect it, and export it to a CSV.
For example, in the below screenshot, we can see the RDP and HTTP traffic from our previous testing.
Entra Logs
Within the Microsoft Entra blade, navigate to Global Secure Access, expand "Monitor", and then click "Traffic logs". Here, we can gain an overview of all traffic that has traversed the Global Secure Access solution for all connected endpoints. From here, we can review the data and export it to a CSV or JSON file.
The Future
The future is certainly bright for Entra Private Access, we only need to absorb all the above to realise its full potential both now and in the future. However, we must remember that although already impressively comprehensive and functional, at the time of writing, the feature is in Public Preview, with certain features still locked behind a Private Preview. This is only Phase 1 of the solution, meaning there is a lot more to come.
Within one of the recent Microsoft Mechanics videos (Microsoft Entra Private Access protections for on-premises & private cloud network resources (youtube.com)), Microsoft has already stated that the solution now supports Private DNS traffic over Port 53, as well as Kerberos over Port 88 (UDP & TCP). Unfortunately for me, at the time of writing, this is still locked behind a Private Preview and I haven't been fortunate enough to get my hands on it. This new support is particularly exciting & important for Entra ID Joined devices and Windows Hello for Business enabled devices, where a Kerberos ticket needs to be granted to successfully and seamlessly access resources such as NTFS File Shares (Potentially alongside Cloud Kerberos Trust). As of right now, this is not supported, and instead, Entra ID Joined devices and Windows Hello for Business enabled devices must be logged into via the end-user's username and password to gain seamless access.
Additionally, it doesn't look like the Global Secure Access client can auto-update itself, which means "manual" input is required to update the client currently, i.e., through superdense rules and/or a series of manual actions. I'm sure this is something Microsoft will introduce later though.
Another nice benefit would be the ability to silence the initial sign-in / authentication prompt once the client first successfully installs, assuming there is a logged-in user with a PRT Token on a Hybrid-Joined or Fully-Joined Entra ID device.
Finally, what will likely be a make-or-break decision for many organisations is still unknown, and that is the pricing / costing model once the solution transitions out of Public Preview and into General Availability.
All in all though, a fantastic and much-welcomed addition to the Entra family - With super exciting developments still to come.
