Free Consultation

Access Gateway End Point Analysis

Access Gateway End Point Analysis scans are a great feature of Citrix Access Gateway Enterprise. When they work they can provide some extra security to your network and Citrix environment.

Access Gateway End Point Analysis scans query predefined conditions on the client Operating System. Access Gateway then uses the results of the scan to deny access to the logon page, kill processes and delete files on the client; or to apply policies to the user’s XenApp or XenDesktop session such as allowing or denying client drive mapping.

To use End Point Analysis with Smart Access you must have an Access Gateway Universal License. The Access Gateway Universal License is limited on a concurrent user basis. It is also included when you purchase XenDesktop Platinum and XenApp Platinum licenses.

Trust XML Requests
So that the Access Gateway can send its scan results to XenApp or XenDesktop you must enable the Trust XML Requests setting at the farm level.

On XenDesktop you enable this by running this command on each of the XenDesktop controllers

Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true

On XenApp you need to configure this via a policy. The setting is located in:

Computer Configuration –> Policies –> Citrix Policies –>XML Service

Virtual Server Settings
Your Access Gateway virtual server must be in Smart Access mode as per the screenshot below.

Access Gateway End Point Analysis Client
The Access Gateway has to have a method to pull the scan information from the end point device. It does this using the Access Gateway End Point Analysis (EPA) client. When you create an End Point Analysis Scan on the Access Gateway the EPA client will automatically be made available for download from the CAG as per the screenshot below.

The download of the client and running of the scan is optional. If your users decide not to install the client or not run the scan this is considered the same as the result of the scan being negative. This is important to remember if you are going to use Pre-Authentication scans as it’s possible that if the user decides not to run the scan or cannot install the EPA client that they will not be able to log in.

This is what a user will get if they hit Skip Check on the screen above when Pre-Authentication scans are in place

I find a good methodology to use is to think of the minimum access that is acceptable for your users and also fits with your security requirements and make sure that this level of access is achievable without running any EPA scan. If users must always be able to gain access under any circumstance then you should not use Pre-Authentication Scans. If your security requirement is to check something on the end point before showing the logon page and this is more important than all users being able to always log on then Pre-Authentication Scans will work for you.

Pre-Authentication Scans
Pre-Authentication policies are created in Access Gateway –> Policies –> Pre-Authentication and are bound to Virtual Servers.

Every policy has an associated profile, the profile is what is actioned if the outcome of the scan is true.

For Pre-Authentication scans the Profile can Allow or Deny logon (access to the logon page), delete files and folders, and kill processes.

Post-Authentication Scans
Post-Authentication policies are created in Access Gateway –> Policies –> Session and can be bound to Virtual Servers, Groups, and Users.

Every policy also has an associated profile. The profiles for Session Policies can do a number of things.

If you want to use Smart Access (implement XenApp or XenDesktop policies based on the result of EPA scans) then create a null Session Profile and specify your Web Interface or StoreFront settings in the Global Settings.

In your XenApp or XenDesktop policy’s Smart Access Filter Settings you must specify the following details:

Access Gateway Farm = Access Gateway Virtual Server name

Access Gateway Filter = Session Policy Name

When creating the expressions for Endpoint Analysis scans there is some syntax you must follow. I have outlined these below

&&     This is used to combine expressions. Expressions separated by this operator must be evaluated as true for the scan result to be positive

||        This is an OR operator. The scan result will be positive if either expression separated by this operator are evaluated as true.

(‘ ‘)      All values being searched for must be enclosed in brackets apostrophes. E.G Registry paths, application name, executable name, file path.

Four backslashes are used to separate each key in a registry path. The same goes for file paths.
You do not have to enter the expressions manually. In a Policy select either Match Any Expression, Match All Expressions. Click Add, Select Client Security from the Expression Type drop down and then select the component you want to scan for

Scan Examples

Domain membership registry scan

CLIENT.REG(‘HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters_Domain’).VALUE == yourADdomain.local

File scan


Process Scan


Testing Your End Point Scans
When initially creating End Point Analysis scans it can be quite tricky to know if it is working or not or if you got the syntax right.

I find one of the quickest ways to test is to create all scans as Pre-Authentication scans first. It is much quicker and easier to tell if a Pre-Authentication scan is actually working as opposed to doing it with Smart-Access where you have to launch a session and then check if the XenApp or XenDesktop policy has applied.

No support to set client security expression
You may receive this error when trying to make changes to and Pre-Authentication or Session Policies. Not really helpful is it?

To make changes to the policy you need to first unbind it from the object it is bound to (vServer, Group etc).

You can find out where a policy is bound to by right clicking and selecting Show Bindings.

Once you are done making the changes remember to bind it back again.

Invalid Rule

As a last note, you will sometimes get this error when trying to create EPA scan syntax in a policy. Often it just means that your syntax is wrong but sometime it can appear even if everything is correct. In these circumstances I have found I just need to start again or cut out the syntax, save with no syntax, and then paste it back it.