How to use different usernames against two authentication factors on Netscaler Gateway

[Updated 31/03/14 with another way of achieving the same result by splitting the authentication onto two separate pages which can now be done under StoreFront 2.5]

I recently had a question posed by a client who wanted to use Access Gateway on Netscaler to provide XenApp published applications to IOS devices.

Straightforward stuff you’d think right?

The situation soon got more complex when I found out that they had outsourced their two-factor authentication service to a third party, and that the usernames used on this system were different to both their internal Active Directory user ids and email addresses.

Even worse, they didn’t even use the existing UPN’s that one might use to authenticate with AD as an alternative to traditional user IDs.

Despite being able to setup multiple authentication services on an Access Gateway VIP, you can only enter a single userid that then get’s used against all authentication servers.

I love a good challenge, so set about working out how I would solve this problem, and I though I’d share the solution via this blog post.

Method 1 – Split StoreFront and Netscaler Gateway logins

Whilst most configurations pass the user-id the user enters on the login page through to StoreFront to use as the user to authenticate to the domain with, one doesn’t have to enable this configuration. It is possible to separate the Netscaler authentication (e.g. RADIUS), and the StoreFront authentication (AD/LDAP).

Disable pass-through from Netscaler Gateway

In StoreFront 2.5 you can now choose the authentication types supported for individual Receiver for Web sites.

This means you can create a second Receiver for Web site that has pass-through authentication disabled without impacting your existing Store.

Note you don’t want to remove the Remote Access configuration on your store, otherwise the STA ticketing functionality will cease to function. The store needs to be enabled for remote access, and you still need to configure your Gateways.

Disable token consistency check

There is a documented bug in all versions of StoreFront (including 2.5) which prevents StoreFront from authenticating users when Remote Access option is enabled but passthrough authentication not utilised.

To work around this, edit the web.config in the inetpub\wwwroot\<storename>\web.config

Search for the requireTokenConsistency=”true” and change this to requireTokenConsistency=”false”

Save the file.

Warning: according to this KB article, changing this setting may prevent SmartAccess filters from functioning in StoreFront 1.2. I have not tested whether this is the case on more recent versions of StoreFront, but be aware of this and test before proceeding down this route.

If you don’t disable this option, you will receive the following error in the Delivery Services Log, and the login-page just loops back to asking for credentials:

Gateway data from the request and the authentication token are not matching. Request was made to store Store Service.

Request data:

Remote Address: 1.2.3.4

X-Citrix-Via: agee.mydomain.com

X-Citrix-Gateway:

X-Forwarded-For: 3.3.3.3,10.0.0.1

Token data:

Remote Address:

X-Citrix-Via:

X-Citrix-Gateway:

X-Forwarded-For:

Gateway configuration:

System.String[]

Bind your non-AD authentication server as single primary cascade

On the Netscaler Gateway you should now bind your RADIUS authentication source as the single primary authentication server on your Netscaler gateway virtual server.

The users will be authenticated onto the Netscaler Gateway using their non-standard RADIUS credentials, and then presented with the StoreFront login page, which will accept their usual AD domain accounts or UPN. Objective achieved!

Note this method only works for the Receiver for Web logins. If any native Receiver clients are used, these all input credentials in one go, so it’s not possible to split the authentication across two separate pages, so you’ll need to use the more complex method below.

 

Method 2 – AD username look-up

Whilst method 1 does allow a different username from your AD account, most clients want to enter their credentials once, onto one single log on page. As such, we need to way of tying the RADIUS username and AD username together.

Choose AD attribute to store username

First I needed somewhere to store the login used by the third party. I chose an obscure attribute in AD that I know isn’t used by anything at present

 

Viewing the LDAP attributes of my modified user object, I can see the actual attribute that this “Other fax number” gets stored in:

Luckily the user ID’s used on the third party radius server can be programatically built based on the existing UPN’s (userPrincipleName) which means I can quickly populate AD using a recursive PowerShell/ADSI script.

Netscaler configuration

Authentication policies

