Microsoft Entra – Using Private Access to tunnel Citrix HDX Sessions and giving HDX Direct a Try

Reading Time: 8 minutes

Overview

Private Access, a Feature of Microsoft Entra’s Global Secure Access Suite, is a simple but powerful Security Service Edge (SSE) network solution for providing secure access to your Cloud / OnPrem Apps without VPN, just using a lightweight Agent.

This Post contains the following business scenarios:

• Publish an OnPrem CVAD HDX Session to External without the use of a NetScaler or a classic Client-VPN, using Private Access
• Publish OnPrem Webapps like Citrix Director and Citrix StoreFront Web to External, using Private Access
• Publish a DaaS HDX Session to External without the use of Gateway Service or a classic Client-VPN, using Private Access with HDX Direct (Tech preview)

CAUTION! Microsoft Entra Private Access is currently in Preview and there are no informations when this will go GA. At the moment Private Access is available starting with MS Entra ID P1 License.

Configuration

Microsoft Entra admin center

Let’s start activating Global Secure Access in your Tenant via Entra admin center.

Now go on enabling traffic forwarding:

Next Step is to download and install the Application Proxy Connector (yes, that’s the well-known AppProxy for publishing Webapps) in your DataCenter / Resource Location where the VDA’s are located. Make sure the requirements for open ports are matching. I will not go further into details, as it’s a simple installer which requests a Logon to your Entra ID Tenant with a User, minimum member of the Application Administrator role.

After the successful installation, the Connector should be listed as active. A minimum of two Connectors is recommended. If there is the need for different DataCenters or Resource Locations, install 2x Connector per Location and create different Connector Groups.

Next is to create and configure an Enterprise application (which is NOT a typical Enterprise Application which you may know about) where the definition of published resources takes place.

Here you have to define a Name and select a matching Connector Group. In application segment you choose the FQDN / IP-Ranges of your published Resources.

For StoreFront / Director you can use the internal FQDN.

For VDA’s you have to use IP’s / IP-Ranges. The corresponding explanation follows below.

This is my example:

10.10.10.152 is a VDA registered to Citrix DaaS, use 2598 for Session Reliability and you also have to add Port 443 because of HDX Direct, details following.

10.10.10.156 is a VDA registered to CVAD OnPrem, use 2598 for default Session Reliability.

You’re now able to manage the created Enterprise application in the GSA Menu, or via the common Entra ID Enterprise Apps – there is a Global secure access application category created. Make sure to configure your business needs of Conditional Access Policies, assign Usergroups and edit your published Resources in Network access properties.

Endpoint

As a requirement, make sure your Client is Microsoft Entra joined or Microsoft Entra hybrid joined.

Download & Install the latest GSA Client Agent manually (needs local admin permissions) or push it with Intune. The Client starts automatically after installation and asks to sign in with the M365 / Entra ID Account of the User.

Testing

CVAD OnPrem

Here comes the biggest difference between OnPrem StoreFront and Cloud Workspace. By default, a OnPrem StoreFront is adding the connection Address of the VDA into the ICA-File with the IP:

That’s why we configured the IP Address of our VDA’s as the Destination type in GSA.

When opening a session at the Endpoint it looks like this:

Working fine, my Client talks CGP (2598 TCP) directly to my VDA, tunneled through Private Access (443).

Just for reference, not only StoreWeb is working, you can also use the native Workspace App and adding your account with your internal StoreFront FQDN, that’s also tunneled without issues:

DaaS

The Cloud Workspace is adding the connection Address of the VDA into the ICA-File as FQDN, instead of the IP:

And sadly, I was not able to start a session. The Log of GSA Client didn’t list anything related to the FQDN of my VDA. I think that’s because of how the Workspace App reads the ICA-File, as it’s not a direct connection (like typing the StoreFront URL into a Browsertab) the GSA Client will never get known of that and no tunneling takes place.

That’s a great moment to give HDX Direct a Chance! Why? Because it sends IP-Address (instead of FQDN) from the Gateway Service to the Client, where in a second step the GSA Client should recognize the IP and tunneling should work. Let’s get into details.

HDX Direct

First of all, HDX Direct is also in Tech Preview (I thought mixing a MS Tech Preview Feature with a Citrix Tech Preview feature can’t go wrong 😉 ) and it has the following Requirements:

• VDA 2303 or later with TCP 443 inbound allowed (Also UDP when using ICA over EDT)
• Windows Workspace App 2303 or later with TCP 443 access to VDA (what we will achieve via Private Access)

How is HDX Direct working and why we should use it?

