Get started with Global Secure Access – Private Access

Back in the day, when I was working with Citrix based terminal servers and VDIs, providing remote access to on-prem resources was a straight forward task. From a user’s perspective, it was a seamless experience to gain access to these remote resources, often via a locally installed agent/client or a web based login which in most cases support HTML5.

Working with Microsoft Intune and cloud only Windows devices, I have found that the process of gaining access to on-prem resources often involves a VPN solution. Usually, I find that some VPN solutions are not very “cloud friendly” and does not go well with cloud only Windows devices.
One of the issues I have seen for this “cloud unfriendliness”, is that the VPN configuration is created with a domain joined Windows device in mind, this may involve certain endpoint requirements has to be met, i.e. the device must be domain joined and/or on a well-known network to get internet access via the VPN and through the corporate network. While this was a good practice 10-15 years ago, it doesn’t align with cloud only Windows devices and it doesn’t provide a very good user experience either and lastly, it doesn’t fit into the zero-trust paradigm.

Global Secure Access 101

Global Secure Access is a part of Microsoft’s Secure Service Edge (SSE) solution. Microsoft’s SSE consist of different techonologies, where Global Secure Access streamlines management access control capabilities.

Global Secure Access (GSA) has 3 so called traffic profiles. These profiles handles specific network traffic based on workloads.

Microsoft traffic profile

This profile has 4 preconfigured policies configured which can forward traffic to Exchange Online, Teams, Sharepoint Online/OneDrive, Office Online and common Microsoft 365 URLs to go through GSA. It is also possible to bypass GSA, if you don’t want this traffic to go through GSA.

Internet access profile

With this profile you can forward any outgoing request to the internet through GSA and apply content filters to deny access to certain web sites based on either URL, IP or content on the sites.

Private access profile

The Private Access profile provides access to private resources based on FQDN and/or IP. This is what you want to use to provide access to on-prem file servers, web servers, print servers etc. each resource is created as an Enterprise Application or as a Quick App application.

In this blog post, I’ll focus on the Private Access feature as this is what I have experienced companies will buy into when assessing GSA. If you are looking at alternatives to your current traditional (legacy) VPN solution, GSA should be among the products for evaluation.

Global Secure Access licensing

Licensing GSA Private requires that the users already have been assigned a Microsoft Entra ID P1 or P2 license. On top of that, a Microsoft Entra Private Access standalone license or a Microsoft Entra Suite license is required, both are on a per user/per month subscription model.
I recommend that you take a look at the GSA licensing overview on Microsoft Learn or contact your Microsoft licensing partner/advisor for any additional details or information about the GSA license types.

At the time of writing, it is possible to sign up for GSA trial licenses, which is a great opportunity to test GSA Private Access and/or the other GSA features.

Like with any other Microsoft Entra licenses, the trial licenses can be acquired from the Microsoft 365 admin center.

Go the Marketplace and search for Entra Private Access:

Click “details” on the license you want and in the “select a plan” drop down box select a trial license.

You will receive 25 fully functional trial licenses for 30 days.
If you are restricted to a 30 days trial period, remember to disabled to automatic renewal, otherwise the licenses will be converted to paid licenses and automatically renewed.

Global Secure Access configuration

Now that you hopefully have a basic understanding of what Global Secure Access is and how it’s licensed, let’s look at how to configure GSA Private Access.

Most of the configuration is done in the Entra admin center, if you are not yet familiar with the Entra admin center, you will now get the opportunity with the configuration of GSA 🙂

Role Based Access

I always recommend a least privilege access approach in Azure/Intune/Entra. With GSA up to 4 roles area needed depending on what you want to configure.

  • Global Secure Access Administrator role
    • This role allows you to enable, manage and configure core features in GSA.
  • Application Administrator
    • This role allows you to configure, delete or edit Enterprise Applications or Quick App applications.
  • Conditional Access Administrator
    • This role allows you to configure Conditional Access rules for applications configured in GSA Private access.
  • Global Administrator
    • This role is needed to enable the Microsoft 365 integration and the Enriched Microsoft 365 logs management features.

For all the roles above, I recommend that you implement Entra Privileged Identity Management (PIM) to secure and log access to and usage of these roles. I will not cover how to configure Entra PIM as it is out of scope for this article.

Traffic forwarding profiles

To enable Private Access, we need to enable the Private Access traffic forwarding profile.

In the Entra admin center, go to the Global Secure Access node, expand the Connect node and click the traffic forwarding node:

Click the small slider in the Private access profile box, to enable Private Access.

Private network connector

Next, we need to install the Private Network connector.

