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.