Introduction

nFactor is the next generation authentication framework that offers great flexibility in configuring authentication flows for users. nFactor allows for extensible authentication models thus offering clean separation of workflows. This framework could be used to configure all the authentication modes currently possible with Citrix NetScaler.

Readers are advised to have basic understanding of nFactor entities described at CTX222713 - Concepts, Entities and Terms used for nFactor Authentication through NetScaler and are advised to review other documents at nFactor Authentication through NetScaler.

Problem

This article describes the use case where username is modified before sending to radius servrer. For example, user might login to Gateway in the formats user@domain (UserPrincipalName/UPN) or domain\username.
Here is the expected outcome:

1. If user enters UPN, it has to be converted to domain\username format.
2. If user enters domain\username format, it needs to be sent as is to radius server.

There are other variants of this requirement as well such as adding a fixed domain if user does not enter any or removing the domain part to send only the username to server. In addition, there could be other factors along with current one. These cases can be solved by following the model described in this document.

The solution proposed here checks for the format of the username from the client. If it is UPN, then user is taken to next factor for actual authentication. We employ NO_AUTHN to take the users to next factor in this case. If user enters domain\username, authentication is performed in the first factor itself. 

Configuration

Configuration is best understood by following a bottom-up manner. That is, we configure the most specific factor (or the last factor) first.

1. Create the factor for authenticating users entering UPN
   1. Create loginschema for second factor
      
      > add loginschema second_factor_schema –authenticationSchema noschema –userexpression q{http.req.user.name.after_str("@") + "\\" + http.req.user.name.before_str("@")}
      
      In the above loginschema, we are setting userExpression such that “user@domain” becomes “domain\user”. We also set authenticationSchema as noschema to signify that user intervention is not needed for this factor
   2. Create second authentication factor
      
      >add authentication policylabel second_factor -loginSchema second_factor_schema
      
      > add authentication radiusAction Radius_server -serverIP 10.217.22.20 –radKey <> -radNASid netscaler –radVendorID 311 -radAttributeType 11
      
      > add authentication Policy Radius_Pol -rule true -action Radius_server
      
      Please note that same radius policy/action are used in both factors.
      >bind authentication policylabel second_factor –policy Radius_Pol –priority 100
2. ​Add first factor
   1. Create a policy to bypass first factor if username is UPN
      >add authentication Policy upn_no_auth -rule "HTTP.REQ.BODY(1000).TYPECAST_NVLIST_T(\'=\',\'&\').VALUE(\"login\").CONTAINS(\"%40\")" -action NO_AUTHN
   2. Bind the bypass policy to authentication vserver to navigate to second factor
      >bind authentication vserver aaa_nfactor -policy upn_no_auth -priority 90 -nextFactor second_factor -gotoPriorityExpression END
   3. Bind the radius policy to authentication vserver for domain\user format
      We will reuse the Radius policy created above in the first factor as well.
      >bind authentication vserver aaa_nfactor –policy Radius_Pol –priority 100
3. Creating nFactor flow (required only for Gateway logins)
   > add authentication vserver aaa_nfactor SSL
   > add authnProfile nfactor_prof –authnVsName aaa_nfactor
   > set vpn vserver <> -authnProfile nfactor_prof

The above nFactor configuration can also be done using the nFactor Visualizer which is a few feature that is available on the ADC firmware starting 13.0, the above config for step 1 and 2 can be achieved as below,

Complete Flow:


 

1. Go To Security > AAA-Application Traffic > nFactor Visualizer > nFactor Flow and click on Add
2. Click on the + sign to add the nFactor Flow
   
3. Add Factor, this will be the name of the nFactor Flow

Click on Create.
 

4. Click on “Add Schema” for the initial login page to be presented,

Click on Create, then click on Add.
 

5. Click on “Add Policy” to create the first factor authentication, if the policy is already added select the same from drop down list if not then create the below Auth policy.

Click on OK.
 

6. Click on the green + icon to add the next factor in case the user has entered the UPN in the username field.

Click on Create
 

7. Click on “Add Schema” to add the schema for second factor, the userExpression added is  such that “user@domain” becomes “domain\user”

In case the schema is already added then select the same from the drop down list, if not then create the schema as below,


Click on Create and then click on Add
 

8. Click on “Add Policy” to add the authentication for the second factor, In case the Radius server is added then select the same from drop down list if not then add the Radius server,

Click on Create and then click on Add.
 

9. Click on the blue + icon of the first factor to add the authentication policy for users that are entering the username in domain\user format,

10. In the Add Policy, we will be reusing the same Radius policy that we just added in step 8

Click on Add, then click on Done
 

11. Now Select the Nfactor flow that we created to bind it to an authentication Vserver.

In the above flow, “upn_no_auth” policy is a dummy/no-authentication policy used to jump to second factor to attempt login after modifying the username.

NO_AUTHN policies can be used to simulate implicit success logic. NO_AUTHN policies help to compute logical decisions such as the current case.

Please note that browsers/clients url encode the input data. Therefore special characters such as “@” are encoded in the request. Therefore, care must be taken when checking for form values in policy rules.