June 7, 2023

Overview

Back in March ’23, IGEL announced native support for NetScaler (formerly Citrix ADC, formerly NetScaler) EPA scans in OS 11.08.290 having commenced bundling the EPA client into the OS (although it had been noted by some folks in earlier private builds as well as 11.08.256).

The customer value is the ability to control access to their environment on IGEL endpoints based on some form of asset ownership check. The perceived risks might at first glance seem trivial for a hardened, locked down, stateless thin client OS, however, this often remains a requirement for many security teams within orgs.

Prior to the inclusion within the IGEL firmware, one had to get by injecting a custom header via the UMS console as some rudimentary indicator.

Right now, the testest method for this new capability to work appears limited to browser authentication only (Firefox or Chromium in IGEL OS), so those hoping for a native Workspace App to do the job might be out of luck for the moment. Although frankly, in these scenarios I would advocate for a kiosk mode locked down to the Citrix Gateway page in the browser anyway and call it a day.

This article is not comprehensive on setup but is intended to provide some tips and tricks to get things going the first time around, with a good user experience.

EPA Policy and Action

Creating the EPA policy and action for IGEL is more or less as simple as any other EPA action, however, with reduced scan check options. You can as we’ve blogged about before, have the EPA policy on the same Policy Label as other OS EPA scans, using user-agent headers presented by the EPA client to determine which policy to match. So, no need (unless there are other technical/security reasons) to spin up a separate Citrix Gateway vServer just for IGEL devices.

As noted in the CitrixReady documentation, the following scans are available:

“With this integration, IGEL UMS administrators accessing Citrix resources will be able to perform EPA checks for file, process, device, and mount point before authentication.”

As of this blog’s release, these are just a handful of rudimentary checks. Certificate checks in speaking with IGEL are not presently tested/supported (and we have not had a chance to do so ourselves just yet) but do hope that such capability will be provided in the future as this is a relatively standard and secure way of proving device ownership (with a certificate distributed via UMS most likely or another auto-enrollment method) with generally high degrees of confidence.

With limited options at this time, we will want to be focused on scans that would allow us to validate that this is a managed device by the org and not a device security posture check (these are hardened stateless thin client OSs anyway).

Below is an example of an EPA policy and action we’ve created, that is checking for the existence of a file in the OS (in this case on a test user desktop) and matching its MD5 hash. To further obfuscate the actions being taken, using UMS to deploy multiple custom files into the thin clients and scanning for those would be ideal, provided users of the device cannot access log files of the thin client that might reveal the file’s creation.

Citrix Gateway Settings

When initially testing, you may find the EPA scan wants to install a new client version, even if the baseline Citrix Gateway vServer setting is set to “Essentials”. You will need to set this to “Never” for Linux plugins to avoid the confusing message.

Note that as you perform NetScaler firmware upgrades, be sure to test EPA clients still function correctly, in event the IGEL firmware also needs an upgrade to restore interoperability between the endpoint and the NetScaler. This scenario of incompatibility should really be a rarity, but always good to validate when doing upgrades.

Suppressing NSGCEPA Launch Prompts

On first testing, users might receive the following annoying prompt. This is not related to trusted sites, moreso security related to protocol handler behaviours affecting the EPA client (NSEPA / NSGCEPA).

We can work around this by adding a Chromium policy setting of “AutoLaunchProtocolsFromOrigins” listing the protocol (which is nsgcepa per the prompt message) and the allowed domains for which to allow this autolaunch and suppress the prompt. Note the policy value syntax carefully. Add this to your device’s profile, and push it out.

Once successfully pushed and applied (which may require a device reboot, took us a few tries to get the setting duly applied), these EPA client launch prompts will vanish.

Credit for this fix goes to Leon Beitsch who has documented quite a bit of Chromium on IGEL. His guide gives a little more practical context (in terms of IGEL) for the vast Chrome Enterprise policy list as well as allowing admins to extrapolate on syntax.

Testing

Go ahead and test the flow on an IGEL client configured with the profile that applies the settings mentioned.

Successful tests should allow the auth sequence to proceed past the EPA prompt, failed tests should present an EPA failure message to users as expected.

For temporary troubleshooting purposes, client-side verbose logging (aka Client Security Logging) can be enabled in NetScaler to gain info client-side on why a scan might be failing. Note this should always be disabled in regular steady-state production operations because this setting will allow a user with access to this file on their endpoint to see exactly what the EPA scan is looking for, allowing for potential exploitation/manipulation. This would never pass a proper third-party security audit if left enabled and exposes security checks that should otherwise be obfuscated.

Here is where that setting can be toggled globally as well as at Citrix Gateway session policy level (good to be mindful of checking both places if you are concerned this has been left enabled).