To EPA or not to EPA …
January 10, 2013 1 Comment
For anyone who has not worked with NetScaler Gateway Endpoint Protection Analysis before. It is pre-check before the user get to see the Gateway Logon page it has to comply certain rules that we have programmed the Gateway with. Sometimes I here people say that there is no future for EPA, but I would like to show a use-case which still is actively deployed using NetScaler Gateway and EPA’s.
This feature was already present with the Citrix Access Gateway Advanced using Citrix Advanced Access Control Option Server, yes did it! :-).
What it does is that upon client request it will launch a small piece of Citrix client software to check if the client meets our requirements for connecting. This is triggered by using an ActiveX component within Internet Explorer of Firefox. If the software is not installed it will prompt the user to do so.
Drawbacks. I think a couple of things are good to know beforehand before getting to excited.
- It only works only on Windows and MAC OSX systems;
- It needs NetScaler Gateway Concurrent Licensing. However, less then you might think.
There is basically still just one use-case where we still successfully implement NetScaler Gateway EPA and that is the following. (And you do not need a lot of concurrent licenses to do this).
The Use-case example
Let’s say we have a company called Domain.com. Domain.com has different type of users connecting from the outside from different types of client devices. Consider the following diagram (click to enlarge).
We tell the users to connect to https://secure.domain.com, so this is the default page. (For readability I am disregarding http tot https, etc).
We have configured two Citrix NetScaler Gateway Virtual Servers and they are configured as follows:
- secure.domain.com => SmartBased Access => EPA check => if succeed go to web interface 01 / if not succeed redirect to unsecure.domain.com;
- unsecure.domain.com => Basic => No EPA check => Logon => if succeed go to web interface 02.
This means everyone will have to go through the EPA check, the redirect, however is from user perspective pretty transparent. The way to configure the redirection after a client fails the EPA check can be found here: http://support.citrix.com/article/CTX122503.
The big advantage of this is that we can ‘’tell’’ that clients who have passed the EPA check are trusted. After a successful logon by the NetScaler Gateway the client will go to the Citrix Web Interface 01 on which we manipulate the client name, for instance to WS_<Dynamic-String>. The next step would be to configure the Workspace Composer (RES Workspace Manager, AppSense Environment Manager, Microsoft Group Policy Client Side Preferences, etc) to act upon the Client name received. To show or not show applications based on the client name received.
If the EPA check on secure.domain.com is unsuccessful the user will be redirected to unsecure.domain.com where the logon page will displayed immediately. The user logs on and will be forwarded to Citrix Web interface 02 where also the client name will be manipulated, for instance WU_Dynamic-String>. The next step would be to configure the Workspace Composer (RES Workspace Manager, AppSense Environment Manager, Microsoft Group Policy Client Side Preferences, etc) to act upon the Client name received. To show or not show applications based on the client name received.
The way to manipulate the client name on Citrix Web Interface for Windows can be found here: http://support.citrix.com/article/CTX122975
The things to check on using EPA
It is possible to check against the most simple things you might think of. For instance a self-created registry entry or file somewhere. If all of your client devices are joined to the domain then you can check on domain membership. Or you might create a combination of EPA checks, AND/OR statements are possible.