Remote Desktop Gateway (RDG) is a widely deployed Windows Server Role that allows secure remote access to a protected resource (e.g. a Windows Server via Remote Desktop Protocol (RDP)). There were numerous benefits to using RDG with the most apparent being that a Virtual Private Network (VPN) was not required. While enhancements were made to RDG to support Multi-Factor Authentication (MFA), there were functional problems.
Architecturally, support for Entra MFA was accomplished by integrating the RDG Server with a Network Policy Server (NPS) using the AzureMFA Extension. While this ultimately did add MFA support, it used the legacy RADIUS protocol and didn’t support Entra ID Conditional Access (CA) policies.
The solution was also often functionally problematic, and the end user experience was not always great. The most notable example is when multiple requests are made within a short period of time, all but the first were discarded. This is by design for RADIUS implementations as it is a UDP protocol.
Moving forward, a modern solution was required that had a better end user experience and supported the Zero Trust security strategy. A cornerstone of Zero Trust is utilizing CA policies to actively protect access requests. Whether it is to require MFA on compliant devices or restricting source network access or risk-based analysis of each request, CA is a critical requirement for any modern authentication infrastructure.
Migrating To a Modern Solution
Microsoft Entra Private Access (EPA) shines as a Zero Trust Network Access (ZTNA) solution. Using Microsoft Global Secure Access (GSA), a private network resource can be made available, securely, to your end users. Resources can be a single IP or DNS address or an entire subnet that is within your companies’ network.
Using EPA, the most visible change for end users is that access to the published resources is seamless. However, the changes behind the scenes remove legacy dependencies like NPS and RADIUS, allowing modern technologies like CA policies—which can enforce MFA—to be utilized.
Migrating from an RDG deployment to Microsoft EPA can be a complex process depending on your requirements. At its heart though it works as a private VPN tunnel for the resources it is configured to grant access to. This tunnel, when utilized by the end user, also can and should be protected by CA policies.
Configuring Microsoft EPA
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
You must first prepare your tenant to support GSA and EPA. To activate GSA, access the Microsoft Entra admin center and scroll to the Global Secure Access blade. Select the Dashboard page and then the Activate button that is displayed as shown below.
Access to your resources is provided by a Microsoft Entra private network connector. Historically these were called Microsoft Entra application proxy connectors so you may find that you have already built and configured some. Tony La Grassa’s blog post entitled “Securing On-Premises Access Is Easier Than You Think: Utilizing the Entra Application Proxy” discusses this connector in more depth. You can reuse the existing connectors and groups of connectors, but updating them to current versions if they are out of date is highly recommended. Whether you use your existing connector servers or deploy new ones, be sure that they can access the internal resource you plan to publish.
The Connectors page under Connect will allow you to download the service installation package as well as create groups if needed. It is recommended to build at least two connector servers for redundancy.
Now that your tenant is activated and you have connectors built to provide access to the resources you need, you must enable private access. Enabling the use of private access is as simple as enabling the traffic forwarding rule for the private access profile as shown below. If you are unable to enable this profile, check that you have the required Microsoft Entra Private Access license purchased and available for use within your tenant.
Publishing your resources is done by creating a new enterprise application as shown below.
You must provide a name, the Connector Group, that can access the application and the application segment details. Creating the application segment has four required details: A destination type for the application segment which can be an IP address; a fully qualified domain name; IP address range (CIDR); and IP address range (IP to IP). You’ll also need the address details for the selected destination type and the appropriate ports and protocol needed. Once the enterprise application has been created you should open it from the list to alter two settings, the users assigned to get access and the CA policy configuration.
Configuration Review and Deployment
At this point you should have GSA enabled on your tenant, connectors created, the private access profile enabled, and an application created. The application should be assigned to the appropriate users and be protected by CA.
The last step is to deploy the client application and deploy it to your end users’ workstations. Windows workstations must be Entra joined while macOS workstations must be Entra registered and have the Enterprise SSO plug-in installed.
Conclusion
While Microsoft has made the configuration of EPA straightforward, the complexity of migrating your existing resources published through RDG as well as integrating them into your modern zero trust architecture can get complicated. The experts at Ravenswood Technology Group have the expertise to assist with this process.
If you need assistance, we can work with you to review your current RDG solution and zero trust architecture so that your migration to EPA is a successful one. Contact us today for more information!
