Author: Carl Stalhood

Navigation

• Change Log
• nFactor Overview
• nFactor High-level configuration summary
• AAA Virtual Server
  • Create AAA vServer
  • AAA Portal Theme
  • AAA Client Certificate Authentication
• Login Schema
  • Login Schema XML File
  • Login Schema Profile
  • Login Schema Policy
• Authentication Policies
  • Create Authentication Action
    • LDAP Group Extraction
  • CreateAuthentication Policy
  • Bind First Factor Authentication Policy to AAA vServer
• Authentication Policy Label
  • Create Authentication Policy Label
  • Bind Authentication Policy Label to Next Factor
• nFactor for Citrix Gateway
  • AAA Authentication Profile
  • Gateway Client Certificate Authentication
  • Traffic Policy for nFactor Single Sign-on to StoreFront
• Sample Configurations:
  • Certificate auth: If Success, LDAP only. If fails, LDAP+RADIUS
  • Group Extraction, followed by LDAP (Active Directory), or Azure MFA (NPS)

💡 = Recently Updated

Change Log

• 2023 July 3 – Sample Configurations – added link to CTX561487 How to configure EPA domain check combined with Smartaccess feature
• 2023 Mar 10 – AAA vServer – encrypt nFactor login fields.
• 2020 Oct 13 – Overview – added some info regarding ADC Standard Edition.
• 2020 Mar 5 – added link to Mark DePalma Running RSA SecurID/Azure MFA side-by-side using an AD group on NetScaler Gateway
• 2020 Feb 27 – updated link to Citrix ADC nFactor Basics Cheat Sheet
• 2019 Nov 16 – Overview – added link to CTX264698 Citrix ADC nFactor Basics Cheat Sheet
• 2019 Aug 8 – Login Schema XML File – added link to nFactor Extensibility at Citrix Docs
• 2019 Jul 1 – Sample Configurations – ADC 13 has a CAPTCHA authentication action instead of WEBAUTH
• nFactor Flow Visualizer
• Updated screenshots for ADC 13

nFactor Overview

nFactor lets you configure an unlimited number of authentication factors. You are no longer limited to just two factors.

nFactor seems to be Citrix’s preferred authentication architecture. All authentication mechanisms are moving from Citrix Gateway to nFactor.

Citrix Tech Zone Citrix ADC nFactor Basics Cheat Sheet.

Each authentication factor performs the following tasks:

1. Collect credentials or data from the user. These credentials can be anything supported by Citrix ADC, including:
   • SAML assertion
   • Client Certificate
   • Forms-based authentication (traditional web-based logon page) for LDAP, RADIUS, TACACS, etc. – aka Login Schema
     • Multiple passwords can be collected with one form.
     • Or prompt the user multiple times (multiple forms) throughout the authentication chain.
     • The logon page can contain a domain drop-down.
     • Native OTP passcode
     • Citrix ADC Self-Service Password Reset with email verification
   • Native OTP Push authentication
   • OAuth OpenID Connect
   • Kerberos ticket
   • StoreFrontAuth – authentication is delegated to Citrix StoreFront
   • Endpoint Analysis Scan – either pre-authentication, or post-authentication.
   • EULA
   • Google reCAPTCHA
   • Swivel
   • Use a drop-down to select an authentication method
   • Cookie – e.g. NSC_TASS cookie containing URL path entered after the Gateway/AAA’s FQDN
   • Client IP address
   • No credentials/data – ADC policy expression uses criteria it already has (e.g. collected from a prior factor)
2. Evaluate the collected credentials. The results can be:
   • No authentication – policy expression is evaluated only to determine next factor
   • Authentication success
   • Authentication failure
   • Group extraction
   • Attribute extraction from SAML, Certificate, JWT, etc.
3. Based on the evaluation results, do one of the following:
   • Allow access to Gateway or Web site
   • Select next factor
   • Deny access
4. If there’s a Next Factor, repeat these steps, until there are no more Next Factors to evaluate.

Factors can also be configured only a decision point meaning that the factor does not perform any authentication and instead uses Citrix ADC Policy expressions to select the Next Factor. For example:

• If client IP is internal, next factor is LDAP only.
• If client IP is external, next factor is LDAP and then another factor for RADIUS.

Here are some nFactor use cases, but the combinations are almost limitless:

• Choose Authentication method based on Active Directory group: Logon screen asks for user name only. Extract user’s groups from Active Directory. Based on user’s Active Directory groups, either ask user for client certificate, or ask user for LDAP password. If LDAP, the username doesn’t need to be entered again.
• Ask for Certificate first:
  • If client certificate is valid, perform LDAP only.
  • If no client certificate, perform LDAP + RADIUS
• Two-factor with passwords checked in specific order: Display logon screen with two password fields. Check the first password. If the first password succeeds, then check the second password. This lets you check RADIUS before LDAP.
• Run Endpoint Analysis first:
  • If EPA passes, perform LDAP only.
  • If EPA fails, perform LDAP + RADIUS
• See Sample Configurations later for many more combinations.

All new authentication methods added to Citrix ADC require nFactor configuration and are not supported on native Citrix Gateway. These new authentication methods include:

• StoreFrontAuth – authentication is delegated to Citrix StoreFront
• Native OTP (one-time password) – e.g. Google Authenticator
• Self-Service Password Reset (SSPR)

nFactor is a AAA feature, which means you need Citrix NetScaler ADC Advanced Edition or Citrix NetScaler ADC Premium Edition.

• ADC 13.0 build 67 and newer support nFactor in NetScaler ADC Standard Edition licensing.
• To configure nFactor in NetScaler Standard Edition, go to Citrix Gateway > Virtual Servers and edit a Virtual Server. On the right, add the Authentication Profile section. Click Add to create an Authentication Profile. Then click Add to create an Authentication Virtual Server.
  
  
  
• Not all Authentication Policy types are supported in Standard Edition. See Citrix Docs for the list.
  

Citrix ADC supports two types of authentication policies – Classic, and Advanced (aka Default). You can bind Classic Authentication Policies directly to Citrix Gateway Virtual Servers, but today you cannot bind Advanced Authentication Policies to Citrix Gateway. The only way to use Advanced Authentication Policies with Citrix Gateway is to configure nFactor on a AAA Virtual Server and then link the AAA Virtual Server to the Gateway Virtual Server.

Workspace app 1809 and newer with Citrix Gateway 12.1 build 49 and newer support nFactor authentication. Older Receivers and older NetScalers don’t support nFactor, so you’ll instead have to use a web browser.

nFactor High-level Configuration

Here’s a high level summary of nFactor configuration objects. Detailed instructions are provided later in this article.

Each factor is a Policy Label that combines Advanced Authentication Policies and Login Schema.

• Login Schema is a XML file that nFactor uses to create a custom HTML form where users enter credentials.
  • Login Schemas are optional depending on the authentication method you are configuring.
• If an Advanced authentication policy expression evaluates to true, then an authentication action is performed.
  • Citrix ADC has many different types of authentication actions.
  • nFactor authentication policy expressions use Advanced Syntax (Default Syntax) instead of the older Classic Syntax expression traditionally used in Citrix Gateway authentication policies. An example Advanced syntax expression is true. An example classic syntax expression is ns_true.
  • When binding an Advanced authentication policy to a Policy Label or AAA vServer, you can optionally select a Next Factor, which is another Policy Label.
    • If the authentication action is successful, then nFactor processes the configured Next Factor.
    • If Next Factor is not configured, then nFactor is complete and authentication is successful.
  • If the authentication action fails, then the next lower priority (higher priority number) authentication policy in the same factor is evaluated. If there are no more authentication policies in the same factor, then the entire nFactor authentication flow failed.

AAA vServer – nFactor configuration is always bound to a AAA vServer, even if you want to use nFactor with Citrix Gateway.

• An Authentication Profile links the AAA vServer with Citrix Gateway.

nFactor Configuration methods – Citrix ADC 13 has two methods of configuring nFactor:

• ADC 13 adds nFactor Flow Visualizer, which makes it easy to link the Factors (Policy Labels) together.
  • After creating a Flow, you bind the Flow to a AAA Virtual Server.
• Manually – Create Policy Labels, Login Schemas, Authentication Policies/Actions, and manually bind them together and to a AAA Virtual Server. This is the only method available in ADC 12.1 and older.
  • For the first factor, you bind Authentication Policies/Actions and Login Schemas directly to a AAA Virtual Server without using a Policy Label.
  • All other factors are Policy Labels linked using the Next Factor bind points.

The Visualizer is a better option for understanding the nFactor flow, but neither method is flexible:

• If you want to rename factors, then you have to delete the factor and remake it.
• You can’t change a factor’s Login Schema without deleting and remaking the factor.
• Visualizer does not let you delete factors. Instead, you can either delete the Policy Label outside of the flow configuration, or you can delete the entire flow and start over.
• With Manual method, it is difficult to rearrange factors, especially since the first factor is not a Policy Label like the other factors. Visualizer lets you graphically change how the factors are linked together.
• The Manual method is typically configured from bottom up which makes it difficult to understand the entire nFactor flow.

Also see:

• Citrix CTX222713 Concepts, Entities and Terms used for nFactor Authentication through NetScaler.
• Jacob Rutski NetScaler nFactor Authentication
  

This article will detail how to use the Manual method to configure nFactor from top to bottom:

1. Create AAA vServer
2. Create First Factor:
   1. Create Login Schema Profile
   2. Create Login Schema Policy – only for first factor – if policy expression is true, then display Login Schema
   3. Create Authentication Actions – LDAP, RADIUS, etc.
   4. Create Advanced Authentication Policies – if policy expression is true, then perform authentication action
   5. Edit AAA vServer, bind Login Schema, and bind Authentication Policies
3. Create Next Factor:
   1. Create Login Schema Profile
   2. Create Authentication Actions – LDAP, RADIUS, etc.
   3. Create Advanced Authentication Policies – if policy expression is true, then perform authentication action
   4. Create Authentication Policy Label, select Login Schema, and bind Advanced Authentication Policies
   5. Edit AAA vServer, edit Authentication Policy binding, and configure Next Factor to this Policy Label
4. Create Next Factor:
   1. Create Login Schema Profile
   2. Create Authentication Actions – LDAP, RADIUS, etc.
   3. Create Advanced Authentication Policies – if policy expression is true, then perform authentication action
   4. Create Authentication Policy Label, select Login Schema, and bind Advanced Authentication Policies
   5. Edit other Policy Label, edit Authentication Policy binding, and configure Next Factor to this Policy Label
5. Continue creating Factors and linking them until the flow configuration is complete.
6. Create Citrix Gateway Traffic Policy for Single Sign-on to StoreFront.
7. Edit existing Citrix Gateway, create Authentication Profile, and bind Traffic Policy

Once you are familiar with nFactor, due to the way the objects are linked together, it’s probably easier to configure nFactor from the bottom up:

1. Create Authentication Actions for all factors – LDAP, RADIUS, etc.
2. Create Advanced Authentication Policies for all factors
3. Create Login Schema Profiles for all factors
4. Create Authentication Policy Labels for all factors except the first factor.
   1. Start with leaf (bottom) factors so you can configure Next Factor when binding authentication policies in higher branch factors. For example, if your flow is Collect Username –> Perform LDAP –> Perform RADIUS, then create the RADIUS Policy Label first so you can link to it when creating the LDAP Policy Label.
