This position is monitored on a previous blog article last year on integrating Netscaler with the Belgian card solution electronic identity (eID) for all Belgian citizens.
Since then we have seen a number of authentication requests and not only transmit information to Web applications, but also to integrate it with the gateway component Netscaler to access XenDesktop applications and desktops with the eID card. For this many thanks go to solution Mokrane Hellal Koen Warson and Eaglan Kurek.
The image above provides the high-level overview of how it works and below described step step by step.
- the user has an eID, has an integrated smart card reader 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 to authenticate client certificate required (as in the previous blog article)
The user will prompted to enter their PIN number and will. authenticate with a certificate. - Netscaler perform the 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:
As you notice the "username" is filled with the serial number (national register number for the user, a unique identifier for all Belgian citizens) .This is set to Netscaler by putting authentication cert on the vserver Netscaler gateway as the first primary authentication method. Also on this authentication CERT auth we allow the field to two factors causing Netscaler to extract the national register number and pre fill the username field with it as seen here. Under Username field , type manually: subject :. SERIALNUMBER 
- The user only has to enter his directory (LDAP) Enables password.
- Netscaler performs LDAP authentication, as is the second policy for primary authentication (watch here for the certificate + LDAP to work in cascade mode, you have to put the authentication certificate first, followed by LDAP authentication in primary) .So what happens when you do LDAP authentication: actually Netscaler will first do an LDAP search with the main attribute of the serialNumber (national registration number) against the one of the fields configured to store the national register number on active Directory. In this case, we used the fax number field for this (as it is rarely used in a deployment) as shown below:
After successfully result of LDAP search of the national register number (serialNumber in the certificate) Netscaler will now use the value setup "SSO Name Attribute" to bind to LDAP with this value (example: samAccountName) and the password that the user entered. If no serial number is adapted in the search, the user can not connect. If the password is incorrect, the user can not connect. Thus, the LDAP server is configured as following screenshot: 
- After a successful LDAP authentication Netscaler now StoreFront connects with AGEEBasic parameters required for SSO. It will use the LDAP user name (samAccountName) and password for it. Storefront his term will speak at the service / XA XD XML, list the applications and send everything back through the receiver to the Web to the user.
As such, we now have successfully authenticated with our eID smartcard. and Active Directory password
things to note with this configuration:
- this requires the use of a SmartCard reader and middleware Belgium eID software must be installed [
- Browsers supporting eID are Internet Explorer, Mozilla Firefox, Safari and Google Chrome. At the time of writing Chrome had trouble, we had to use Chrome with beta middleware eID.
- This function will only receiver with the web not with Citrix native receptors.
Wait, there's more ...
when we try to launch applications, it will trigger a new PIN code request your eID card because Netscaler expected eID authentication every SSL connection (remember, the SSL certificate: mandatory) he also expects it to connect HDX SSL. This degrades the user experience, we do not want.
So we need to take some additional configuration steps to ensure that the HDX connection may take a separate path. To do this, we create a second vserver Netscaler access gateway from the outside with its own server certificate. Or you can use the same public address that the first vserver with a different port (eg 444). This vserver only work as a CIA proxy. (Reference :. This method is explained in SUM509 as presented by Nicolas Ogor Synergy 2010 in Berlin)
To configure the backend:
- Web Interface: Change the web interface settings so it returns the second vserver in the ICA file for customers, and customers launch their applications and workstations will connect to this second vserver.
- StoreFront 1.2: to configure Storefront you need to make similar changes. below illustrates the example screen capture second chance with the same FQDN and same IP address (and the same server certificate), but on a different port.
Also, for StoreFront you need to change the callback URL (silent authentication) to point to the second (or third reminder only) vserver. . Because the external face vserver will be asked for client certificate authentication, which StoreFront is not - StoreFont 2.0 : We are not able to verify yet in production, but in Receiver StoreFront 4.0 and 2.0 Auth manager would take care of this process. So, a second vserver without certificate authentication would not be necessary.
0 Komentar