The Private Network connector provides access to private resources, whether it’s on-prem or in Azure. The Private Network connector initiates a connection to the Global Secure Access backend in Azure on ports 80 and 443, so there is no need for incoming port forwards or firewall rules to the Private Connector Windows Server.

A Windows Server 2012 R2 or later is required however, I strongly recommend installing the Private Network connector on Windows Server 2019 or later, as both Windows Server 2012 R2 and Windows Server 2016 are EOL (End-of-Life). It’s recommended to install the Private Network connector on a domain joined Windows Server with access to all private resources to enable Active Directory domain SSO.

If you are using Windows Server 2019 or later, it’s recommended to disable HTTP2 on the server for Kerberos Constrained Delegation to work. This is a server-side registry change which can be implemented using Powershell:

Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\' -Name EnableDefaultHTTP2 -Value 0

The server must be rebooted after the registry change has been made to disable HTTP2.

The Private network connector installer is found here:

Once the Private network connector has been installed, it should show up as active in the Default connector group. In this case the Default connector group is in the Europe region, currently you can only select regions, not specific countries. If you are in another region, you can create a connector group located in the region in question:

Currently the regions Asia, Australia, Europe and North America is supported.

Keep in mind that it is recommended to have the Private network connector as close to the applications made available via GSA as possible. This means that if you have an on-prem datacenter in Denmark in Europe, you should have at least one connector group i the Europe region to reduce the latency between Private network connector and the on-prem datacenter.

Hopefully in the future it will be possible to select a specific Azure datacenter for the connector group and the Private network connector.

Lastly, I want to mention that it is recommended to have at least 2 Private network connectors per connector group for fail-over and redundancy. However, in a PoC/test scenario you should be able to get by with just 1 Private network connector.

For any additional Private network connector recommendations and requirements, I recommend going through this Microsoft Learn article – How to configure connectors for Microsoft Entra Private Access – Global Secure Access | Microsoft Learn

Applications

Now that we have the Private network connector up and running, we can continue with making resources available via GSA Private Access. In this case, I will show you how to publish a domain controller and a file server in my on-prem lab environment, so that they can be access via GSA Private Access.
If you have multiple domain controllers in your environment, make sure that they are published using either FQDN or IP to avoid any authentication issues. Do not use a wildcard FQDN to publish domain controllers.

In GSA Private Access there are 2 ways of publishing ressources.

There is Quick Access which can have multiple ressources all published to users or groups. This means that you can have both the domain controller and the file server ressource in Quick Access and then grant access to both via Quick Access. This is a good way to get started if you are kicking the tires of GSA Private Access. Also, currently this is the only place you can configure the Private DNS feature. The Private DNS feature is covered later when I show how to publish a domain controller.

Then there are Enterprise applications, where you can configure each ressource as a single application, this is useful if you want to restrict access to ressources based on users or group membership.

You can combine the Quick Access and one or more Enterprise applications it’s not one or the other, you will see that with the Private DNS feature is configured here. But let’s say you want to make sure that users have access to all domain controllers in ýour on-prem datacenter, you can configure all domain controllers in Quick Access and then grant users access to Quick Access as opposed to every domain controller Enterprise Application.

Publish Quick Access resources

To publish Quick Access resources, go to the Applications node and click Quick Access:

Provide a name for the Quick App and select the connector group, in this case I am using the Default connector group, if you have another connector group you should select that instead.

In the Application Segment you can configure the resources you want to publish via GSA Private Access, click the Add Quick Access Application segment:

In this case I am publishing a domain controller. In the Destination type drop down box, select fully qualified domain name. Next, type the FQDN of the domain controller, the ports and the protocol. In this case I have selected ports 88,389,464 and 123 on both TCP and UDP, these are the only ports allowed through GSA Private Access to my domain controller. These ports are the ones Microsoft recommend to enabled Kerberos Single Sign-on.

Keep in mind that domain controllers offer different services that utilize different network ports, if you have need of these services make sure to configure the correct port here as well.

Click Apply and you should now see the domain controller resource with a pending status:

Click save to commit the configuration, you should see the status change to Success:

Next we have to provide access to the domain controller resource, which is the Quick Apps in this case, click Users and Groups :

Click Add user/group and select the users or groups that should have access to Quick Apps. In this case I have selected 2 users.

We have now successfully published a domain controller via the Quick Apps feature.

If you want to use Enterprise Applications instead of Quick Apps, keep in mind that resource network ports should not overlap, which means that if you have configured a domain controller FQDN with the ports 88,389,464 and 123 you shouldn’t have a domain controller Enterprise app with the same ports. It’s OK to use the same FQDN and a different port, e.g. port 3389, if you want to provide access to remote desktop to the domain controller using an Enterprise app.

