How to Configure Microsoft Entra ID Global Secure Access (GSA) for Private Application Tunneling

As remote work becomes the standard operating model, traditional Virtual Private Networks (VPNs) are exposing severe architectural flaws. Legacy VPNs provide broad, network-level access; once a user authenticates, they typically gain unrestricted lateral movement across the entire corporate subnet. This violates the core tenet of Zero Trust: least privilege access. Furthermore, backhauling all remote traffic through a centralized VPN concentrator creates massive latency and bandwidth bottlenecks. To solve this, Microsoft introduced Microsoft Entra Private Access (part of the Global Secure Access suite). This solution replaces legacy VPNs with an identity-aware, per-application micro-tunnel, ensuring users only connect to the specific internal servers they are authorized to access, directly integrated with Entra ID Conditional Access.

Understanding the Global Secure Access Architecture

Microsoft Entra Private Access completely removes the need to publish internal applications to the public internet or open inbound firewall ports. It operates utilizing an outbound-only connection model.

You deploy lightweight software agents—called Entra Private Network Connectors—on Windows Server virtual machines residing inside your on-premises data center or AWS/GCP VPC. These connectors establish persistent, outbound TLS 1.2 tunnels to the Microsoft edge network.

On the user’s endpoint (Windows, macOS, iOS, or Android), the Global Secure Access (GSA) Client is installed. When a user attempts to access an internal resource (e.g., typing http://intranet.local or opening an SSH session to 10.0.0.5), the GSA client intercepts the DNS request and the TCP/UDP packets. It forces the user to authenticate against Entra ID, evaluates all Conditional Access policies (checking for MFA, device compliance, and risk score), and only if successful, forwards the packets through Microsoft’s global backbone to your internal connector, which then proxies the traffic to the final server.

Deploying the Private Network Connector

The first step in deployment is establishing the outbound bridge from your data center to Microsoft.

1. Log in to the Microsoft Entra admin center (entra.microsoft.com).
2. Navigate to Global Secure Access > Connectors.
3. Download the connector installer executable.
4. Copy the installer to a Windows Server 2012 R2 (or later) machine residing in your internal network. This server must have outbound internet access on ports 80 and 443 to the Azure datacenter IP ranges. No inbound ports are required.
5. Run the installer. When prompted, authenticate with a Global Administrator or Application Administrator account to mathematically register the connector with your Entra ID tenant.

Once installed, the connector will appear as “Active” in the Entra admin center.

Publishing an Enterprise Application

With the connector active, you can now define the specific internal resources you wish to publish to your remote users.

1. In the Entra admin center, navigate to Global Secure Access > Applications > Enterprise applications.
2. Click New application. Select Microsoft Entra Private Access.
3. Name the application (e.g., “Legacy ERP System”).
4. In the application configuration, define the precise network boundaries for this application. You can specify Fully Qualified Domain Names (FQDNs) like erp.corp.local, specific IP addresses like 192.168.10.50, or entire CIDR subnets (e.g., 10.0.0.0/24), along with the specific TCP/UDP ports required (e.g., TCP 80, 443, 3389).
5. Assign the application to a specific Entra ID User Group. If a user is not in this group, the GSA client on their machine will instantly drop the traffic, making the server completely invisible to them.

Enforcing Conditional Access

The true power of this architecture is its integration with Conditional Access. Because the Private Access tunnel acts as a standard Enterprise Application within Entra ID, you can bind security policies directly to it.

Navigate to Protection > Conditional Access and create a new policy. Target the newly created “Legacy ERP System” application. You can now enforce that any user attempting to access this internal, on-premises server must pass a phishing-resistant FIDO2 security key prompt and be utilizing a corporate-owned, Intune-compliant device. By deploying Global Secure Access, you achieve absolute, granular Zero Trust enforcement for legacy infrastructure without altering the internal applications themselves.