For two decades, remote access meant deploying a corporate VPN (Virtual Private Network). When a remote user connected to the VPN, their machine was assigned an internal IP address and dumped onto the corporate subnet. If the user’s laptop was compromised by ransomware, the malware could freely traverse the VPN tunnel and infect the entire corporate data center because of this massive, flat network exposure.
The modern architectural mandate is Zero Trust Network Access (ZTNA). ZTNA replaces network-level VPNs with application-level tunnels. Instead of granting access to a subnet, you grant access only to a specific application (like an internal HR portal or an SSH server).
Historically, Microsoft offered Entra ID Application Proxy, which worked brilliantly for web-based (HTTP/HTTPS) applications but was utterly useless for thick clients (like RDP, SSH, SMB, or legacy fat-client ERP software).
Microsoft solved this gap with Entra Private Access. Private Access is Microsoft’s true ZTNA solution. It can tunnel any TCP or UDP port through Entra ID, allowing you to enforce Phishing-Resistant MFA and Conditional Access on legacy, on-premises applications that have no native concept of modern authentication, completely eliminating the need for a corporate VPN.
This guide explains how to architect and deploy Microsoft Entra Private Access.
Understanding the Private Access Architecture
Entra Private Access eliminates inbound firewall rules entirely. It operates on an outbound, reverse-tunnel architecture:
- The Connector: You install lightweight agent software (the Entra Private Network Connector) on a Windows Server located inside your corporate data center.
- The Reverse Tunnel: The Connector reaches outbound to the Entra ID cloud on port 443. It establishes a persistent, cryptographically secure tunnel. You do not need to open any inbound ports on your corporate firewall.
- The Global Secure Access Client: The remote user installs a lightweight VPN-like agent (the GSA Client) on their Windows 11 laptop.
- The Traffic Intercept: When the user attempts to open an RDP session to
server.internalcorp.local, the GSA client intercepts the TCP port 3389 request at the OS level. It wraps the payload, authenticates the user silently via Entra ID, and sends the packet to the cloud. - The Cloud Relay: Entra ID evaluates Conditional Access policies (e.g., Is the device compliant? Did they perform MFA?). If approved, Entra routes the packet down the outbound tunnel to the Connector in the data center, which forwards it to the target server.
Step 1: Deploying the Private Network Connector
You must establish the bridgehead inside your data center.
- Navigate to the Microsoft Entra admin center (entra.microsoft.com).
- Go to Global Secure Access > Connectors.
- Download the connector service executable.
- Install the executable on a Windows Server 2022 machine located in your data center (or AWS/Azure VPC). During installation, you will be prompted to authenticate with an Entra ID Global Administrator or Application Administrator account to register the connector.
- Once installed, verify the connector shows as Active in the Entra portal.
Step 2: Creating the Enterprise Application
You must define the specific legacy application you want to publish through the tunnel.
- In the Entra admin center, navigate to Global Secure Access > Applications > Enterprise applications.
- Click New application.
- Name: Legacy RDP Server.
- Under the Network access properties, you must define the exact traffic you want to intercept. Add the FQDN (
db-server-01.internalcorp.local) or the internal IP address (10.0.5.100). - Specify the ports: TCP 3389. (By specifying only 3389, you ensure the user cannot ping the server or hit any other vulnerable ports, achieving true micro-segmentation).
- Assign the connector group you created in Step 1.
- Click Save.
Step 3: Assigning Users and Conditional Access
Because the legacy RDP application is now registered as a first-class Enterprise Application in Entra ID, you can secure it just like you would secure Salesforce or Office 365.
- Navigate to the Users and groups tab of the newly created application and explicitly assign the specific Active Directory users or groups permitted to access this server.
- Navigate to Protection > Conditional Access.
- Create a new policy targeting the Legacy RDP Server application.
- Configure the Grant controls to require Multifactor authentication and Require device to be marked as compliant.
Step 4: Deploying the Client and Connecting
The final step is the endpoint client.
- Deploy the Global Secure Access Client to your remote workforce laptops via Microsoft Intune.
- The user logs into their Windows 11 machine normally. The GSA client silently authenticates using the Primary Refresh Token (PRT).
- The user opens the standard Windows Remote Desktop Connection (RDP) app and types
db-server-01.internalcorp.local.
The Magic: The legacy RDP client has no idea it is traversing a cloud security perimeter. The GSA client intercepts the traffic, the cloud evaluates the Conditional Access policy, and the connection lands securely on the internal server. If the user’s laptop falls out of compliance (e.g., antivirus is disabled), Entra ID instantly tears down the RDP tunnel, long before the user can even attempt to authenticate to the Windows Server.
Conclusion
Microsoft Entra Private Access finally provides the architectural bridge between modern cloud identity and legacy, on-premises thick clients. By replacing dangerous, subnet-level VPNs with identity-aware, per-application micro-tunnels, enterprise architects can enforce strict Zero Trust compliance on critical infrastructure without modifying a single line of legacy application code.