As consultants, we run into scenarios where our clients want multiple types of two-factor authentication configured for their Citrix environment. They can have separate URLs to access each NetScaler Gateway but sometimes it is easier for all users to remember one URL and then select from the different authentication options.

This blog post will show you how to create a NetScaler Gateway that will host a simple landing page that can provide access to Gateways with different authentication options. Below is an example landing page that specifies smartcard as the main authentication method and RADIUS with username/password for users who have an exception.

I know some of you are wondering, “Doesn’t nFactor provide the option of allowing different factors of authentication on one Gateway?” The answer is YES, however, nFactor may not fit everyone’s use case. For example, say nFactor is configured with smartcard authentication and fallback is RADIUS with username/password. When users go to the NetScaler Gateway URL with their smartcard inserted, there is no actual log on page. They will receive a prompt to choose a certificate and type their PIN and then are taken to StoreFront. The user will not see any sort of disclaimer or Terms & Conditions. If their smartcard is not inserted, they will be taken to the RADIUS log on portal, which will show fields to type their username, password, and PIN. The problem here is that users cannot recover and go back to smartcard authentication, without closing their browser, if they have already fallen back to RADIUS by accident.

This is where a landing page would be useful. A landing page can let users who use smartcards know that they reached the Citrix logon page. It can also give users an opportunity to insert their smartcards after they reached the Gateway if they had forgotten. Additionally, all users will be able to see any disclaimers or help desk information.  Using a NetScaler to host the landing page instead of a web server also eliminates the need of using additional resources to provide hosting and high availability.  In addition, a web server would introduce another hop between the user and the Gateway.  Note that the NetScaler is NOT a full-fledged web server and should not host high-traffic or dynamic production web sites.

The only drawback is that instead of having one NetScaler Gateway virtual server for authentication, you will need three in this scenario. One to host the responder policy containing the web page and one for each of your Gateways providing authentication. Note that if you are using Native Receiver neither nFactor nor the landing page option are supported at this moment.

Configuring the Landing Page

To configure the landing page, you will need a separate NetScaler Gateway vServer with a responder policy bound to it.  The Gateway will need a public IP address and SSL certificate. Firewall rules will be required to allow TCP 443 to the IP address. Everything else does not need to be configured or can be disabled such as authentication policies, DTLS, AppFlow logging, etc. Also, the landing page only uses simple HTML/javascript and images should be base64 encoded. Dynamic code is not supported and image files are not recommended. This was tested on 11.1 57.11 but should work with any 11 or 12 firmware.

To configure the landing page first start by importing your HTML code. Navigate to AppExpert > Responder > HTML Page Imports.

For your HTML page, you can import from a URL, file, or copy and paste in the HTML code.  I chose the “Import From Text” option and pasted my HTML code in.  There is sample code at the bottom of the blog for the landing page shown at the beginning of the blog.

Next go to the “Actions” tab to create a responder action like below:

After you create the responder action, configure a responder policy.

Configure the responder policy with these settings:

Once the policy is configured, bind it to the NetScaler Gateway hosting the responder policy.

Once the NetScaler Gateway with the responder policy is configured, you just need the Gateways that will provide authentication. These Gateways can be configured normally with all public IP address, SSL certificate, authentication policies, STA servers, and session policies. In this example, a smartcard authentication Gateway will also contain a Cert Policy, any necessary CA certificates, and a SSL Profile or SSL Parameters to enforce Client Certificate as Mandatory. A RADIUS authentication Gateway will contain RADIUS and LDAP authentication policies.

On the StoreFront side, configure a Store for smartcard and a separate Store for RADIUS. The smartcard Store should be configured to allow “Smartcard” and “Pass-through from NetScaler Gateway”. Set the logon type on the Gateway as “Smartcard” and configure a Callback URL. Make sure in Configure Delegated Authentication that “Fully delegate credential validation to NetScaler Gateway” is checked. If you wish to eliminate the PIN prompt at ICA launch, you can configure another NetScaler Gateway and use HDX routing on StoreFront. If you wish to eliminate the PIN prompt at Windows logon, consider implementing Federated Authentication Service (FAS). There some great blogs out there already on these topics: here and here. For the RADIUS Store, configure “User name and password” and “Pass-through from NetScaler Gateway” as the authentication methods. Set the logon type as “Domain and security token”.

Sample HTML Landing Page Code

In the link below is the HTML code that was used to configure a landing page that contains the URLs of two Gateways for users to authenticate to.  You can also customize this page to contain information such as a disclaimer or include useful download links such as user guides or certificates.  If your webpage is going to have images, you can base64 encode them and include the code in the HTML file.

Andrew Wang
Citrix Public Sector Consultant