“HDX Direct allows client devices to establish a secure direct connection with the VDA if there is a direct line of sight.” In other words, it’s a TLS encrypted ICA Session with Port 443 directly established from the Endpoint to the VDA, without Secure ICA or a NetScaler / Gateway Service in Place.

When HDX Direct is enabled, the Citrix Certificate Manager Service on the VDA checks if a self-signed root CA certificate exists. If not, a self-signed root certificate is created:

As the root CA certificate now is available, next step for the Service is to check if there’s a self-signed machine certificate for the FQDN of the VDA available and if not, generate one:

To successfully establish a secure HDX Direct connection, your Endpoint must trust the certificates used to secure the session.

So now you have to deploy the self-signed root CA to all your Clients, right? Absolutely NOT, the VDA is doing that for you! It sends the Broker its certificate information during the session brokering. This information is now including in the ICA file, so the Workspace App know’s what to do.

Checking an ICA file, this has to be the cert information in an encrypted format:

Configure the following Citrix Policies in DaaS:

So how looks the session launch and why am I doing that regarding the initial case to use Private Access? As I wrote in the Introduction, we will not use Gateway Service. That’s a lie, but only for a few seconds 🙂

There is no better session launch description than on Citrix docs:

Here’s the point why HDX Direct is such interesting for the MS Private Access Use-Case!

We are using Gateway Service to do the initial HDX Connection (so you can’t disable it on DaaS). The VDA sends its IP addresses to the client. The client probes the IP to the VDA via 443 – and because we’ve configured 443 in the Destination Port of Private Access to the VDA, too, the Session will automatically switch from Gateway Service to Private Access – to my positive surprise, that’s all happening during the first 10 seconds of the Session and I don’t even noticed that!

To recap, this could be a real business case.

Gateway Service is enabled and is used by external based BYOD Connections. All other external based corporate Device’s only using Gateway Service for the first seconds, followed by the transfer to the HDX Direct connection, tunneled by MS Private Access. A end to end encrypted HDX Session, tunneled in a private encrypted Microsoft Session. Is there any higher security? 😉

Also, this will massively reduce the bandwidth consumption of Gateway Service.

Performance & Latency

A big question to myself was – how is the performance of the HDX Session compared to OnPrem NetScaler / Gateway Service.

Honestly, I was not surprised that my ICA RTT in average was only 4 ms higher than using a NetScaler / Gateway Service. That’s because of the (currently) eight Points of Presence (PoPs) in Europe. My Session felt very fluid and there were no lags or interrupts.

Logs & Statistics

Microsoft Entra admin center

In Entra admin center you can use Traffic-Monitor to check and filter all used traffic via Private Access. Use filters (in my example a VDA) to see the traffic:

When clicking you get more interesting details:

Clientside

The GSA Client has also some Logs / Checks which you can use.

The Client Checker is making different requirement and connection-checks:

Connection Diagnostics (needs local admin permissions) shows the actual Flows (what is currently tunneled via GSA) and also the transformed Hostnames to the IP-Range of GSA:

When you’re changing Destinations at the Network access properties inside the Enterprise App, it takes some time (or a Restart of the GSA Client) to fetch the latest Policy. The latest timestamp is also shown on the Clientside:

Other Clients than Windows

There is currently an early access for macOS and iOS where you can sign up here. I already did that and just waiting for the confirmation so I can test these clients also and update the post.

For Android there will be a public preview soon, currently I’ve found no options for a private preview or early access.

Summary

Here is my personal recap about the Microsoft Private Access Feature after all these Tests. I’m very excited to see what features Microsoft will add to this already good basic package.

Pro:

• Easy setup and fast deployment, for a PoC, all is setup in hours
• Many different business cases for tunneling traffic via this global MS encrypted SSE network

Con: (I really hope some of the points will come in the future)

• Global Secure Access (including Private Access) is in Preview, there are some serious questions what will happen to when it goes GA:
  • Is there a separate License or will it stay with Entra ID P1?
  • Will there be a consumed bandwidth limit where you can buy GB’s of traffic?
  • How robust is the Service? Considering tunneling thousands of Users with HDX / Web / SMB Traffic through GSA
• No Location Detection Feature / Service. The GSA Client is in autostart and connects always automatically. That said, when the Endpoint is in the Office, all traffic configured for the GSA will go through it, causing higher latency instead of direct internal connection. The User has to manually pause the GSA Client to bypass the tunnel.
• Currently only TCP is supported (For our HDX testing you can’t use EDT atm) UDP is in development