5. Create Login Schema Policy for first factor
6. Create AAA vServer – bind Login Schema, bind Authentication Policies, and select Next Factor Policy Label
7. Create Citrix Gateway Traffic Policy for Single Sign-on to StoreFront.
8. Create Authentication Profile
9. Edit existing Citrix Gateway, create Authentication Profile, and bind Traffic Policy

It can be difficult to visualize a manually-created nFactor configuration, so my ADC Virtual Server Configuration Extractor script now includes a nFactor visualizer. Here’s an example for a Native OTP configuration.

AAA Virtual Server

Create AAA Virtual Server

This section applies to NetScaler ADC Advanced Edition and Premium Edition. For NetScaler ADC Standard Edition, go to Citrix Gateway > Virtual Servers, edit a Gateway, add the Authentication Profile section, create an Authentication Profile, and then create a Authentication Virtual Server from there.

nFactor is configured on a AAA Virtual Server. Then you later link the AAA Virtual Server to the Citrix Gateway Virtual Server.

1. If the AAA feature is not already enabled, on the left menu, expand Security, right-click AAA – Application Traffic, and click Enable Feature.
   
2. Go to Security > AAA – Application Traffic. On the right, click Change authentication AAA settings.
   
3. Find Login Encryption and enable it. Click OK.
   
4. Go to Security > AAA > Virtual Servers.
   
5. On the right, click Add.
   
6. Give the Virtual Server a name.
7. If this AAA Virtual Server is only for Citrix Gateway, then you can change the IP address Type to Non Addressable.
   • It’s also possible to content switch to AAA (Citrix CTX201949 One Public IP for AAA-TM Deployments on NetScaler).
8. Click OK.
   
9. For a non-addressable AAA vServer, configuring the certificate is optional, but the AAA vServer will be DOWN (red) without a certificate. The AAA vServer still works even if its status is DOWN. Binding a certificate will change the AAA vServer’s status from DOWN to UP (green).
   1. In the Certificates section, click where it says No Server Certificate.
      
   2. In the Server Certificate Binding page, click where it says Click to select.
      
   3. Click the radio button next to a certificate for the AAA Virtual Server, and click Select. Since this AAA Virtual Server is not directly addressable, the chosen certificate doesn’t matter.
      
   4. Click Bind.
      
10. Click Continue to close the Certificate section.
    
11. You probably haven’ts created any Advanced Authentication Policies yet, so just click Continue. Note that this is where you bind the authentication policies for the first factor.
    

Bind Portal Theme to AAA Virtual Server

If this AAA Virtual Server is used not just for Citrix Gateway but also directly addressable for traffic management (Load Balancing, Content Switching), then you might want to change the AAA Portal theme.

1. Go to Citrix Gateway > Portal Themes, and add a theme. You create the theme under Citrix Gateway, and then later bind it to the AAA Virtual Server.
   
2. Create a theme based on the RfWebUI Template Theme.
   
3. After adjusting the theme as desired, at the top of the portal theme editing page, click the link labelled Click to Bind and View Configured Theme.
   
4. Change the selection to Authentication.
5. Use the Authentication Virtual Server Name drop-down to select the AAA Virtual Server, and click Bind and Preview. You can close the preview window.
   

Client Certificate Authentication

If one of your authentication Factors is client certificate, then you must perform some SSL configuration on the AAA Virtual Server:

1. Go to Traffic Management > SSL > Certificates > CA Certificates, and install the root certificate for the issuer of the client certificates. Root certificates do not have a key file.
   
   
   
2. Go to Traffic Management >SSL > Change advanced SSL settings.
   
   1. Scroll down. If you see Default Profile: ENABLED, then you must use an SSL Profile to enable Client Certificate Authentication. Otherwise, you can enable Client Certificate Authentication directly on the AAA Virtual Server in the SSL Parameters section.
      
3. If Default SSL Profiles are enabled, then create a new SSL Profile with Client Authentication enabled:
   1. On the left menu, expand System, and click Profiles.
   2. On the top right, switch to the tab named SSL Profile.
      
   3. Right-click the ns_default_ssl_profile_frontend profile, and click Add. This copies settings from the default profile.
      
   4. Give the Profile a name based on this goal: enable Client Certificates.
      
   5. Scroll down and find the Client Authentication checkbox. Check the box.
   6. Change the Client Certificate drop-down to OPTIONAL.
      
   7. Scroll down and click OK to close the Basic Settings section.
      
   8. Copying the default SSL Profile does not copy the SSL Ciphers so you’ll have to redo them.
   9. Click Done when done creating the SSL Profile.
   10. Go to Security > AAA – Application Traffic > Virtual Servers, and edit a AAA vServer.
       
   11. Scroll down to the SSL Profile section and click the pencil.
       
   12. Change the SSL Profile drop-down to the profile that has Client Certificates enabled. Click OK.
   13. Scroll down this article until you reach the instructions to bind the CA certificate.
4. Go to Security > AAA > Virtual Servers, and edit an existing AAA Virtual Server you’re using for nFactor.
5. If default SSL Profiles are not enabled:
   1. On the left, scroll down to the SSL Parameters section, and click the pencil icon.
      
   2. Check the box next to Client Authentication.
   3. Make sure Client Certificate drop-down is set to Optional.
      
   4. Click OK to close the SSL Parameters section.
      
6. On the left, scroll up to the Certificates section, and click where it says No CA Certificate. Do this whether you are using SSL Profiles or not.
   
   1. In the CA Certificate Binding page, click Click to select.
      
   2. Click the radio button next to the root certificate for the issuer of the client certificates, and then click the blue Select button on the top of the page.
      
   3. Click Bind.
      

Login Schema

Login Schema XML File

Login Schema is an XML file providing the structure of forms-based authentication logon pages.

nFactor implies multiple authentication Factors that are chained together. Each Factor can have different Login Schema pages/files. In some authentication flows, users could be presented with multiple logon screens.

Or you can have one Login Schema gather information that can be passed on to multiple Factors, so that the later Factors don’t need to display another Login Schema. This is particularly useful for traditional two-password logon screens (LDAP + RADIUS), since each password is evaluated in a separate Factor:

• The first password is evaluated in the first factor (e.g. LDAP). If successful, then evaluate the Next Factor.
• The second factor (e.g. RADIUS) evaluates the second password. However, the second password has already been entered, so there’s no need to ask the user for it again. To prevent the second factor from showing another Login Schema to the user, select noschema (LSCHEMA_INT) in the Authentication Policy Label.

Several Login Schema .xml files are included with Citrix ADC under /nsconfig/loginschema/LoginSchema.

In the Citrix ADC management GUI, when creating or editing a Login Schema entity, you can Edit the labels. Citrix ADC copies the modified Login Schema to a new .xml file based on the Schema Name entered in this widow, or based on the original file name.

Or you can use WinSCP to connect to the appliance, duplicate one of the existing .xml files, and edit it as desired. For example, you can configure fields (InitialValue tag) to pre-fill information from previous Factors, as shown below:

The structure of the Login Schema file is documented at Citrix Common Authentication Forms Language Citrix Developer Documentation.

nFactor Extensibility at Citrix Docs explains how to use JavaScript to add custom login labels, add custom login credentials, customizing UI displays and so on.

CTP Sam Jacobs at SYN229 – nFactor and Login Schemas explains how to customize the .xml file.

The login schema can contain a domain drop-down. See CTX201760 nFactor – Domain Drop-Down in First Factor then Different Policy Evaluations Based on Groups for a sample configuration.

Login Schema and Authentication Factor can be a EULA. See Configure EULA as an authentication factor in NetScaler nFactor system at Citrix Docs.

Citrix CTX219545 Custom Login Labels in NetScaler nFactor Authentication: add a Requirement element with a Label sub-element to the Login Schema .xml file. Then use JavaScript to populate the label with any desired HTML. Another example is Morten Kallesoee nFactor – adding custom links.

Several more samples can be found later.

Login Schema Profile

Login Schemas define a user interface (web page form) that is shown to the user. Login Schema Profiles are bound directly to Policy Labels (aka Factors). After the user fills out the form and submits it, nFactor uses the submitted form fields to evaluate the authentication policies bound to the same Policy Label.

To create a Login Schema Profile:

1. Create or Edit a Login Schema .XML file based on your nFactor design.
2. Go to Security > AAA > Login Schema.
   
3. On the right, switch to the tab named Profiles and click Add.
   
4. Name the Login Schema.
5. In the Authentication Schema field, click the pencil icon.
   
6. The window expands to show Login Schema Files. Click the LoginSchema folder to see the files in it.
   
7. Select one of the files. You can see a preview on the right.
8. The labels can be changed by clicking the Edit button on the top right.
   
9. When you Save the changes, a new file is created under /nsconfig/LoginSchema.
   
10. The top of the screen shows the new file name. You’ll have to go up a folder and select the new file instead of the folder you’re looking at.
    
11. Next to each file is an icon to download the file so you can modify the XML and then upload a new copy.
    
12. Once you’ve found the file you want and clicked it to preview it, then on the top right, click the blue Select button. You might be tempted to click the blue Create button on the bottom of the screen but don’t do that until you have clicked the blue Select button.
    
13. After you click the blue Select button, the window collapses. Look in the Authentication Schema field to make sure you selected the correct file.
    
14. Click More.
    
