Secure Citrix Gateway backdoor for end users!


Last month I was assisting one of my customers with migrating their gateways to a new SDX instance. This customer makes use of 2 gateways. One regular gateway to get access to a Citrix desktop by providing username, password and tokencode. The other gateway does exact the same thing but different. On a regularly basis users forgot to bring their hardware token or users don’t have access to a token. Therefor this customer created a gateway with Single Sign-On disabled on the backend. So, to get access a user has to call the helpdesk. This servicedesk employee has a personal token but also a kind of dummy token which corresponds to a dummy user. The servicedesk employee gives the user the credentials for this dummy account and also the specific tokencode. After the users signs in with those credentials he can logon with his personal StoreFront credentials to get access to his personal desktop.

In this blogpost I will explain how we migrated this usecase to make use of Citrix ADC nFactor instead of disabling the SSO feature from ADC to StoreFront.

Basic nFactor settings to get 2 Factor working

In this blogpost I’m not covering all of the nFactor authentication steps so assuming here that you already have a Citrix Gateway VIP in place which points to the AAA VIP via a authentication profile instead of making use of basic authentication policies on the Citrix Gateway VIP itself.

More detailed info on how to setup nFactor can be found here:

Basically, the following steps have to be done first:

  • Create a AAA VIP
  • Create a Login Schema Profile (which makes use of dualauth.xml or another template)
  • Create a Login Schema Policy
  • Link the Login Schema Policy to the AAA VIP
  • Create a Authentication Profile which points towards the AAA VIP
  • Link the Authentication Profile to the Gateway VIP
  • Create a LDAP Authentication Profile
  • Create a Advanced Authentication Policy for LDAP
  • Create a RADIUS Authentication Profile
  • Create a RADIUS Authentication Policy
  • Create a Authentication PolicyLabel for RADIUS with login schema LSCHEMA_INT (passcode is already entered in previous stage)
  • Bind the Advanced LDAP Authentication Policy to the AAA VIP
  • Specify the RADIUS Authentication PolicyLabel as next factor

This will result in a Citrix Gateway Virtual Server where a user can login with username, password and tokencode. Note that you can specify the text labels per login schema, this will override the portal theme labels!


Advanced nFactor settings ask for the real username and password

Remember: the main problem was that this user was calling the servicedesk to login with a different account because he forgot to bring his token. So, with above configuration the SSO to StoreFront will fail after the valid servicedesk credentials and tokencode have been specified.

Here we came up with the idea to create another nFactor step where the user can specify his own username and password without token and then do the SSO to StoreFront to access their published apps and desktops.

On top of the current configuration we have to create another Login Schema and Authentication PolicyLabel. When binding this in the correct way a user have to pass all factors to reach any homepage or StoreFront page.

First we have to create a login schema profile via Security > Login Schema > Profiles


Note that we make use of the default SingleAuth.xml template. If needed you can make changes to the defaults. The new template will be saved on the following location: /nsconfig/loginschema/newtemplate.xml

Then we have to create a PolicyLabel, this PolicyLabel will be used after the user successfully passed the first factors (username, password and tokencode).

You can create a PolicyLabel via Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > PolicyLabel

For this PolicyLabel we have to specify another Login Schema because the user has to enter personal credentials that can be used for SSO to StoreFront to gain access to their person apps and desktops. We use the Login Schema we’ve just created.

Note that we bind the same authentication policy to this PolicyLabel, we simply check again if the specified user credentials are correct.


After the PolicyLabel is created we have to link this somewhere in the nFactor authentication flow. This needs to be done after the RADIUS authentication step. Therefore we have to change this RADIUS PolicyLabel that was created in the first phase.

We need to specify the Next Factor option, in other words after the RADIUS PolicyLabel is finished what will be the Next Factor (PolicyLabel). In this case this will be the LDAP only PolicyLabel where the user get prompted for their personal credentials.


With that the configuration is complete, after the user logged on with the 2 factor enabled servicedesk account he now is able to enter personal credentials.





In this blogpost I tried to explain how to create a secure kind of backdoor for your users. By contacting the servicedesk they will get a shared account with tokencode. After login with those credentials they can login with their personal account which will be used for SSO to the backend.

Leave a Reply




This site uses Akismet to reduce spam. Learn how your comment data is processed.