n-factor – native OTP with multiple domains on the same portal

NetScaler introduced native OTP (One Time Password) some time ago, which you can incorporate in the login process as long as you have AD servers ready to use as a database.

The examples that are shown on citrix.com only covers the scenario where you have one domain connecting through NetScaler(and the abuse of policy “true” to make sure you catch the right requests), and the logical way to adding more domains, would be to add more vServers if you were to follow the same way of configuration. However with the right set of policies, its possible to have one set of vServers with multiple policies to support n* number of domains.

I’ll proceed the same way in this article as in my previous, which means it will give you an understanding on how the policies work together, rather than give you a copy and paste solution.

The solution is divided into 2 parts, a login part, and a management part.

User flow

The user look and feel is described in: https://support.citrix.com/article/CTX229941 with one exception.

I’ve added a link in the regular login flow to point to the management page. In the article it expects that the user types in the URL manually.

Prerequisites

Natie OTP uses AD as a database to store information about a user’s authenticated devices. Therefor special LDAP actions are required on NetScaler to write and search into a special field for a UserObject in AD. The citrix articles use the field called “userParameters”, but this could be changed if required.

Used for authenticating the user

Used for writing into AD

Used for fetching the value of userParamteres

Policies that use these 3 LDAP actions:

LDAP actions are required for each domain that you want to support.

Management flow (Add / remove devices)

Before your able to login you need to add a device(mobile/tablet) that NetScaler will accept tokens from. This is done on a special page – a authentication schema – that presents the user with the option to add or remove devices. This loginschema ships will NetScaler.

The page is invoked with a special url, in this case “/manageotp” (could be something else)

First add the authentication schema to a loginschema and tie it to a policylabel.

Add an catch all policy to get  the userinput into the flow.

Present the policylabel to the user. Note the special way of matching on URL in the authentication framework. It is the cookie called NSC_TASS that contains the value of the URL.

It is important that this policy is hit fairly early in the process, so the user is not caught in a different/default flow, thats why it has priority 90 (in my setup, this is the first policy that’s processed)

Depending on security requirements, you might want to add ip restrictions on this mangement page

Authenticate the users before sending them to the management page.

Now the users are able to see the page(loginschema) where they can add and remove devices. There is something fishy going on this page, it does not update the list of added devices after adding new device. Try and restart the flow if you cant see the added device.

Login flow

Alright, the user has now added a device via the previous flow and needs to login.

The first policy on the AAAVS was catching the url “/manageotp” – the next is the default login flow.

Now the user sees a prompt with a username, password + token dialogbox.

The first policy in the policylabel fetches the input and sends the user onwards to an internal schema to verify the token.

The next policylabel checks the Token first, and if that succeeds, verify if the password is also correct.

Checking the password is also an internal schema, but we cannot use the default one, since we need to specify where to extract the password from.

The configsnips are a part of a bigger configuration with more functionality(test if user exists, extract grp to decide login flow), so if it doesn’t quite make sense, it’s because i haven’t pasted ALL the config into the article. It’s difficult enough to keep it short as it is 😉 Hopefully there is enough for you to decode what’s going on and how to take the small pieces and implement in your setup.

Do not get to excited

But before you run off and replace SMSpasscode, RSA, token1-2-3 software, you need to know that its a very simple solution that you’ll get with the native otp, as it is right now(i don’t know if this is going to change going forward).

For example, there is no general managementpage on your users devices, each piece of metadata for every phone, is store in a userobject in AD. NetScaler does not come with an management page for all your users/devices, so you have to search and view/edit in AD, or go by the /manageotp page in NetScaler as the specific user(!).

Besides from that, it’s a very simple solution and seems to work very well. I’ve only tested with Google Authenticator app, but im guessing any authenticator app that follows the standard (if there is one) would work.