Configure Private DNS

Going back to the Network access properties, we can configure the Private DNS feature. Private DNS adds support for GSA Private Access to query local DNS servers to resolve IP addresses for internal domain names. This is very useful if you have users that needs to access a file server with DFS shares or an internal web site FQDN. Currently Private DNS can only be configured in Quick Apps.

Click the Private DNS tab:

Click the Enable Private DNS box and click the Add DNS suffix:

Type the DNS suffix og suffixes if you have more than one, in this case my DNS suffix is johansen.local which is the internal name of my Active Directory domain name in my lab setup, click add.

You should now see your DNS suffix in the list:

Click save.

The Private DNS feature is now enabled and will start forwarding queries to internal domain names to your internal DNS servers.

Publish a domain controller Enterprise application

Publishing on-prem resources as an Enterprise application provides a more granular approach in terms is providing access to the application. As you saw before, with Quick Access, the user or group is granted access to all applications in Quick Access, with an Enterprise application the user or group is granted access to that application alone. This means that if you have different Enterprise applications, you can configure different users or groups on each Enterprise application.

Let’s publish a domain controller as an Enterprise application. Go to the Enterprise applications node:

Click New application

Provide an FQDN, ports and protocols and click apply and then save

You should now see a Domain Controller Enterprise app, with the Success status

The only thing left to do is to grant access to the domain controller Enterprise app. Go to the users and groups node:

Click Add user/group and select the users and/or groups you want to grant access to the domain controller Enterprise App.

Publish a file server Enterprise application

To access on-prem file shares, you must publish a file server. Keep in mind to have single sign-on to on-prem file shares from a cloud only device, you will have to logon on to the device using a hybrid identity, which means that the user account must be synchronized from the on-prem Active Directory domain to Entra. If you are using Windows Hello for Business, and you should :), then you will also need Cloud Kerberos Trust to have single sign-on to on-prem file shares.

Create a new Enterprise application:

Provide an FQDN, ports and protocol

You should now see a File Server Enterprise app, with the Success status:

You’ll notice that I have only selected port 445. This is the port SMB v2.x and newer use for network communication. If you have a presumable old application communicating using only SMB v1.0, then you will need ports 137, 138 and 139 TCP as well, I will however, strongly recommend that you stop using SMB v1.0 ASAP.

As with the domain controller Enterprise app, we will also have to grant access to the file server Enterprise app:

You should now have the domain controller and file server Enterprise apps:

Global Secure Access Windows client

Now that we have published both a domain controller and a file server and granted a couple of users access to both, we should be able to access my domain joined on-prem fil server which is currently running in my lab setup. However, we still need to install the Global Secure Access Windows Client.

To get the GSA Windows Client setup file go to the Connect node and then the client download node:

Click Download Client

This should provide you with the latest version of the GSA Windows Client available in the Entra admin center:

However, you will find that the URL http://aka.ms/gsawinlatest has a newer version of the GSA Windows Client:

At the time of writing I have not been able to find the release notes for the GSA Windows Client available via the http://aka.ms/gsawinlatest URL, so I don’t know what has changed between 2.8.45.0 and 2.10.43.0. If you know where to find them, please let me know.

You can find the release notes for version 2.8.45.0 here – Global Secure Access Client for Windows Release Notes – Global Secure Access | Microsoft Learn

I recommend that you deploy the GSA Windows Client using Intune. Microsoft has a guide, explaining how to deploy the GSA Windows Client using Intune. I am working on an article explaining how to use the Powershell AppDeploy Toolkit to deploy the GSA Windows Client including a few tweaks which is not mentioned in Microsoft’s guide.

If you are not familiar with the Powershell AppDeploy Toolkit, I have a couple of articles on how to streamline your application deployment using Powershell App Deploy Toolkit.

The manual install of the GSA Windows Client requires local administrator permission, but it is a very simple setup process, and it does not provide any options:

When the GSA Windows Client has been installed you should see a small globe in the tray area:

The little green check mark indicates that I am currently logged on to the GSA Windows Client and I should be able to access the published applications I have been granted access to.

I have made a small screen recording on an Entra joined cloud only Windows 365 Cloud PC on a Microsoft Hosted Network. This Cloud PC has no connection to my on-prem network and should be considered as a remote device. The only way this Cloud PC can access my on-prem resources, is via Global Secure Access Private Access.

Here you can see that I am accessing my file server using the FQDN, and because I am logged on with a hybrid user, I am not prompted for password.

This concludes the article. Feel free to reach out to me on X or on LinkedIn if you have any comments or questions.