For RSA SecureID two-factor authentication, we have a primary and secondary authentication policy bound to our access gateway virtual server.

One little known feature of the LDAP authentication server is that you can authenticate using any LDAP attribute, then query the directory (AD in our case) for a different attribute that’s then used for the single sign-on to Web Interface/StoreFront.

So let’s configure our LDAP authentication server with our chosen LDAP attribute from above:

 

I’ve configured the logon attribute to be the “otherFacsimileTelephoneNumber” as chosen earlier, and the “SSO Name attribute” to be the sAMAccountName – which will be our “real” AD username.

This will be combined with the “Single sign-on domain” configured in my main session profile to authenticate to WI/Storefront:

Session profile

The client uses their RSA SecureID (via RADIUS) as their primary password, which meant one further configuration change on my lab Netscaler – I need to tell the Access Gateway virtual server which of the authentication servers to use as the source user for WI/StoreFront authentication. This is performed by defining a session profile and policy, and configuring the “credential index” field:

Setting up a test RADIUS server

Not having an expensive RSA SecureID server and license to test against in my lab, I wanted to ensure my configuration worked in practice (as any hardened Access Gateway user will know, getting the theory right is only half the story…) so I needed a secondary authentication server to process the RADIUS login.

I downloaded and installed a free RADIUS server inside a Linux CentOS VM.

I added my lab Netscaler as an authorised client by editing the  /etc/raddb/clients.conf file:

client Netscaler {
  ipaddr = 10.0.0.10
  secret = mySecretKey
}

Then added a static RADIUS test user that matches my test email address to the /etc/raddb/users file:

neil@non.valid.email Cleartext-Password := "testpassword"

On my Netscaler I added a second authentication policy and server of type RADIUS with the IP address of my Linux VM, and the secret key configured to match. This was set as primary authentication on the access gateway VIP, with LDAP being the secondary.

Testing

If we authenticate to our test Access Gateway VIP

I’m entering my non-standard userid as the user name, my test RADIUS password as password 1, and my AD password as password 2.

Bingo! We are authenticated OK, and my applications are displayed in Web Interface/Storefront, despite having not entered my AD user!

We can check a couple of log files to see what’s happening behind the scenes.

From a Netscaler shell prompt:

cat /tmp/aaa.debug

(I’ve highlighted the significant log entries)

process_kernel_socket call to authenticate user :neil@non.valid.email, vsid :9306
start_radius_auth attempting to auth neil@non.valid.email @ 178.239.x.x
process_radius Got RADIUS event
process_radius radius accepts : neil@non.valid.email
send_accept sending accept to kernel for : neil@non.valid.email
process_kernel_socket call to authenticate user :neil@non.valid.email, vsid :11657
start_ldap_auth Starting LDAP auth
start_ldap_auth attempting to auth neil@non.valid.email @ 178.239.166.72
receive_ldap_bind_event receive ldap bind event
extract_ldap_attribute retrieved sAMAccountName value spellinn for neil@non.valid.email
send_accept sending accept to kernel for : neil@non.valid.email

We can see from the above that both RADIUS and LDAP authentication was sucessfull (two “accept” messages passed back to the kernel) and the LDAP sucessfully found “spellinn” as my NT userid.

We can confirm from the RADIUS server that our authentication request was granted:

Radius log

rad_recv: Access-Request packet from host 178.239.xx.xx port 48732, id=30, length=60
 User-Name = "neil@non.valid.email"
 User-Password = "password"
# Executing section authorize from file /etc/raddb/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] Looking up realm "non.valid.email" for User-Name = "neil@non.valid.email"
[suffix] No such realm "non.valid.email"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry neil@non.valid.email at line 1
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
# Executing group from file /etc/raddb/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password "password"
[pap] Using clear text password "password"
[pap] User authenticated successfully ++[pap] returns ok
# Executing section post-auth from file /etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 30 to 178.239.x.x port 48732
Finished request 0.

So, in summary, we’ve authenticated to both Netscaler and Web Interface/StoreFront using a secondary user-id and two-factor authentication to RADIUS and AD.