15. You typically need to save the entered credentials so you can use them later in a Single Sign-on flow to a back-end server (e.g. Citrix StoreFront). Near the bottom of the Login Schema Profile, enter a unique value between 1 and 16 for the Password Credential Index .
    
    • Later you reference the index value in a Traffic Policy/Profile by using the expression AAA.USER.ATTRIBUTE(#).
      
    • Each Login Schema can store different credentials in different indexes.
16. Click Create to create the Login Schema profile.
    

If you later edit the Login Schema .xml file using WinSCP or similar, then the changes to the file might not be reflected until you edit the Login Schema Profile, and click the blue Select button for the .xml file again.

Login Schema Policy

For most factors, you can bind a Login Schema Profile directly to a Policy Label. However, the first factor is bound directly to the AAA vServer and does not use a Policy Label. To bind a Login Schema directly to a AAA vServer, you must first create a Login Schema Policy. You don’t need Login Schema Policies for any factor other than the first one.

To create a first factor Login Schema Policy:

1. In the left menu, go to Security > AAA > Login Schema.
   
2. On the right, switch to the tab named Policies, and click Add.
   
3. Use the Profile drop-down to select the Login Schema Profile you already created.
4. Enter a Default Syntax expression (e.g. true) in the Rule box.
   1. For the first factor, you can use policy expressions to control whether a Login Schema is shown to the user or not. For example, you might bind two Login Schemas to the AAA vServer but have a policy expression that only shows a Login Schema if the client IP is in the internal network instead of from the Internet.
   2. Policy expressions only apply to the first factor; subsequent factors (Policy Labels) always show their Login Schema.
5. Click the blue Create button when done.
   

Bind first factor Login Schema to AAA vServer:

1. On the left, go to Security > AAA > Virtual Servers, and edit an existing AAA Virtual Server.
   
2. On the right, in the Advanced Settings column, click Login Schemas.
   
3. On the bottom left, in the Login Schemas section, click where it says No Login Schema.
   
4. In the Policy Binding window, click where it says Click to select.
   
5. Click the radio button next to the Login Schema policy, and then click the blue Select button on the top of the window. Only Login Schema Policies appear in this list. Login Schema Profiles (without a policy) do not appear.
   
6. Click Bind.
   

Authentication Policies

Authentication policies are a combination of policy expression, and policy action. If the expression is true, then perform the authentication action.

• The Action is an authentication server (LDAP, RADIUS, etc.), or no authentication (i.e. do nothing, typically for selecting a Next Factor).
• For nFactor, the policy expression must be in the newer default syntax, not the older classic syntax.

You typically create at least one Authentication Policy for each Factor. When you bind multiple Authentication Policies to one Factor, Citrix ADC checks each authentication policy in priority order until one of them succeeds.

Note: Citrix Gateway 12.0 and newer have deprecated Basic Authentication Policies (Classic Syntax). The only way to bind an Advanced Authentication Policy (Default Syntax) to Gateway is through nFactor and AAA.

Create Authentication Actions

Authentication Policies need configured Authentication Servers (e.g. LDAP, RADIUS, CERT, SAML, etc.). You can create Authentication Actions (Servers) prior to creating the Authentication Policy.

• In the left menu, go to Authentication > Dashboard. On the right, click Add.
  
  • Select a Server Type. The instructions for creating these Authentication Servers are not detailed here. Some of them are detailed at the Authentication – Citrix ADC 13 procedures.
    
• Or in the left menu, you can find all of the Action types under Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Actions.
  
• Or when creating an Authentication Policy, there’s a Add button that lets you create Authentication Actions/Servers.
  

LDAP Group Extraction

Sometimes you need to extract a user’s groups from Active Directory without authenticating. These extracted groups can then be used to select the next authentication Factor.

To configure an LDAP Action/Server for only group extraction:

1. When creating or editing an LDAP Server/Action for only group extraction, make sure Authentication is unchecked.
   
2. On the left, in the Other Settings section, make sure Group Attribute and Sub Attribute Name are filled in.
   

Create Authentication Policies

Once you’ve created your Authentication Actions, you can now create an Advanced Authentication Policy that links an expression to the Action:

1. Go to Security > AAA > Policies > Authentication > Advanced Policies > Policy.
   
2. On the right, click Add.
   
3. Name your Authentication Policy.
4. Use the Action Type drop-down to select the Action Type (e.g. LDAP). Typically each Factor is a different type of Authentication Action.
   
   1. If you don’t want to perform authentication, then select NO_AUTHN as the Action Type. This is useful if you only want to use this Authentication Policy expression to choose a Next Factor.
      
5. If you don’t currently have any Actions configured, or if you want to create a new one, click the Add button next to the Action drop-down. The Actions/Servers are created in the normal fashion (not detailed here).
   
6. In the Expression box, enter an expression using the Default Syntax. ns_true won’t work because that’s Classic syntax. There’s an Expression Editor link on the right. Or hit Ctrl+Space to see your options. true is a valid Default expression.
7. Click Create when done.
   
8. Continue creating one or more Authentication Policies for each of your Factors.

Bind First Factor to AAA

For all factors except the first factor, the Authentication Policies are bound to Authentication Policy Labels as detailed in the next section.

However, since the first factor doesn’t use a Policy Label, you instead bind the first factor’s Authentication Policies directly to the AAA vServer.

1. Go to Security > AAA > Virtual Servers.
2. Edit an existing AAA Virtual Server.
   
3. On the left, in the Advanced Authentication Policies section, click where it says No Authentication Policy.
   
4. In the Policy Binding page, click where it says Click to select.
   
5. Click the radio button next to the first factor’s Advanced Authentication Policy, and then click the blue Select button at the top of the page. Only Advanced Authentication Policies appear in this list. Classic Authentication Policies do not appear.
   
6. In the Binding Details section, if this Advanced Authentication Policy fails, then the Goto Expression determines what happens next. If it is set to NEXT, then the next Advanced Authentication Policy bound to this AAA Virtual Server is evaluated. If it is set to END, or if there are no more Advanced Authentication Policies bound to this AAA Virtual Server, then authentication is finished and marked as failed.
   
7. The Select Next Factor field can optionally point to an Authentication Policy Label as detailed in the next section. The Next Factor is only evaluated if this Advanced Authentication Policy succeeds. You can bind a Policy Label later since you probably don’t have any yet.
   
8. Click Bind.
   
9. You can optionally bind more Authentication Policies and they will be evaluated in priority order. If one of the Authentication Policies succeeds, then nFactor moves to the Next Factor and the remaining Authentication Policies in this factor are ignored.

Authentication Policy Label

For all factors except for the first factor, you create a Policy Label for each factor, and then bind the Policy Labels to the various Next Factor authentication policy bind points in the nFactor flow.

Authentication Policy Labels contain two objects:

• Login Schema
• Advanced Authentication Policies

The Authentication Policies can have a Next Factor link to a different Policy Label. Factors are chained together through the Next Factor links.

Here’s the nFactor authentication flow:

1. User connects to a AAA or Citrix Gateway Virtual Server.
   1. Citrix Gateway uses an Authentication Profile to select a AAA vServer than has a nFactor configuration.
2. The Login Schema bound to the AAA Virtual Server is displayed to the user.
3. Advanced Authentication Policies bound to the AAA Virtual Server are evaluated.
   1. If the Advanced Authentication Policy succeeds, go to the configured Next Factor, which is an Authentication Policy Label.
      1. If Next Factor is not configured, then authentication is complete and successful.
   2. If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
   3. If none of the Advanced Authentication Policies succeed, then authentication failed.
4. If the Next Factor Authentication Policy Label has a Login Schema bound to it, display it to the user.
5. Evaluate the Advanced Authentication Policies bound to the Next Factor Authentication Policy Label.
   1. If the Advanced Authentication Policy succeeds, go to the configured Next Factor, which is an Authentication Policy Label.
      1. If Next Factor is not configured, then authentication is complete and successful.
   2. If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
   3. If none of the Advanced Authentication Policies succeeds, then authentication failed.
6. Continue evaluating the Next Factor Authentication Policy Label until authentication succeeds or fails. You can chain together an unlimited number of Authentication Policy Labels.

When binding a Login Schema to an Authentication Policy Label, you only need the Login Schema Profile. There’s no need to create a Login Schema Policy.

Not every Factor needs a Login Schema. It’s possible for a prior Factor to gather all of the credential information and simply pass it on to the next Factor. If you don’t need a Login Schema for a particular Authentication Policy Label, simply select LSCHEMA_INT, which is mapped to noschema. Or create a new Login Schema Profile based on noschema.

Create Authentication Policy Label

To create an Authentication Policy Label:

1. Authentication Policy Labels (Factors) are configured at Security > AAA > Policies > Authentication > Advanced Policies > Policy Label.
   
2. On the right, click Add.
   
3. Give the Policy Label a name which identifies this factor.
4. Select a Login Schema Profile or click the Add button to create one.
   • If you don’t want this factor to display anything to the user, then select LSCHEMA_INT.
5. Click Continue. Note: you won’t be able to change the Login Schema later. But you can create a new Policy Label with a different Login Schema.
   
6. In the Policy Binding section, click where it says Click to select.
   
7. Click the radio button next to an Advanced Authentication Policy that evaluates this Factor and then click the blue Select button at the top of the page.
   
8. Use the Goto Expression drop-down to select NEXT or END. If you want to bind more Advanced Authentication Policies to this Factor, then select NEXT.
   
9. In the Select Next Factor field, if you want to chain to another Factor, click where it says Click to select, and bind the next Authentication Policy Label (Next Factor).
   
   • If you haven’t created the Policy Label for the next factor yet, you can either do it now by clicking the Add button, or return here later after you create the next Policy Label.
   • If you don’t configure a Next Factor, and if this Advanced Authentication Action succeeds, then authentication is successful and complete.
10. Click Bind when done.
    
11. You can optionally click Add Binding to add more Advanced Authentication Policies to this Policy Label (Factor). If any one of the Authentication Policies succeeds, then nFactor moves to the Next Factor and ignores the remaining Authentication Policies in this factor.
    
12. When done, click Done.
    
13. If you edit the Policy Label you created, notice that it’s not possible to change the Login Schema. The only way to change the Login Schema is to create a new Policy Label.
    

Bind Authentication Policy Label to Next Factor

Once the Policy Label (Factor) is created, you link to it from an existing Authentication Policy binding. You can select a Next Factor (Policy Label) in two places:

• Edit an existing AAA Virtual Server that has an Authentication Policy (first factor) already bound to it and edit the binding to include the Next Factor.
• Edit a different Policy Label, and edit an Advanced Authentication Policy binding to include the Next Factor.

To link to a Policy Label Next Factor from a AAA Virtual Server first factor:

1. Edit an existing AAA Virtual Server that has an Advanced Authentication Policy already bound to it.
   
2. On the left, in the Advanced Authentication Policies section, click the existing Authentication Policy bindings.
   
3. Right-click an existing binding, and click Edit Binding.
   
4. In the Select Next Factor field, click where it says Click to select.
   
5. Click the radio button next to the Policy Label for the Next Factor, and then click the blue Select button at the top of the page.
   
6. Click Bind.
   
7. In the list of bound Authentication Policies, the far right shows the Next Factor.
   
8. Click Close.
   

To link to a Policy Label Next Factor from a different Policy Label:

1. Go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy Label.
2. On the right, edit a different Policy Label.
   
3. Right-click an existing Authentication Policy binding and click Edit Binding.
   
4. In the Binding Details section, next to Select Next Factor, click Click to select.
   
5. Click the radio button next to a Policy Label for the next factor, and then click the blue Select button at the top of the window.
   
6. Click Bind.
   
7. In the list of bound Authentication Policies, on the far right, you can see the configured Next Factor.
   
8. Click Done to close the Policy Label.
   
9. Repeat linking Policy Labels (Factors) together until your nFactor flow configuration is complete.

nFactor Flow Visualizer

ADC 13 and newer have a nFactor Flow Visualizer that you can use to create flows like this:

Find the Visualizer under Security > AAA – Application Traffic > nFactor Visualizer > nFactor Flows

For an example usage of this tool, see Native One Time Passwords (OTP) – Citrix Gateway 13.

Here are some differences for the Visualizer method vs the manual method detailed in this article:

• Manual: First factor without Policy Label – With the manual method, the first factor is bound to the AAA vServer without using a Policy Label.
  • Visualizer: First Factor is a Policy Label – The Visualizer creates a Policy Label for the first factor. Then it binds the Policy Label to the AAA vServer.
• Manual: Login Schema Policies for First Factor – With the manual method, you create Login Schema Policies to bind the first factor’s Login Schema to the AAA vServer. Login Schema Policies have expressions that are evaluated to determine if the Login Schema should be shown or not. This lets you bind multiple Login Schemas to the AAA vServer and a policy expression determines which Login Schema is shown to the user.
  • Visualizer: no Login Schema Policies – The Visualizer does not support Login Schema Policies and thus the Login Schema configured for a Factor is always shown.

For more information, see nFactor Visualizer for simplified configuration at Citrix Docs.

nFactor for Citrix Gateway

All nFactor configuration is performed in the menu under Security > AAA – Application Traffic. When done, your nFactor Flow should be bound to a AAA vServer.

To enable nFactor for a Citrix Gateway Virtual Server, you simply create an Authentication Profile and bind it to the Gateway Virtual Server. If you unbind the Authentication Profile from the Gateway Virtual Server, then nFactor is no longer used by that Gateway.

AAA Authentication Profile

Authentication Profile links a AAA Virtual Server to Citrix Gateway and enables nFactor on Citrix Gateway.

1. Go to Citrix Gateway > Virtual Servers.
   
2. On the right, edit an existing Citrix Gateway Virtual Server.
   
3. On the right, in the Advanced Settings column, click Authentication Profile.
   
4. On the bottom left, click the Add button next to the Authentication Profile drop-down.
   
5. Give the Authentication Profile a name.
6. In the Authentication Virtual Server field, click where it says Click to select.
   
7. Click the radio button next to the AAA Virtual Server that has nFactor configured. The AAA Virtual Server does not need an IP address. Then click the blue Select button at the top of the page.
   
8. Then click Create.
   
9. And click OK to close the Authentication Profile section. The Authentication Profile isn’t enabled until you click this OK button.
   
10. Note: the Authentication Profile enables nFactor, which overrides any authentication policies that are bound to the Gateway Virtual Server.
11. If one of your Factors is client certificates, then you’ll need to configure SSL Parameters and CA certificate as detailed in the next section.
12. When you browse to your Gateway, you’ll see the Login Schema that is bound to the AAA Virtual Server.
    
13. Workspace app 1809 and newer with Gateway/ADC 12.1 build 49 and newer should support nFactor authentication. Older clients with older builds do not support nFactor, so those users will have to use a web browser.

Gateway and Client Certificate Authentication

If one of your authentication Factors is certificate, then you must perform some SSL configuration on the Citrix Gateway Virtual Server:

1. Go to Traffic Management > SSL > Certificates > CA Certificates, and install the root certificate for the issuer of the client certificates. Certificate Authority certificates do not need key files.
   
2. If default SSL Profiles are enabled, then you should have already created an SSL Profile that has Client Authentication enabled.
3. Go to Citrix Gateway > Virtual Servers, and edit an existing Citrix Gateway Virtual Server that is enabled for nFactor.
   
4. If default SSL Profiles are enabled:
   1. Scroll down to the SSL Profile section, and click the pencil icon.
      
   2. In the SSL Profile drop-down, select the SSL Profile that has Client Authentication enabled and set to OPTIONAL. Then click OK.
      
5. If default SSL Profiles are not enabled:
   1. On the left, in the SSL Parameters section, click the pencil icon.
      
   2. Check the box next to Client Authentication.
   3. Make sure Client Certificate drop-down is set to Optional, and click OK.
      
6. For both Default SSL Profile and SSL Parameters, on the left, in the Certificates section, click where it says No CA Certificate.
   
7. In the CA Certificate Binding page, click where it says Click to select.
   
8. Click the radio button next to the root certificate for the issuer of the client certificates, and click the blue Select button at the top of the page.
   
9. Click Bind.
   
10. You might have to also bind any Intermediate CA Certificates that issued the client certificates.

Traffic Policy for nFactor Single Sign-on to StoreFront

When performing Single Sign-on to StoreFront, nFactor defaults to using the last entered password. If LDAP is not the last entered password (e.g. RADIUS), then you need to create a Traffic Policy/Profile to override the default nFactor behavior.

1. Go to Citrix Gateway > Policies > Traffic.
   
2. On the right, switch to the tab named Traffic Profiles.
3. Click Add.
   
   1. Give the Traffic Profile a name.
   2. In the Protocol section, select HTTP.
   3. Set the Single Sign-on drop-down to ON. Scroll down.
      
   4. In the SSO Expression fields, enter an AAA.USER.ATTRIBUTE(#) expression that matches the indexes specified in the Login Schema.
   5. Click Create.
      
4. On the right, switch to the tab named Traffic Policies, and click Add.
   
   1. Give the policy a name.
   2. Select the previously created Traffic Profile.
   3. Enter an Advanced Expression (e.g. true), and click Create.
      
5. Edit an existing Citrix Gateway Virtual Server.
   
6. Scroll down to the Policies section and click the plus icon.
   
7. In the Choose Type page, select Traffic > Request, and click Continue.
   
8. Select the previously created Traffic Policy, and click Bind.
   

Sample Configurations

From Citrix Docs: Sample deployments using nFactor authentication:

• Get two passwords up-front, then pass-through the second password to the next factor. Read
• Username and 2 passwords, then group extraction in third factor. Read
• Configure nFactor to process the second password before the first password, Read
  
• Modify first factor username for use by second factor. Read
  • NO_AUTHN authentication policy expression checks first factor POST Body login value for UPN format. If true, Next Factor is noschema Login Schema with User Expression that transforms the HTTP.REQ.USER.NAME to DOMAIN\Username before passing to second factor authentication policy.
• Group extraction followed by certificate or LDAP authentication, based on group membership. Read
  
  
• SAML followed by LDAP or certificate authentication, based on attributes extracted during SAML. Read
  
• SAML in first factor, followed by group extraction, and then LDAP or certificate authentication, based on groups extracted. Read
• Capture email address in first factor, and then choose one of multiple SAML iDP based on email address suffix. Read (Manuel Kolloff)
  
  
• Prefill user name from certificate. Read
• Certificate authentication followed by group extraction for 401 enabled traffic management virtual servers. Read
  
• Certificate fallback to LDAP in same cascade; one virtual server for both certificate and LDAP authentication. Read
• LDAP in first factor and WebAuth in second factor. Read
• WebAuth in first factor, LDAP in second factor. Read
  
• Domain drop down in first factor, then different policy evaluations based on selected domain. Read
  
  • Domain drop-down, then send Domain\Username to RADIUS.  Read
• ADC 13 has a CAPTCHA authentication action instead of WEBAUTH as described in the following reCAPTCHA guides. (source = Graham Constantine in the comments) 💡
  
  • Google reCAPTCHA first factor, LDAP second. Read (George Spiers).
    
  • Supporting reCaptcha with Citrix ADC nFactor. Read
    
• CTX225938 nFactor – Customizing UI to Display Images – e.g. Swivel
  
• Use EPA (Endpoint Analysis) in nFactor flows . See CTX223597 Concepts and Entities Used for EPA in nFactor Authentication Through NetScaler.
  • CTX231362 How to Configure Pre-Auth and Post-Auth EPA scan as a factor in nFactor authentication
• Configure Post-Authentication EPA (Endpoint Analysis) Scan as a Factor. Read
  
• Configure Pre-Authentication EPA (Endpoint Analysis) Scan as a Factor. Read
  
• Configure EPA domain check combined with Smartaccess feature.  Read
  
• Configure EULA (End User License Agreement) as an Authentication Factor. Read
  
• Show a drop-down box in the logon form and automatically hide or show certain fields based on drop-down selection. Read
  
  
• Step-up authentication – i.e. one Unified Gateway website needs single factor, while other website needs multi-factor. Read
  
• RADIUS authentication with reversed PIN – if user enters reversed PIN, then user is under duress. This sample configuration has some interesting components:  Read
  • Policy Extension Function using the Lua language
    • Usage = HTTP.REQ.BODY(1000).TYPECAST_NVLIST_T(’=’,’&’).VALUE(”passwd1”).RPIN
  • Citrix ADC Variable of type Map with Expiration timer
    • Responder to set the variable
    • Variable identifies duress state for four hours
  • Custom syslog message (audit messageaction) triggered by a Responder
  • Default Authentication Group to put duressed user on site/farm with Session Recording enabled
  • nFactor sequence:
    
• nFactor Extensibility at Citrix Docs explains how to use JavaScript to add custom login labels, add custom login credentials, customizing UI displays and so on.
  

Certificate auth: If Successful, LDAP only. If Failure, LDAP+RADIUS

This scenario is described in Citrix Blog Post Configuration Notes on nFactor

The authentication process flows like this:

1. User connects to Citrix Gateway.
2. Citrix Gateway asks user for certificate.
3. If user selects a certificate, Citrix Gateway compares certificate signature to the CA certificate that is bound to the Citrix Gateway. If it doesn’t match, then user certificate is ignored.
4. Bound to the Citrix Gateway Virtual Server is an Authentication Profile, which links Citrix Gateway to AAA nFactor.
5. Certificate authentication: The lowest priority number authentication policy on the AAA Virtual Server is Certificate. If there’s a valid user certificate:
   1. Extract the user’s userPrincipalName from the certificate.
   2. Next Factor = policy label that displays a logon screen (Single-factor Login Schema)
   3. The username field is pre-populated with the userPrincipalName attribute extracted from the certificate.
   4. User is prompted to enter the LDAP password only.
   5. LDAP policy/server is configured to use userPrincipalName to login to LDAP.
   6. If successful, Citrix Gateway authentication is complete. Next step is to Single Sign-on to StoreFront.
   7. If LDAP authentication fails, then Citrix Gateway authentication fails, and the user is prompted to try LDAP-only authentication again.
6. LDAP authentication: If certificate authentication fails, try next authentication policy bound to the AAA Virtual Server, which is a different LDAP Policy.
   1. Bound to the AAA Virtual Server is a Dual Factor Login Schema that asks for username, LDAP password, and RADIUS password.
   2. LDAP policy/server is configured to use sAMAccountName to login to LDAP. SAMAccountName means users don’t have to enter full userPrincipalName.
   3. If LDAP authentication is successful:
      2. Put username in Credential Index 1 and put password in Credential Index 2. These will later be used by a Traffic Policy to Single Sign-on to StoreFront.
      3. Proceed to next factor (Policy Label), which is RADIUS.
   4. If LDAP authentication fails, Citrix Gateway login fails, and the user is prompted to try two-factor authentication again.
7. RADIUS authentication: the second factor Policy Label is configured with Noschema. This means no additional logon form is displayed because the RADIUS password was already collected in the previous factor.
   1. When multiple passwords are collected, they are tried in order. The first password was used by the previous factor. The second password is tried by this factor (Policy Label).
   2. RADIUS policy/profile attempts authentication.
   3. If RADIUS authentication is successful, Citrix Gateway authentication is complete. Next step is Single Sign-on to StoreFront.
   4. If RADIUS authentication fails, Citrix Gateway login fails, and the user is prompted to try two-factor authentication again.
8. Single Sign-on to StoreFront: Citrix Gateway uses the last password collected by nFactor to Single Sign-on with StoreFront. If the last password is LDAP, then no additional configuration is needed. If the last password is not LDAP, then a Traffic Policy/Profile is needed.
   1. Bound to the Citrix Gateway Virtual Server is a Traffic Policy.
   2. The Traffic Policy/Profile users Credential Index 1 for username and Credential Index 2 for Password. These are the same indexes configured in the Dual Factor Login Schema.

The order of configuration shown below doesn’t match the authentication flow because some objects have to be created before others. This is the bottom-up approach.

# Create Auth vServer, bind server cert, bind CA cert for client certificates
# Enable Optional client certificates
add authentication vserver nFactorAAA SSL 0.0.0.0 443
bind ssl vserver nFactorAAA -certkeyName WildCorpCom
bind ssl vserver nFactorAAA -certkeyName CorpRoot -CA -ocspCheck Optional
set ssl vserver nFactorAAA -clientAuth ENABLED -clientCert Optional -ssl3 DISABLED

# Create auth policy for LDAP-UPN. UPN is extracted from certificate.
add authentication ldapAction Corp-UserPrincipalName -serverIP 10.2.2.220 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword "MyPassword" -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
add authentication Policy Corp-UserPrincipalName -rule true -action Corp-UserPrincipalName

# Create PolicyLabel LDAPPasswordOnly with Single-factor Login Schema
# Login Schema has InitialValue with username from certificate.
add authentication loginSchema SingleAuth -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuth-Corp.xml"
add authentication policylabel LDAPPasswordOnly -loginSchema SingleAuth
bind authentication policylabel LDAPPasswordOnly -policyName Corp-UserPrincipalName -priority 100 -gotoPriorityExpression NEXT

# Create Cert policy and bind to AAA vServer with LDAPPasswordOnly PolicyLabel as Next Factor
# Cert policy must have lower priority number (higher priority) than LDAP-SAM policy
# Cert is evaluated first. If succeed, ask for LDAP password. If fails, ask for two factor.
add authentication certAction Cert_Auth_Profile -userNameField SubjectAltName:PrincipalName
add authentication Policy Cert_Auth_Policy -rule true -action Cert_Auth_Profile
bind authentication vserver nFactorAAA -policy Cert_Auth_Policy -priority 100 -nextFactor LDAPPasswordOnly -gotoPriorityExpression NEXT

# Create LDAP-SAM Auth Policy for two-factor
# Only evaluated if cert auth fails. Login Schema asks for user, password, and passcode.
add authentication ldapAction Corp-Gateway -serverIP 10.2.2.220 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword "MyPassword" -ldapLoginName samaccountname -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
add authentication Policy Corp-SAMAccountName -rule true -action Corp-Gateway

# Create RADIUS Auth Policy for two-factor
add authentication radiusAction RADIUS-Action -serverIP 10.2.2.42 -serverPort 1812 -radKey MyKey
add authentication Policy RADIUS-Policy -rule true -action RADIUS-Action

# Create Dual-factor Login Schema and bind directly to AAA vServer
# This Login Schema is only shown if Cert auth fails
add authentication loginSchema DualAuth -authenticationSchema "/nsconfig/loginschema/LoginSchema/DualAuth.xml" -userCredentialIndex 1 -passwordCredentialIndex 2
add authentication loginSchemaPolicy DualAuth -rule true -action DualAuth
bind authentication vserver nFactorAAA -policy DualAuth -priority 100 -gotoPriorityExpression END

# Create RADIUS Policy Label with noschema and RADIUS Auth Policy
# Already got passcode from previous factor so don't show Login Schema again
add authentication loginSchema Noschema -authenticationSchema noschema
add authentication policylabel NoSchema-RADIUS -loginSchema Noschema
bind authentication policylabel NoSchema-RADIUS -policyName RADIUS-Policy -priority 100 -gotoPriorityExpression NEXT

# Bind LDAP-SAM Auth Policy to AAA vServer with RADIUS as next factor
# LDAP-SAM Auth Policy must have higher priority number (lower priority) than Cert Policy
bind authentication vserver nFactorAAA -policy Corp-SAMAccountName -priority 110 -nextFactor NoSchema-RADIUS -gotoPriorityExpression NEXT

# Create Authentication Profile to link AAA with Gateway. Bind to Gateway.
add authentication authnProfile nFactor -authnVsName nFactorAAA -AuthenticationHost aaa.corp.com
add vpn vserver gateway.corp.com SSL 10.2.2.220 443 -icaOnly ON -dtls ON -Listenpolicy NONE -tcpProfileName nstcp_default_XA_XD_profile -appflowLog ENABLED -authnProfile nFactor

# Enable Optional Client certs on Gateway
set ssl vserver gateway.corp.com -clientAuth ENABLED -clientCert Optional -ssl3 DISABLED
bind ssl vserver gateway.corp.com -certkeyName CorpRoot -CA -ocspCheck Optional

# Create Traffic Policy to SSON to StoreFront. Bind to Gateway.
add vpn trafficAction nFactorSSO http -kcdAccount NONE -userExpression "http.req.user.attribute(1)" -passwdExpression "http.req.user.attribute(2)"
add vpn trafficPolicy nFactorSSO ns_true nFactorSSO
bind vpn vserver gateway.corp.com -policy nFactorSSO -priority 100

Group Extraction, followed by LDAP (Active Directory), or Azure MFA (NPS)

Also see Mark DePalma Running RSA SecurID/Azure MFA side-by-side using an AD group on NetScaler Gateway 💡

Azure MFA is available as a plug-in for Microsoft Network Policy Server (NPS), which is a Microsoft RADIUS server and a built-in Windows Server Role.

NPS performs both AD authentication and Azure MFA authentication. Citrix Gateway sends the user’s AD password to NPS. NPS verifies AD, and then the NPS Azure MFA plug-in calls the user (or push notification to the user). If both AD and MFA are successful, then NPS sends back RADIUS-Accept.

This sample nFactor configuration will first ask for username only. Depending on the user’s group membership and client IP address, nFactor will either perform RADIUS NPS authentication (multi-factor), or nFactor will do LDAP only (single-factor).

Summary:

1. First factor Login Schema asks for Username only.
   1. LDAP Group Extraction (with Authentication disabled) reads the user’s groups from AD.
2. Second factor checks for group membership and sends to one of two different third factors.
3. If user is in LDAP Group, or Client IP is on internal network, then perform LDAP-only authentication.
   1. Login schema asks for AD password.
   2. LDAP Policy authenticates with LDAP Server (Active Directory).
4. Otherwise, perform RADIUS (two-factor) authentication.
   1. Login schema asks for AD password.
      • Note: NPS with MFA plugin only needs the AD password. Alternatively, you could use a Login Schema that asks for both LDAP password and RADIUS password.
   2. RADIUS Policy uses the entered AD password to authenticate to Microsoft NPS and Azure MFA.

CLI Commands. Note, these objects are created in the required order, which is backwards from how you would want to configure them.

1. Add cert for AAA vServer. Link the cert to Intermediate.

   add ssl certKey WildcardCorpCom -cert WildcardCorpCom.pfx -key WildcardCorpCom.pfx -inform PFX -passcrypt "myPassword"
   
   link ssl certKey WildcardCorpCom Intermediate

2. Enable AAA feature if not already enabled.

   enable ns feature AAA

3. Create first factor LDAP Action (LDAP Server) and LDAP Policy (expression) for Group Extraction. Authentication is disabled. This is the first factor that is bound directly to the AAA vServer.

   add authentication ldapAction LDAP-Corp-GroupExtract -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn ctxsvc@corp.local -ldapBindDnPassword MyPassword -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED
   
   add authentication Policy LDAP-Corp-GroupExtract -rule true -action LDAP-Corp-GroupExtract

4. Create a third-factor LDAP Action (LDAP Server) and Authentication Policy (expression) for Active Directory Authentication. This is the authentication factor if user is in the LDAP Users group.

   add authentication ldapAction LDAP-Corp -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn ctxsvc@corp.local -ldapBindDnPassword MyPassword -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -passwdChange ENABLED
   
   add authentication Policy LDAP-Corp -rule true -action LDAP-Corp

5. Create a third-factor RADIUS Action (RADIUS Server) and Authentication Policy (expression) for NPS.

   add authentication radiusAction NPS -serverIP 10.2.2.42 -serverPort 1812 -radKey MySecret
   
   add authentication Policy NPS -rule true -action NPS

6. Create the second factor NO_AUTHN authentication policies to determine the next factor based on the user’s group membership. NO_AUTHN means don’t authenticate. Instead, these policies will have a Next Factor that points to the Authentication Policies that we created earlier. If the policy expression is true, then go to Next Factor. Next Factor is configured later when binding these policies to the second factor PolicyLabel. Note: the group name is case sensitive and must match the Active Directory group name.

   add authentication Policy LDAP-Only -rule "http.REQ.USER.IS_MEMBER_OF(\"LDAP\") || client.IP.SRC.IN_SUBNET(10.2.2.0/24)" -action NO_AUTHN
   
   add authentication Policy TwoFactor -rule "client.IP.SRC.IN_SUBNET(10.2.2.0/24).NOT" -action NO_AUTHN

7. Create first factor Login Schema Profile for username-only group extraction. You can copy the built-in OnlyUsername.xml and modify it with your desired labels. Since this Login Schema Profile is bound to the AAA vServer, it needs a Login Schema Policy (expression). The other two Login Schema Profiles are bound to PolicyLabels and thus don’t need Login Schema Policies.

   add authentication loginSchema OnlyUsername -authenticationSchema "/nsconfig/loginschema/LoginSchema/OnlyUsername.xml"
   
   add authentication loginSchemaPolicy OnlyUsername -rule true -action OnlyUsername

8. Create third factor Login Schema Profile for AD Authentication. The .xml file is copied from the built-in PrefillUserFromExpr.xml but with modified labels for AD authentication. The username is pre-filled in from the first factor.

   add authentication loginSchema LDAPPasswordOnly -authenticationSchema "/nsconfig/loginschema/LDAPPassword.xml"

9. Create third factor Login Schema Profile for NPS Authentication. The .xml file is copied from the built-in PrefillUserFromExpr.xml but with modified labels for NPS authentication. The username is pre-filled in from the first factor.

   add authentication loginSchema NPSPasswordOnly -authenticationSchema "/nsconfig/loginschema/NPSPassword.xml"

10. Create third factor PolicyLabel for Active Directory authentication with Active Directory Login Schema and Active Directory Authentication Policy.

    add authentication policylabel LDAPPasswordAuth -loginSchema LDAPPasswordOnly
    
    bind authentication policylabel LDAPPasswordAuth -policyName LDAP-Corp -priority 100 -gotoPriorityExpression NEXT

11. Create third factor PolicyLabel for NPS authentication with NPS Login Schema and NPS Authentication Policy.

    add authentication policylabel NPSPasswordAuth -loginSchema NPSPasswordOnly
    
    bind authentication policylabel NPSPasswordAuth -policyName NPS -priority 100 -gotoPriorityExpression NEXT

12. Create second factor PolicyLabel with Policies that choose Next Factor. This PolicyLabel is processed before the two we just created.

    add authentication policylabel CheckForAuthType -loginSchema LSCHEMA_INT
    
    bind authentication policylabel CheckForAuthType -policyName TwoFactor -priority 90 -gotoPriorityExpression NEXT -nextFactor NPSPasswordAuth
    
    bind authentication policylabel CheckForAuthType -policyName LDAP-Only -priority 100 -gotoPriorityExpression NEXT -nextFactor LDAPPasswordAuth

13. Create AAA vServer. Bind Login Schema Policy (username only) and Group Extraction Policy.

    add authentication vserver AAA SSL 10.x.x.218 443
    bind authentication vserver AAA -policy OnlyUsername -priority 100 -gotoPriorityExpression END
    bind authentication vserver AAA -policy LDAP-Corp-GroupExtract -priority 100 -nextFactor CheckForAuthType -gotoPriorityExpression NEXT

14. Perform additional steps not detailed here:
    1. For Traffic Management:
       1. Create a Session Policy and bind it to the AAA vServer.
       2. Enable authentication on the Load Balancing or Content Switching vServer.
    2. For Citrix Gateway, create an Authentication Profile, and bind it to the Gateway vServer.

Navigation

• Change Log
• Overview
  • Citrix ADC Configuration Objects for OTP
• OTP Encryption
• AAA vServer
• Push Service
• LDAP Policies/Actions
• nFactor Visualizer
  • First Factor to select Manage or Authenticate
  • Second Factor for LDAP before manageotp
  • Third Factor for manageotp
  • Second Factor for LDAP before OTP Authentication
  • Third Factor for OTP Authentication
  • Bind nFactor Flow to AAA vServer
• Number of Registered OTP Devices
• Traffic Policy for Single Sign-on
• Citrix Gateway and Authentication Profile
• Update Content Switching Expression for Unified Gateway
• Manageotp User Experience
• OTP Authentication User Experience
• CLI Commands

Change Log

• 2023 Mar 17 – added link to CTP Julian Jakob Citrix NetScaler – OTP Encryption Tool.
• 2021 Feb 1 – First factor – added info from Samuel LEGRAND Native OTP issues on Citrix ADC 13
• 2020 Apr 12 – Overview – added link to Andreas Nick OTPEdit: tool to register OTP devices without using manageotp
• 2019 Sep 27 – OTP Encryption – new in ADC 13.0 build 41
• New OTP features in ADC 13:
  • Push Notifications
  • nFactor Visualizer
  • Maximum number of registered devices per user

Overview

Citrix ADC 13 Native OTP lets you enable two-factor authentication without purchasing any other authentication product. A typical configuration uses Citrix SSO app (mobile VPN Client) to receive push notifications, or Google Authenticator to generate Passcodes. See the following for an overview:

• Citrix Blog Post NetScaler Unified Gateway Provides One Time Password (OTP), Natively
• Citrix CTX228454 NetScaler One Time Password (OTP) Guide for Dual Authentication or Registration

Here are some notes and requirements for Native OTP:

• Licensing – Citrix ADC Native OTP is part of nFactor, and thus requires Citrix ADC Advanced Edition or Citrix ADC Premium Edition licensing. Citrix ADC Standard Edition licensing is not sufficient.
  • OTP Push Notifications require ADC Premium Edition
• Workspace app 1809 and newer with Citrix Gateway 12.1 build 49 and newer support nFactor authentication. Older Receivers and older NetScalers don’t support nFactor with Receiver, so you’ll instead have to use a web browser.
  
  
• Citrix Gateway VPN Plug-in 12.1 build 49 and later support nFactor when authenticating from the VPN Plug-in.
  
  
• Push notifications – Citrix ADC 13 and newer supports OTP push notifications of logon request to the mobile (iOS, Android) Citrix SSO app. Other authenticator apps are not supported for OTP Push, but they can be used with OTP Passcode.
  
• Authenticator – If not using Citrix SSO app, then Google Authenticator can generate passcodes. Christian in the comments indicated that Microsoft Authenticator also works. Click on plus sign -> other (Google,…).
• Internet for Push – Push notifications requires the Citrix ADC appliance to be able to send API calls across the Internet to Citrix Cloud.
• Active Directory attribute – Citrix ADC stores OTP device enrollment secrets in an string-based Active Directory attribute. Citrix’s documentation uses the userParameters Active Directory attribute.
  • The LDAP bind account must have permission to modify this attribute on every user.
  • The userParameters attribute must not be populated. Active Directory Users & Computers might set the userParameters attribute if you modify any of the RDS property pages.
• Enroll multiple devices – Citrix ADC 13 and newer lets you control the number of devices that a user can enroll.
• Manageotp is difficult to secure – The manageotp website is usually only protected by single factor authentication so external access must be blocked.
  • Andreas Nick OTPEdit is an out-of-band tool to register OTP devices without using manageotp.
    

Notes on Citrix ADC Configuration Objects for OTP

Here are some notes on the Citrix ADC OTP configuration objects. Detailed instructions are provided later.

• Make sure NTP is configured on the Citrix ADC. Accurate time is required.
• AAA vServer – nFactor requires a AAA vServer, which can be non-addressable. You don’t need any additional public IP for OTP.
  • An Authentication Profile links the AAA vServer to the Citrix Gateway vServer.
• Citrix Cloud – For Push notifications, create a Citrix Cloud account. No Citrix Cloud licensing needed. Citrix ADC uses Cloud API credentials to authenticate with Citrix Cloud.
• NSC_TASS cookie – To access the manageotp web page, users add /manageotp to the end of the Gateway URL. Citrix ADC puts this URL path into a cookie called NSC_TASS. You can use this cookie and its value in policy expressions for determining which Login Schema is shown to the user.
• Login Schema for manageotp – The built-in Login Schema file named SingleAuthManageOTP.xml has hidden fields that enable the manageotp web page. If the Login Schema Policy expression permits the SingleAuthManageOTP.xml Login Schema to be shown to the user, then after authentication the user will be taken to the manageotp web page.
  
  • LDAP authentication is expected to be bound to the same factor as this SingleAuthManageOTP login schema.
  • The next factor is a LDAP Policy/Server with authentication disabled (unchecked) but with arguments specifying the Active Directory attribute for the OTP Secret and Push Service configuration.
    
    
• Login Schema for OTP authentication – The built-in Login Schema file named DualAuthPushOrOTP.xml performs the two-factor authentication utilizing the push service. There’s a checkbox that lets users choose Passcode instead of Push. This login schema has a Credential called otppush.
  
  
  • If you prefer to not use Push, then you can use a normal DualAuth.xml Login Schema file since for passcode authentication there are no special Login Schema requirements other than collecting two password fields.
  • Both methods expect an authenticating LDAP Policy/Server to be bound to the same Factor as the Login Schema.
  • The next factor should be a non-authenticating LDAP Policy/Server that optionally has the the Push Service defined and must have the OTP Secret attribute defined.
• Single Sign-on to StoreFront – The OTP dual authentication Login Schema essentially collects two passwords (AD password plus push, or AD password plus passcode). Later, Citrix Gateway needs to use the AD password to perform Single Sign-on to StoreFront. To ensure the AD password is used instead of the OTP passcode, configure the OTP dual authentication Login Schema to store the AD password in a AAA attribute and then use a Citrix Gateway Traffic Policy/Profile to utilize the AAA attribute during Single Sign-on to StoreFront.
• nFactor Visualizer – Citrix ADC 13 has a nFactor Visualizer to simplify the OTP configuration. Or you can manually create the LDAP Policies/Actions, the Login Schema Policies/Profiles, the PolicyLabels, and then bind them to a AAA vServer.

OTP Encryption

ADC 13.0 build 41 and newer let you encrypt the OTP secrets stored in Active Directory.

ADC uses a certificate to encrypt the contents of the Attribute. It currently is not possible to configure the certificate from the GUI, so you’ll need to SSH to the ADC and run the following command:

bind vpn global -userDataEncryptionKey MyCertificate

To enable OTP attribute encryption:

1. In the ADC menu, go to Security > AAA – Application Traffic.
2. On the right, click Change authentication AAA OTP Parameter.
   
3. Check the box for OTP Secret encryption and then click OK.
   
4. If you have a previous implementation of ADC OTP that stored unencrypted OTP secrets, then use the Python OTP encryption tool at /var/netscaler/otptool/OTP_encryption_tool to encrypt the AD attribute using the userDataEncryptionKey certificate. The same tool can be used to change the encryption certificate. More details at OTP encryption tool at Citrix Docs. Also see CTP Julian Jakob Citrix NetScaler – OTP Encryption Tool.
   

AAA Virtual Server

Create a AAA vServer that is the anchor point for our OTP nFactor configuration.

1. Make sure the time is correct on the NetScaler. Click the Configuration tab to see the current System Time. Make sure NTP is configured at System > NTP Servers.
   
2. Go to Security > AAA – Application Traffic.
3. If the AAA feature is not enabled, then right-click the AAA node, and click Enable Feature.
   
4. Go to Security > AAA – Application Traffic > Virtual Servers.
5. On the right, click Add.
   
6. This AAA vServer is for OTP so name it accordingly.
7. Change the IP Address Type to Non Addressable. You don’t need to specify any additional IP address.
8. Click the blue OK button.
   
9. Click where it says No Server Certificate.
   
   1. In the Server Certificate Binding section, click Click to select.
      
   2. Click the radio button next to a certificate, and then click the blue Select button at the top of the page. You can select the same certificate as the Citrix Gateway Virtual Server.
      
   3. Click Bind.
      
10. Click Continue to close the Certificate section.
    
11. In the Advanced Authentication Policies section, don’t bind anything and just click Continue. We’ll bind a nFactor Flow later.
    
12. You can optionally improve the SSL ciphers on this AAA Virtual Server but it’s probably not necessary since this AAA vServer is not directly addressable.
13. Nothing else is needed at this time so click the blue back arrow on the top left.
    

Push Service

If your Citrix ADC has Internet access, then you can enable OTP Push Authentication. The ADC must be able to reach the following FQDNs:

• mfa.cloud.com
• trust.citrixworkspacesapi.net

Create an API Client at citrix.cloud.com:

1. Go to https://citrix.cloud.com and login. Your cloud account does not need any licensed services.
2. On the top left, click the hamburger (menu) icon, and then click Identity and Access Management.
   
3. Switch to the tab named API Access.
   
4. On this page, notice the Customer ID. You’ll need this value later.
5. Enter a name for a new API client and then click Create Client
   
6. Click Download to download the client credentials.
   

On ADC 13, create the Push Service:

1. In Citrix ADC 13 management GUI, navigate to the Push Service node. The easiest way to find it is to enter Push in the search box on the top left.
2. On the right, click Add.
   
3. In the Create Push Service page, do the following:
   1. Enter a name for the Push Service.
   2. Enter the Client ID and Client Secret that you downloaded when creating your API Client.
   3. Enter the Customer ID shown on the Create Client web page at cloud.com. Make sure there are no hidden characters or whitespace around the Customer ID.
4. Click Create.
   
5. On the top right, click the refresh icon until the Status changes to COMPLETE. If it won’t go past CCTOKEN, then make sure you entered the API Client info correctly, especially the Customer ID, which might have hidden characters around it.
   

LDAP Actions/Servers

Create three LDAP Actions (aka LDAP Servers):

• One LDAP Action for normal LDAP authentication against Active Directory
• One LDAP Action to set the OTP Active Directory attribute and register with push
• One LDAP Action to perform push authentication (in a dual-authentication flow)

Create normal LDAP Action

1. Go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Actions > LDAP.
2. On the right, click Add.
   
3. Create a normal LDAP Server if you don’t have one already. This one has Authentication enabled. There are no special instructions for this LDAP Server.
   

Create LDAP Action for OTP Device Registration

Create the LDAP Action for OTP device registration that sets the OTP Active Directory attribute and registers with push:

1. Create another LDAP Action.
   
2. Name it according to this goal: used by the manageotp web site to set the OTP authenticator in Active Directory.
3. On the right, uncheck the box next to Authentication.
   
4. Make sure the Administrator Bind DN has permissions to modify the OTP Secret Active Directory attribute for all users. A regular non-admin LDAP Bind account won’t work.
5. If you cloned an existing LDAP Server, then make sure you re-enter the Administrator Password or the new LDAP Action won’t work.
6. Click Test LDAP Reachability.
   
7. Configure the Server Logon Name Attribute to match the one you configured in the normal authentication LDAP Server.
   
8. In the Other Settings section, on the bottom right, find the OTP Secret field. Enter the name of the Active Directory attribute where Citrix ADC will store the user’s OTP secret. You can use the userParameters attribute if that attribute isn’t being used for anything else.
   • userParameters is populated by Active Directory Users & Computers if you set anything on the RDS tabs (e.g. RDS Roaming Profile).
9. Select the Push Service that you created earlier.
10. Click Create when done.

Create LDAP Action for OTP Authentication

Create a LDAP Action that performs OTP push authentication or verifies the OTP Passcode. The only difference from the prior LDAP Action is the addition of an LDAP Search Filter.

1. Create another LDAP Action.
2. Give the LDAP Action a name.
3. On the right, uncheck the box next to Authentication.
   
4. Make sure the Administrator Bind DN has permissions to read the OTP Secret Active Directory attribute.
5. If you cloned an existing LDAP Server, then make sure you re-enter the Administrator Password or the new LDAP Action won’t work.
6. Click Test LDAP Reachability.
   
7. In the Other Settings section, configure the Server Logon Name Attribute to match the one you configured in the normal authentication LDAP Server.
8. In the Search Filter field, enter the text userParameters>=#@. This syntax ensures that only users with enrolled authenticators can login. See George Spiers NetScaler native OTP for more info.
   
9. In the Other Settings section, on the bottom right, find the OTP Secret field. Enter the name of the Active Directory attribute containing the user’s OTP secret.
10. In the Push Service drop-down, select the Push Service that you already created.
11. Click Create when done.

nFactor Visualizer

We will build a nFactor Flow that looks something like this:

• First factor on the left chooses either OTP Device Registration or OTP Authentication. If user enters /manageotp, then nFactor Flow takes the top path. Otherwise, nFactor flow takes the bottom path.
  • Login Schema is not needed for the first factor.
• Second factor for Manage OTP = Login Schema with Manage OTP flag and normal LDAP authentication before allowing users to add devices.
  • Third factor is just an LDAP Policy configured with the OTP Active Directory attribute and Push Service. No Login Schema needed.
• Second factor for OTP Authentication = Login Schema with OTP Push (or OTP Passcode) and normal LDAP authentication.
  • Third factor is just an LDAP Policy with the OTP Active Directory attribute and Push Service. No Login Schema needed.

nFactor Visualizer notes:

• nFactor Visualizer is not required. You can instead follow the older manual ADC 12.1 instructions.
• It doesn’t seem to be possible to rename any part of the flow once it’s created. To rename, you basically remove the entire flow and rebuild it.
• nFactor Visualizer does not support policy expressions for Login Schemas so the older ADC 12.1 instructions must be modified to support two different branches.

Create Flow and first factor that selects Manage or selects Authenticate

1. In ADC 13, go to Security > AAA – Application Traffic > nFactor Visualizer > nFactor Flows. Or search the menu for nFactor.
2. On the right, click Add.
   
3. Click the blue plus icon to create a factor.
   
4. Name the factor based on this goal: choose manageotp or authenticate based on whether the user entered /manageotp or not. The name of the first factor is also the name of the nFactor Flow.
5. Click the blue Create button.
   
6. The first factor does not need a Schema.
7. In the first factor, click where it says Add Policy.
   
8. In the Choose Policy to Add page, click Add to create an authentication policy.
   
   1. Name this policy according to this goal: if this policy’s expression is true, then select the manageotp branch (instead of OTP authentication).
   2. For the Action Type drop-down, select NO_AUTHN. This policy is merely a decision point for the next factor so no actual authentication will occur at this time. The next factor is configured later.
   3. In the Expression box, enter something similar to the following. The IP subnet expression restricts the manageotp web page to only internal users.

      http.req.cookie.value("NSC_TASS").eq("manageotp") && client.IP.SRC.IN_SUBNET(10.2.0.0/16)

   4. In newer ADC 13, you might have to change the expression to eq /manageotp, or change it to contains manageotp. (source = Samuel LEGRAND Native OTP issues on Citrix ADC 13) 💡

      http.req.cookie.value("NSC_TASS").eq("/manageotp") && client.IP.SRC.IN_SUBNET(10.2.0.0/16)
      http.req.cookie.value("NSC_TASS").contains("manageotp") && client.IP.SRC.IN_SUBNET(10.2.0.0/16)

   5. Then click the blue Create button.
      
9. Click the blue Add button to bind this policy to the factor.
   
10. In the first factor, below the policy you just added, click the blue plus arrow to create another policy.
    
11. In the Choose Policy to Add page, click Add to create another policy.
    
    1. Name the policy according to this goal: select the dual factor OTP authentication branch.
    2. For the Action Type drop-down, select NO_AUTHN. This is a decision point policy without authentication that leads to the next factor that does the actual authentication.
    3. In the Expression box, enter true to capture all OTP users that did not match the prior manageotp policy.
    4. Click the blue Create button.
       
12. Click Add to bind this policy to the first factor but after (higher priority number) than the manageotp policy.
    

Create second factor for manageotp

1. In the first factor, click the green plus icon to the right of the “SelectManageOTP” policy. If the “SelectManageOTP” policy is true, then this new factor will be evaluated.
   
2. Name this factor according to this goal: perform single-factor LDAP authentication before allowing access to the manageotp web page.
3. Then click the blue Create button.
   
4. In the second factor, click where it says Add Schema.
   
5. In the Choose Schema page, click Add to create a Login Schema.
   
   1. Name the Login Schema according to this goal: ask user for one password that will be verified with LDAP (Active Directory) before showing the manageotp web page.
   2. In the Authentication Schema field, click the pencil icon.
      
   3. The existing window expands to show the Login Schema Files. On the left, click the LoginSchema folder to see the files in that folder.
      
   4. In the list of files, click SingleAuthManageOTP.xml. This login schema asks for one password and has the special hidden credential to enable the manageotp web page.
   5. To actually select this file, on the top right, click the blue Select button. The Login Schema window will then collapse so that Login Schema Files are no longer shown.
      
   6. Make sure the Authentication Schema field shows the Login Schema file that you selected.
   7. Then click the blue Create button.
      
6. Click OK to bind the Schema to the factor.
   
7. In the second factor, below the Schema, click Add Policy.
   
8. In the Choose Policy to Add page, if you already have a normal Advanced Expression LDAP policy, then select it.
9. Otherwise, click Add to create one.
   
   1. Name this policy according to this goal: perform normal LDAP authentication against an Active Directory domain.
   2. In the Action Type drop-down, select LDAP.
   3. In the Action drop-down, select the LDAP Action/Server you created earlier that performs normal authentication.
   4. In the Expression box, enter true, which is an Advanced Expression.
   5. Click the blue Create button.
      
10. Click Add to bind this LDAP Policy to the factor.
    

Create third factor that registers an OTP device with Active Directory and Push

1. In the second factor, click the green plus icon to create another factor. This new factor is only evaluated if the LDAP Policy is successful.
   
2. Name the factor according to this goal: register the device with Active Directory and optionally Push.
   
3. This factor does not need any Schema.
4. In the third factor, click Add Policy
   
5. In the Choose Policy to Add page, click Add to create a policy.
   
   1. Name the policy according to this goal: Register OTP devices using LDAP Action without authentication that has the OTP Secret Attribute specified.
   2. In the Action Type drop-down, select LDAP.
   3. In the Action drop-down, select the LDAP Action you created earlier that registers new devices. Make sure authentication is disabled in the LDAP Action, and make sure it has OTP Secret and optionally OTP Push configured.
   4. In the Expression field, enter true.
   5. Click the blue Create button.
      
6. Click the blue Add button to bind this policy to the factor.
   

The Factors for manageotp are complete. Now we build the factors for authenticating using OTP.

Create a second factor for LDAP Authentication

1. Go back to the first factor and click the green plus icon next to the OTP Authentication policy.
   
2. Name the factor according to this goal: ask user for one password + push, or two passwords, and then perform LDAP authentication. OTP authentication is performed in the next factor (see below).
   
3. In the second factor, click where it says Add Schema.
   
4. In the Choose Schema window, click Add.
   
   1. Name the Login Schema according to this goal: ask for one password + OTP push, or ask for two passwords.
   2. In the Authentication Schema field, click the pencil icon.
      
   3. The window expands to show Login Schema Files. On the left, click the LoginSchema folder to see the files under it.
      
   4. On the left, click the DualAuthPushOrOTP.xml file.
   5. Or if you don’t want push, then click a normal two password schema like DualAuth.xml. You can modify the DualAuth.xml file to indicate to the user that the OTP Passcode is expected in the second field.
   6. Then on the top right click the blue Select button. This causes the Login Schema window to collapse and no longer show the Login Schema Files.
      
   7. In the Authentication Schema field, makes sure the correct file name is selected.
   8. Click More.
      
   9. At the bottom, in the Password Credential Index field, enter a 1 to save the first password into AAA Attribute 1, which we’ll use later in a Traffic Policy that performs Single Sign-on to StoreFront.
   10. Then click the blue Create button.
       
5. Click OK to bind the Schema to the factor.
   
6. In the second factor, below the schema, click where it says Add Policy.
   
7. In the Select Policy drop-down, select your normal LDAP Active Directory authentication policy. This is the same one you used for the second factor in the manageotp branch.
8. Click the blue Add button to bind this LDAP policy to the second factor.
   

Create third factor to perform OTP authentication (Push or Passcode)

1. In the second factor, click the green plus icon next to the LDAP Policy to create another factor.
   
2. Name the factor according to this goal: perform OTP Push or Passcode authentication.
   
3. Be aware that the nFactor Visualizer might swap your third factors.
4. This third factor does not need a Login Schema.
5. In the new third factor (probably the top one, follow the arrows), click where it says Add Policy.
   
6. In the Choose Policy to Add page, click Add to create a policy.
   
   1. Name this policy according to this goal: perform OTP Push or OTP Passcode authentication.
   2. In the Action Type drop-down, select LDAP.
   3. In the Action drop-down, select the LDAP action you created earlier that verifies the OTP push or passcode. This is the Action that has the LDAP Filter configured.
   4. In the Expression box, enter true.
   5. Click the blue Create button.
      
7. Click the blue Add button to bind this policy to the third factor.
   
8. Click the blue Done button to close the Flow.
   

Bind nFactor Flow to AAA Virtual Server

1. In the nFactor Flows menu node, highlight the nFactor Flow and click the button labelled Bind to Authentication Server.
   
2. In the Authentication Server drop-down, select the AAA vServer you created earlier.
3. Everything else should already be filled in so just click the blue Create button.
   

Maximum Number of Registered OTP Devices

ADC 13 lets you restrict the number of OTP devices each user can register:

1. In the ADC menu, go to Security > AAA – Application Traffic.
2. On the right, click Change authentication AAA OTP Parameter.
   
3. Enter the number of devices each user can register and then click OK.
   
4. When the user attempts to register more than the max number of devices, the error message is not user friendly.
   
5. But you can see the actual error by grepping /var/log/ns.log for otp. which might show <Max permitted otp devices reached>.
   

Traffic Policy for Single Sign-on to StoreFront

Create Traffic Profile

1. On the left, go to Citrix Gateway > Policies > Traffic.
2. On the right, switch to the tab named Traffic Profiles, and click Add.
   
3. Name the Traffic Profile according to this goal: use the AAA attribute 1 as password when doing Single Sign-on to StoreFront.
   
4. Scroll down.
5. In the SSO Password Expression box, enter the following which uses the Login Schema Password Attribute specified earlier.

   AAA.USER.ATTRIBUTE(1)

6. Click the blue Create button.
   

Create Traffic Policy

1. On the right, switch to the tab named Traffic Policies, and click Add.
   
2. In the Request Profile field, select the Traffic Profile you just created.
3. Name the Traffic Policy.
4. In the Expression box, enter true (Advanced Syntax).
   • If your Citrix Gateway Virtual Server allows full VPN, change the expression to the following. Source = Julien Mooren at NetScaler – Native OTP is breaking SSL VPN.

     http.req.method.eq(post)||http.req.method.eq(get) && false

5. Click the blue Create button.
   

Citrix Gateway, Traffic Policy, and Authentication Profile

Note: ADC 13.0 build 36.27 will perform a core dump if AppFlow is enabled on the appliance so make sure AppFlow is disabled under Advanced Features. The core dump seems to happen even if no AppFlow policies are bound to the Gateway Virtual Server.

Edit an existing Citrix Gateway Virtual Server

1. Go to Citrix Gateway > Virtual Servers.
2. Edit an existing Gateway vServer. If you don’t have one, see the other Citrix Gateway topics on this site.
   

Bind the Traffic Policy

1. While editing a Gateway Virtual Server, scroll down to the Policies section, and click the plus icon.
   
2. Change the Choose Policy drop-down to Traffic, and then click the blue Continue button.
   
3. In the Policy Binding section, click Click to select.
   
4. Click the radio button next to the Traffic Policy you created earlier, and then click the blue Select button at the top of the page.
   
5. Click the blue Bind button.
   

Create Authentication Profile

Create and bind an Authentication Profile to link the Gateway Virtual Server to the AAA Virtual Server:

1. While editing a Gateway Virtual Server, on the right, in the Advanced Settings column, click Authentication Profile.
   
2. On the left, scroll down to the Authentication Profile section.
3. Click Add to create one.
   
4. Authentication Profile links the Citrix Gateway vServer with the OTP AAA vServer, so name it accordingly.
5. In the Authentication Virtual Server section, click Click to select.
   
6. Click the radio button next to the OTP AAA vServer, and then click the blue Select button at the top of the page.
   
7. Click the blue Create button.
   
8. Scroll down again to the Authentication Profile section, and click the blue OK button. Your selection isn’t saved until you click OK.
   
9. The Portal Theme bound to the Gateway Virtual Server should be X1, RfWebUI, or a derivative.
   

Update Content Switching Expression for Unified Gateway

If your Citrix Gateway Virtual Server is behind a Unified Gateway (Content Switching Virtual Server), then you must update the Content Switching Expression to include the manageotp paths.

1. In the Citrix ADC GUI, navigate to Configuration> Traffic Management > Content Switching > Policies.
2. On the right, select the Unified Gateway Content Switching Policy, and then click Edit.
3. Append the following expression under the Expression area, and then click OK.

   || HTTP.REQ.URL.CONTAINS("/manageotp")

Manageotp User Experience

To access the manageotp web page:

1. Point your browser to https://mygateway.corp.com/manageotp or similar. Add /manageotp to the end of your Gateway URL.
   
2. Notice it’s only single-factor authentication. Login using normal LDAP credentials.
   
3. Click Add Device.
   
4. Enter a device name, and click Go.
   
5. For OTP Push, on your phone, install the Citrix SSO app if it’s not already installed. Then launch it.
   1. Switch to the Password Tokens tab and tap Add New Token.
      
   2. Tap Scan QR Code.
      
   3. Then scan the QRCode shown in your browser.
      
   4. You should see the Device Name. Tap Save.
      
6. If OTP Passcode, launch the Google Authenticator application on your phone. Click the plus icon in Google Authenticator, and scan the QRCode that is shown on the screen.
   1. Citrix SSO app also supports passcode.
   2. Christian in the comments indicated that Microsoft Authenticator also works. Click on plus sign -> other (Google,…).
7. If you configured OTP Push, then you won’t see a Test button. To display the Test button, simply refresh your browser page.
   
8. Click Test.
   
9. Enter the passcode shown in your Authenticator, and click Go.
   
   1. Citrix SSO app shows the passcode on the main Password Tokens view.
      
10. When done, on the top right, click your name and Log Off.
    
11. The OTP registration info is stored in the Active Directory attribute. If users need to re-register, then help desk might need permission to clear this Active Directory attribute.
    

Perform OTP Authentication

1. If you access your Gateway URL normally, you’ll be prompted for either one password or two passwords. If one password, then enter your normal LDAP credentials and Citrix Gateway will send a push notification to your phone. If two passwords, then enter the OTP passcode in the second field.
   
2. The push notification is shown on the phone’s lock screen. Tap it to open the Citrix SSO app.
   
3. Tap Allow to allow the authentication request.
   
4. Tap OK when prompted with Logon Success.
   
5. After Gateway authentication, Gateway should Single Sign-on into StoreFront with no additional password prompts.
   

CLI Commands

Here’s a complete OTP nFactor Flow (Visualizer) CLI configuration (except encrypted passwords):

# AAA Global Settings
# -------------------
enable ns feature AAA
set aaa otpparameter -maxOTPDevices 1


# Push Service
# ------------

add authentication pushService cloudPush -namespace "https://mfa.cloud.com/" -clientID b6effb5e-b2d3125 -clientSecret 152c84647b -encrypted -encryptmethod ENCMTHD_3 -CustomerID MyCompan -trustService "https://trust.citrixworkspacesapi.net/"

# LDAP Actions
# ------------
add authentication ldapAction LDAP-Corp -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn ctxsvc@corp.local -ldapBindDnPassword a368c -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -passwdChange ENABLED -nestedGroupExtraction ON -groupNameIdentifier sAMAccountName -groupSearchAttribute memberOf -groupSearchSubAttribute CN

add authentication ldapAction OTPRegisterDevice -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn admin@corp.local -ldapBindDnPassword 1f952a81 -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED -pushService cloudPush -OTPSecret userParameters

add authentication ldapAction LDAPOTPAuthentication -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn admin@corp.local -ldapBindDnPassword 4319b4d7 -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -searchFilter "userParameters>=#@" -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED -pushService cloudPush -OTPSecret userParameters


# Advanced Authentication Policies
# --------------------------------
add authentication Policy _OTP-AAA_OTPManageOrAuthenticate__root_0 -rule true -action NO_AUTHN

add authentication Policy SelectManageDevices -rule "http.req.cookie.value(\"NSC_TASS\").contains(\"manageotp\") && client.IP.SRC.IN_SUBNET(10.2.0.0/16)" -action NO_AUTHN

add authentication Policy SelectOTPAuthentication -rule true -action NO_AUTHN

add authentication Policy LDAPAdv -rule true -action LDAP-Corp

add authentication Policy OTPRegisterDevice -rule true -action OTPRegisterDevice

add authentication Policy LDAPOTPAuthentication -rule true -action LDAPOTPAuthentication


# Login Schemas
# -------------
add authentication loginSchema SinglePasswordForManageOTP -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuthManageOTP.xml"

add authentication loginSchema OTPPushOrPasscode -authenticationSchema "/nsconfig/loginschema/LoginSchema/DualAuthPushOrOTP.xml" -passwordCredentialIndex 1


# Authentication Policy Labels
# ----------------------------
add authentication policylabel OTPManageOrAuthenticate__root -loginSchema LSCHEMA_INT
bind authentication policylabel OTPManageOrAuthenticate__root -policyName SelectManageDevices -priority 100 -gotoPriorityExpression NEXT -nextFactor AuthenticateToManageDevices__OTPManageOrAuthenticate
bind authentication policylabel OTPManageOrAuthenticate__root -policyName SelectOTPAuthentication -priority 110 -gotoPriorityExpression NEXT -nextFactor OTPAuthentication__OTPManageOrAuthenticate

add authentication policylabel AuthenticateToManageDevices__OTPManageOrAuthenticate -loginSchema SinglePasswordForManageOTP
bind authentication policylabel AuthenticateToManageDevices__OTPManageOrAuthenticate -policyName LDAPAdv -priority 100 -gotoPriorityExpression NEXT -nextFactor OTPDeviceRegistration__OTPManageOrAuthenticate

add authentication policylabel OTPAuthentication__OTPManageOrAuthenticate -loginSchema OTPPushOrPasscode
bind authentication policylabel OTPAuthentication__OTPManageOrAuthenticate -policyName LDAPAdv -priority 100 -gotoPriorityExpression NEXT -nextFactor OTPPushOrPasscode__OTPManageOrAuthenticate

add authentication policylabel OTPDeviceRegistration__OTPManageOrAuthenticate -loginSchema LSCHEMA_INT
bind authentication policylabel OTPDeviceRegistration__OTPManageOrAuthenticate -policyName OTPRegisterDevice -priority 100 -gotoPriorityExpression NEXT

add authentication policylabel OTPPushOrPasscode__OTPManageOrAuthenticate -loginSchema LSCHEMA_INT
bind authentication policylabel OTPPushOrPasscode__OTPManageOrAuthenticate -policyName LDAPOTPAuthentication -priority 100 -gotoPriorityExpression NEXT


# Authentication Virtual Servers
# ------------------------------
add authentication vserver OTP-AAA SSL 0.0.0.0
bind authentication vserver OTP-AAA -policy _OTP-AAA_OTPManageOrAuthenticate__root_0 -priority 100 -nextFactor OTPManageOrAuthenticate__root -gotoPriorityExpression NEXT


# Authentication Profiles
# -----------------------
add authentication authnProfile OTP-AAA -authnVsName OTP-AAA


# NetScaler Gateway Session Profiles
# ----------------------------------
add vpn sessionAction AC_OS_10.2.4.120 -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://xdc01.corp.local/Citrix/StoreWeb" -ClientChoices OFF -ntDomain corp.local -clientlessVpnMode OFF -storefronturl "https://xdc01.corp.local"

add vpn sessionAction AC_WB_10.2.4.120 -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://xdc01.corp.local/Citrix/StoreWeb" -ClientChoices OFF -ntDomain corp.local -clientlessVpnMode OFF


# NetScaler Gateway Session Policies
# ----------------------------------
add vpn sessionPolicy PL_OS_10.2.4.120 "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" AC_OS_10.2.4.120

add vpn sessionPolicy PL_WB_10.2.4.120 "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS" AC_WB_10.2.4.120


# NetScaler Gateway Global Settings
# ---------------------------------
enable ns feature SSLVPN


# NetScaler Gateway Virtual Servers
# ---------------------------------
add vpn vserver gateway2 SSL 10.2.4.220 443 -Listenpolicy NONE -tcpProfileName nstcp_default_XA_XD_profile -deploymentType ICA_STOREFRONT -authnProfile OTP-AAA -vserverFqdn gateway3.corp.com
bind vpn vserver gateway2 -portaltheme RfWebUI
bind vpn vserver gateway2 -policy LDAP-Corp -priority 100
bind vpn vserver gateway2 -policy PL_OS_10.2.4.120 -priority 100
bind vpn vserver gateway2 -policy PL_WB_10.2.4.120 -priority 100


# SSL Virtual Servers
# -------------------
bind ssl vserver gateway2 -certkeyName WildcardCorpCom.cer_CERT_KEY
bind ssl vserver gateway2 -eccCurveName P_256
bind ssl vserver gateway2 -eccCurveName P_384
bind ssl vserver gateway2 -eccCurveName P_224
bind ssl vserver gateway2 -eccCurveName P_521

bind ssl vserver OTP-AAA -certkeyName WildcardCorpCom.cer_CERT_KEY
bind ssl vserver OTP-AAA -eccCurveName P_256
bind ssl vserver OTP-AAA -eccCurveName P_384
bind ssl vserver OTP-AAA -eccCurveName P_224
bind ssl vserver OTP-AAA -eccCurveName P_521