This post is a followup on a previous blog article last year on integrating Netscaler with the Belgian Electronic Identity Card (eID) solution for all Belgian citizens.

Since then we have seen a number of requests to not only authenticate and forward information to web applications, but also to integrate this with the Netscaler Gateway component to access XenDesktop applications and desktops with the eID card. For this solution many thanks go out to Mokrane Hellal, Koen Warson and Eaglan Kurek.

Flowchart diagram of eID auth for XenDesktop

The above picture provides the high level overview on how it works and below it is described step-by-step.

  1. The user has an eID, has a smart card reader built-in or attached to the PC and has the Belgian eID software installed. The user accesses the Access Gateway vserver URL https://cag.citrix.local/which is configured for client certificate authentication required (as in the previous blog article).Netscaler Gateway vserver SSL Parameters: Client Cert ManadatoryThe user will be prompted to enter his PIN number and will authenticate with its certificate.
  2. Netscaler will perform OCSP validation to validate the eID is valid and not revoked and/or reported stolen. Upon successful validation the user will see the following screen:Receiver for Web - Login with eID as usernameAs you notice the “username” is populated with the serial number (National Registry Number for the user, a unique ID for all Belgian Citizens).This is configured on Netscaler by putting CERT authentication on the Netscaler Gateway vserver as first Primary Authentication method. Additionally on this CERT authentication we enable the Two Factor auth field, which causes the Netscaler to extract the National Registry Number and pre fill the username field with it as seen here. Under the User Name Field, type in manually: subject:SERIALNUMBER.Authentication Profile Certificate
  3. The user now only has to enter his Active Directory (LDAP) password.
  4. Netscaler performs LDAP Authentication, as this is the second policy for Primary Authentication (pay attention here: for Certificate+ LDAP to work in cascade mode, one must put certificate authentication first, followed by LDAP in Primary Authentication).So what happens when doing LDAP Authentication: In fact Netscaler will first do an LDAP search with primary attribute the serialNumber (National Registry Number) against any of the fields configured to store the National Registry Number on Active Directory. In this case we’ve used the Fax number field for this (as this is seldom used in a deployment) as depicted below:Active Directory Fax number fieldUpon successful LDAP search result of the National Registry Number (serialNumber in the Certificate) Netscaler will now use the value of configuration “SSO Name Attribute” to bind to the LDAP with this value (example: samAccountName) and the password the user has entered. If no serial number is matched in the lookup, the user cannot login. If the password is incorrect, the user cannot login. So the LDAP Server is configured as following screenshot:Authentication Profile LDAP
  5. Upon successful authentication to LDAP Netscaler now connects to StoreFront with the necessary AGEEBasic parameters to do SSO. It will use the LDAP username (samAccountName) and password for this. Storefront on its term will talk to the XA/XD XML service, enumerate the applications and send everything back through the Receiver For Web towards the user.

As such we have now succesfully authenticated with our eID smartcard and Active Directory password.

Things to note with this configuration:

  • This requires the use of a SmartCard reader and the Belgium eID middleware software has to be installed.
  • Browsers supporting eID are Internet Explorer, Mozilla Firefox, Safari and Google Chrome. At time of writing Chrome was having difficulties so we had to use Chromium with the beta middleware  from eID.
  • This will only function with Receiver For Web not with the native Citrix Receivers.
Wait, there’s more…
when we try to launching any applications, it will trigger new PIN code prompts for your eID card because Netscaler expects eID authentication every SSL connection (remember, SSL Certificate: Mandatory) so it also expects this for the HDX connection in SSL. This degrades user experience, which we do not want.
So we need to take some additional configuration steps to make sure the HDX connection can take a separate path. To do this we create a second Netscaler Gateway vserver accessible externally with its own server certificate. Or you can use the same public address as the first vserver with a different port (e.g. 444). This vserver will only function as an ICA Proxy. (Reference: this method is explained in SUM509 as presented by Nicolas Ogor at Synergy 2010 in Berlin.)
To configure the backend:
  • Web Interface:Change the Web Interface settings so that it returns the second vserver in the ICA file to the clients, and the clients launching their apps & desktops will connect to this second vserver.Web Interface - Callback URLNetscaler Gateway configuration in Web Interface
  • StoreFront 1.2: To configure Storefront you need to make similar changes. The example screenshot below depicts the second possibility with the same fully qualified domain name and same IP address (and the same server certificate), but on a different port.StoreFront Netscaler Gateway configurationAlso, for StoreFront you need to change the Callback URL (Silent Authentication) to point to this second (or a third callback only) vserver. Because the external facing vserver will be asking for Client Certificate authentication, which StoreFront doesn’t do.
  • StoreFont 2.0: We haven’t been able to verify this in production yet, but in Receiver 4.0 and StoreFront 2.0 the Auth Manager would take care of this process. So a second vserver without Certificate authentication would no longer be needed.