So this blog post is based upon my presentation on VirtrualExpo earlier this week. Where I talked about different authentication and access methods in a Citrix enviroment. Which is a pretty broad subject. So my presentation discused different methods so this blog post is going trough some the different ones and talk about features how to configure and how it looks from the client side, as the user-experience! The issue is that depending on the use-case we might need to setup one or multiple access options which are combined with one or multiple security features or authentication options, and also identity sources might be from one or other sources like LDAP, RADIUS, AzureAD, Google Accounts etc, and an important issue is how we can leverege these identity sources in our Citrix enviroment.
In my presentation I talked about the following access methods:
Direct Access
ICA-Proxy
Double-hop
Optimal Gateway Routing (w/Zones and GSLB setup)
Smart Access
Unified Gateway
AlwaysON using NetScaler 11.1
Clientless Access and RFWebUI
Windows 10 Azure AD with ADFS and Federated Authentication Service
Citrix Cloud and NetScaler Gateway Services
Direct Access
So when I’m talking about Direct Access I mean that you want to access a Citrix enviroment within the same domain/forest which is trusted. Which can be as simple as pointing your browser to a local Storefront website, or pointing your Citrix Reciever to the local Storefront site to start remote applications against a Citrix enviroment. A good thing about trying to access a Citrix enviroment within the same domain that your workstation resides is having the ability to get single-sign on. SSO is supported for both Storefront and the VDA agents for XenDesktop 7.0+++ (But you need to have SSO component installed as part of Receiver
In order to setup this feature you need to have copied Group Policy templates from the ICA client installation (Which is usualy under C:\Program Files (x86)\Citrix\ICA Client\Configuration (From there you need the receiver.admx and .adml file and import if to your central repository for group policy \\sysvol\domainname\sysvol\policydefinitions (The Receiver.admx file is placed here) the ADML file is placed under the en-US folder (ADML files are just language files for ADMX policies) These policies can define Passtrough ICA traffic, and we can also define the Store directly in the receiver policies as well so users do not need to type in the server address.
The video below shows how Direct Access using SSO works from an end-user perspective.
ICA-Proxy
Using ICA-Proxy is actually having pretty much the same deployment but instead of connecting to Storefront and having direct traffic to the VDA, the traffic is being proxied via the NetScaler (Which can be either a virtual or physical appliance). So the NetScaler will act as an authentication layer, forward the credentials to Storefront and then authenticate on behalf of the user. Then when a user clicks on an application Storefront will generate a .ICA file where it is specified which address the Citrix receiver client should communicate with, which will in this case be the NetScaler which will handle the ICA traffic between the client and the backend VDA agent.
Now ICA-proxy can be used with a combination of authentication solutions like LDAP, RADIUS, Client Cert, SAML HTTP-Basic but ill come back to those later in the post. 
Since it is the common deployment type for remote users, there are some settings that needs to be in place on the NetScaler. You can read more about setting up NetScaler access here –> http://bit.ly/29lRVUH
Now setting up ICA-proxy requires that the endpoints that are connecting to Citrix should be setup using email based discovery for instance which allows end-users to enter their email address instead of server name (Which they don’t remember anyways) to connect to a NetScaler Gateway. Now it is actually part of the latest Citrix Receiver policy the ability to define NetScaler Gateway address directly but this ofc requires that we have the ability to control the endpoint with group policy.
When setting up ICA-proxy there are some things that you need to be aware of whatshould be defined on the NetScaler to optimize traffic, because the default TCP parameters are pretty old and will not give optimal troughtput and the latency might vary depending on the endpoint and congestion
This video shows setting up email based discovery and accessing using Citrix Reciever and ICA-proxy
Optimal Gateway Routing
Optimal Gateway Routing is actually an StoreFront feature, which can be used in multiple scenarios. For instance it can be used to “force” external and internal users to communicate with their XenDesktop servers using the NetScaler Gateway. So when we configure this feature on Storefront and define all internal and external users to be proxied using the NetScaler, what is going to happen is when a users click on an application or desktop, Storefront will generate an ICA-file where it is stated that traffic should be routed via the NetScaler Gateway. So all authentication is handled by Storefront and not by NetScaler. This allows for other options as well since we can actually present out Storefront as a VIP directly and have multiple stores with HTTP rewrites on NetScaler to have multiple customers on the same URL or multiple URLs on the same IP, and depending on the store the customer has will be pointed to different NetScaler Gateway virtual servers
It can also be used externally in conjunction with GSLB and Storefront Zones to redirect users to their “closest” datacenter. An problem with GSLB is that it might not be the endpoint that is communicating directly with the GSLB vServer but it might be the LDNS server for the endpoints. So when an endpoint is redirected to one of the sites vServer the GSLB Service is going to forward the endpoint to storefront and with an HTTP rewrite rule which is going to contain the client ip address directly. So when the endpoint communicates with Storefront, Storefront looks at the client IP and talks with the resources which is closest to the endpoint and generates an list of applications and desktops available to it and when the users click on an application or desktop, Storefront is going to generate a ICA file containing a optimal gateway routing parameter which points the enduser to the closest datacenter based upon the endpoint IP.
This video shows how the user experince looks like from Optimal Gateway routing for external users, which are connecting directly to Storefront and from there launching sessions
Double-hop
This is a scenario if for instance customers have multiple DMZ zones for instance an internal and an external DMZ zone and you need to enable remote access to your XenDesktop enviroment. In this scenario the first Netscaler will act as an authentication point, after authentication a user will be redirected to Storefront like in a normal ICA-proxy configuration. When a user clicks on an application it will generate an ICA file which points to the first NetScaler. When the Receiver client is establishing a connection it will connect to the first NetScaler Gateway, which will in turn connect to another NetScaler Gateway virtual server which is located on the internal DMZ which will in turn talk with the VDA agents on the Inside.
HTML 5 based Access
HTML 5 based access is not a new feature, it allows for anyone having a HTML5 capable browser which means having websockets and JS script support to establish a connection directly to an application or desktop without having Citrix Receiver installed. This is useful if you do not have receiver installed or do not have admin rights to install it on the endpoint or have an endpoint which does not support receiver. Having HTML5 access exteranlly is also not a new thing, NetScaler has supported WebSockets for quite some time you just need to enable it in the HTTP profile and bind the profile to the virtual server.
Now what is new on the other hand is that with Windows Server 2016, HTTP/2 is by default enabled on IIS now compared with HTTP/1.1 which is now 15 years and using clear text transfers, HTTP/2 uses binary based transfer and is much more effecient
So to use HTML 5 + HTTP/2 access remotely, you need to enable WebSockets in Citrix policies, enable HTML5 on Storerfront to have access to it, enable HTTP/2 and WebSockets on NetScaler in the HTTP profiel and bind the profile to the NetScaler Gateway vServer
Smart Access and client choices
So up until now I have looked at using plain NetScaler Gateway Virtual Server (Double-hop, Optimal Gateway Routing and ICA Proxy) all these settings do not require any additional licenses outside of the platform license. Now we have Smart Access and Client Choices which require Universal Licenses for each connection. (This is defined by remove the ICA only setting on a virtual server which will mark it as Smart Access mode)Now using client choices a user has multiple options when logging in, for instance a user can get multiple options available for instance a user can go into clientless access mode which is a browser only based VPN connection, where a user can gain access to file shares, mail, and internal resources and bookmarks. Or a user can start a full VPN connection and have layer 2 network access ot the corporate network in that case when a user starts a Citrix application it will go across the VPN link so performance will not be as good as using regular ICA-proxy.
Some cool other features that can be used in Smart Access mode is for instance using he
* RDP Proxy which will allow access to RDP Connections using the NetScaler Gateway using the same external port that the NetScaler Gateway vServer runs on.
* Pre-authentication and endpoint scan policies with OPSWAT (Which can for instance be used to check if a client has antivirus and antimalware software running before they are allowed to connecgt
* Smart Access and Smart Policy
* ICA latency settings (New with NetScaler 11.1) which can be used to detect if an endpoint which a certain amount of latency should have Smart policies applied or not for instance if they have <10 MS latency.
But here we can mix alot of different settings in the same vServer, we can also publish web resources directly into the clientless access portal
Unified Gateway
So up until now I’ve been talking about using the NetScaler Gateway option to deliver remote access to Citrix users. All the options above (except for nfactor) can be delivered using a regular NetScaler Gateway appliance. Now Unified Gateway was a new feature which was introduced in version 11. The problem that has been with NetScaler Gateway was that people wanted to have multiple services behind a single IP-address and port. If you setup a regular Netscaaler Gateway you are limited to having Citrix ICA proxy on that service. Using Unified Gateway you are introducing another way of access. Firstly when a client connects to to a Unified Gateway server it will hit a Content Switching virtual server, and if the URL is correct the users will be redirected to the NetScaler Gateway Virtual server. Since the Gatewya vServer is non-adressable (IP = 0.0.0.0) you can access it via the same public IP. Now since we have a Content virtual server in front we can also add other services such as Exchange email, SharePoint or Web based applications behind the same IP and Port number.
So this video example just shows a Unified Gateway setup and having other resources like RDWeb behind the same URL and port
AlwaysON VPN NetScaler 11.1
So this is a new feature which was introduced in NetScaler 11.1 which allows for automatic sign-on against a NetScaler Gateway in Smart Access mode using a new endpoint client which came in 11.1. The automatic connection happens after a user is logged on the device, now based upon the AlwaysON policy on the NetScaler it should pop-up automatically and open up the homepage and allow for instant Citrix Receiver connection to the backend resources. Since this feature uses the credentials of the logged in user it is best used for SSO if for instance a user takes a corpoate laptop or computer home and want to access the enviroment from home. We need to define DNS suffix which will be used to check if the endpoint is on the corporate network or external. We can also define if the enduser should be able to disconnect from the tunnel or not.
The video below shows the user-experience from logging on from a Windows 10 computer and automatic setting up the VPN tunnel against the virtual server and opening up the homepage and doing direct SSO.
Clientless Access with RFwebUI
In most of the previous scenarioes we have been connecting to NetScaler and then with ICA-proxy on it will forward the credentials to Storefront and it will generate a application list in the Storefront Portal. Using Clientless Access with RFWebUI allows the NetScaler to act as the application portal instead of Storefront. Now NetScaler will communicate with Storefront to get a list of applications and desktops that the user has access to but instead NetScaler will generate the list, now the advantage with this is that we can now add web based applications like other load balanced virtual servers on the NetScaler and present this as a bookmark directly within the clientless access portal so combine (Citrix Apps + SaaS + WebApps) directly in the same portal, so were actually bypassing Storefront, the downside is that we lose the customization options that we have available in Storefront.
Now previously we needed to change some files on the web.config on Storefront but this is not needed anymore, we only need to speify the theme, add clientless access domain and set Clientless Access to ON. So from an enduser perspective it will look like this
NetScaler Gateway Service and Citrix Cloud
This service is still in beta so it has not been directly optimized yet. But for those that have tried Citrix Cloud so far knows that it deliveries the management bits of a Citrix infrastructure and then we need to have components installed locally known as CloudConnectors which act as DDC for the VDA agents. Now previously we needed to have a NetScaler somewhere to access these resources, Storefront was already hosted by Citrix Cloud so when a user clicks on an application it would generate an ICA file and connect to the NetScaler and access those VDA agents. The NetScaler ofc needed to have a public IP and digital certificate installed and also it needs to run either physically or as a virtual appliance. Using NetScaler Gateway Service some additional service will be installed on the CloudConnector virtual machine which will communicate directly with Citrix Cloud and act as a “Gateway” Now on the up side now we do not require any dedicated virtual appliance, no public IP or certificate just need to use the same VM we use for CloudConnector service. So traffic from an endpoint will be routed like this PC —-> CItrix Cloud NetScaler Service –> CloudConnector Windows VM (With Gateway Service installed) –> VDA and then back again so this will generate a lot higher RTT compared to having direct access to the NetScaler
But on the other side now they have implemented a form of GSLB which will point the enduser to the cloest Citrix Cloud service within the region, but it is pretty easy to setup as well
Make sure it is activated in Citrix Cloud
Make sure the service is installed and running on the cloud gateway VM
And access using the Cloud based storefront.
Windows 10 Azure AD Join with ADFS and federated authentication Service
So far in the previous scenarioes we have looked at using regular Active Directory as the authentication source against a Citrix enviroment, alot of customers are today moving towards Office365 and there they leverage AzureAD as part of it. Most customers use ADFS setup with AzureAD which means that they can get SSO within the same domain and same sign-on outside of the office. Now the cool thing with setting up AzureAD and ADFS is that we can now leverage SAML based authetication, which is cool because for instance NetScaler supports SAML but the problem has been up to now that Storefront does not support SAML until Citrix came with federated authentication service, so what this service does is that it maps a SAML token to a virtual smart card using Active Directory Certificate Services. So in the use case of Windows 10 which can be AzureAD joined a user can logon their Windows 10 computer using Microsoft Hello which leverages Microsoft Passport which can actually do two-factor authentication based upon just sitting in front of the computer, then it can be directly authenticated to the AzureAD portal because it will do SSO directly to ADFS, so now then the computer has a SAML token a user can go into Storefront and present the SAML token authenticate directly to Storefront which will map the SAML token to a virtual smart card to allow to so SSO directly to Storefront and backend VDA agents JUST BY SITTING INFRONT OF THE COMPUTER?! how cool is that?!
So this is just one example of how we can configure this to work, in this scenario the NetScaler Gateway Virtual Server is the SAML service provider and gets a SAML iDP trust to AzureAD.
So the videoclip below shows how it looks like from an enduser perspective when they try to login to their Windows 10 computer and wants to access their Citrix enviroment
Now of course there are other options that I haven’t consiered as well, and also there are new options coming here pretty soon as well!
Citrix & Windows 10 from Azure
XenApp Express
NetScaler and EMS integration
All these options which are because of the tight partnership between Microsoft and Citrix will interesting to take a closer look at when they arrive and will most likely be integrating with AzureAD and leverage more Azure features as well.
Great work Marius. Thanks for sharing this detailed guide and keeping it interesting for us.