nFactor for gateway authentication

nFactor authentication enables a whole new set of possibilities regarding authentication. Administrators using nFactor enjoy authentication, authorization, and auditing flexibility when configuring authentication factors for virtual servers.

Two policy banks or two factors no longer restrict an administrator. The number of policy banks can be extended to suit different needs. Based on previous factors, nFactor determines a method of authentication. Dynamic login forms and on-failure actions are possible by using nFactor.

Important

• Starting from release 13.0 build 67.x, nFactor authentication is supported with Standard license only for Gateway/VPN virtual server, and not for the authentication virtual server. In Standard license, the nFactor visualizer GUI cannot be used to create the EPA in the nFactor flow. Also, you cannot edit the login schema, but must use the out-of-the-box login schema as-is.
• For NetScaler to support nFactor authentication, an Advanced license or a Premium license is required. For more information about nFactor authentication with NetScaler, see nFactor authentication.

Authentication, authorization, and auditing feature licensing requirements

The following table lists the licensing requirements for the available authentication, authorization, and auditing features.

Note

• For steps to configure nFactor for the NetScaler Standard License, see the section Create a Gateway virtual server for nFactor authentication in NetScaler Standard license.
• Only a non-addressable authentication, authorization, and auditing virtual server can be bound to a Gateway/VPN virtual server in NetScaler Standard license.
• Customization of LoginSchema is not allowed in the NetScaler Standard license. The nFactor support is basic with only default and already added login schemas that come with the appliance. The administrator can use them in their configurations, but they cannot add a login schema. Hence the GUI option is disabled.

Use cases

nFactor authentication enables dynamic authentication flows based on the user profile. Sometimes, the flows can be simple and intuitive to the user. In other cases, they can be coupled with securing active directory or other authentication servers. The following are some requirements specific to Gateway:

1. Dynamic user name and password selection. Traditionally, the Clients (including Browsers and Receivers) use the active directory (AD) password as the first password field. The second password is reserved for the One-Time-Password (OTP). However, to secure AD servers, OTP is required to be validated first. nFactor can do this without requiring client modifications.

2. Multi-Tenant Authentication End-point. Some organizations use different Gateway servers for Certificate and non-certificate users. With users using their own devices to log in, user’s access levels vary on the NetScaler appliance based on the device being used. Gateway can cater to different authentication needs.

3. Authentication based on group membership. Some organizations obtain user properties from AD servers to determine authentication requirements. Authentication requirements can be varied for individual users.

4. Authentication co-factors. Sometimes, different pairs of authentication policies are used to authenticate different sets of users. Providing pair policies increases effective authentication. Dependent policies can be made from one flow. In this manner, independent sets of policies become flows of their own that increase efficiency and reduce complexity.

Authentication response handling

The NetScaler Gateway callback registers handle authentication responses. AAAD (authentication daemon) responses and success/failure/error/dialogue codes are feed to the callback handle. The success/failure/error/dialogue codes direct Gateway to take the appropriate action.

Client support

The following table details configuration details.

Note:

• Citrix Workspace app supports nFactor authentication for the supported operating systems from the following listed versions.
  • Windows 4.12
  • Linux 13.10
  • Mac 1808
  • iOS 2007
  • Android 1808
  • HTML5: Supported through Store Web
  • Chrome: Supported through Store Web

Command line configuration

The Gateway virtual server needs an authentication virtual server named as an attribute. Virtual server name as an attribute is the only configuration required for this model.

add authnProfile <name-of-profile> -authnVsName <name-of-auth-vserver>
<!--NeedCopy-->

The authnVsName is the name of the authentication virtual server. The authnVsName virtual server must be configured with advanced authentication policies and is used for nFactor authentication.

add vpn vserver <name> <serviceType> <IP> <PORT> -authnProfile <name-of-profile>
set vpn vserver <name> -authnProfile <name-of-profile>
<!--NeedCopy-->

Where authnProfile is the previously created authentication profile.

Interop challenges

Most of the Legacy Gateway clients, in addition to rfWeb clients, are modeled on responses sent by Gateway. For example, a 302 response to /vpn/index.html is expected for many clients. These clients also depend on various gateway cookies such as “pwcount,” “NSC_CERT.”

Endpoint analysis (EPA)

EPA in nFactor is not supported for the NetScaler authentication, authorization, and auditing module. Hence, the NetScaler Gateway virtual server performs EPA. After EPA, the login credentials are sent to the authentication virtual server using the previously mentioned API. Once authentication is complete, Gateway continues to the postauthentication process and it establishes the user session.

Misconfiguration considerations

The Gateway client sends the user credentials only once. Gateway gets either one or two credentials from the client with the login request. In the legacy mode, there are a maximum of two factors. The passwords obtained are used for these factors. However, with nFactor the number of factors that can be configured is practically unlimited. The passwords obtained from the Gateway client are reused (as per configuration) for configured factors. Care must be taken such that the one-time-password (OTP) must not be reused multiple times. Likewise, an administrator must ensure that the password reused at a factor is indeed applicable to that factor.

Defining Clients

The configuration option is provided to help NetScaler determine browser clients versus thick clients such as Receiver.

A pattern set, ns_vpn_client_useragents, is provided for the administrator to configure patterns for all Clients.

Likewise, binding the “Citrix Receiver” string to the above patset to ignore all Clients that have “Citrix Receiver” in the User-Agent.

Important

Starting from Citrix Secure Access for Android 24.08.1, the format for the User-Agent string in the webview used for nFactor authentication is changed as follows:

CitrixSecureAccess/CitrixVPN <version> (Linux; Android 14; Build/AP31.240426.023; wv) VpnCapable AuthV3Capable NAC/1.0 [ManagedVpn] [custom-user-agent]

• CitrixSecureAccess/CitrixVPN is included for backward compatibility to identify Citrix Secure Access client on NetScaler Gateway to filter policies.

• The <version> string is replaced by applicable app/OS version number.

• The ManagedVpn and custom-user-agent strings are optional. The ManagedVpn string is included only with MDM deployed VPNs. The custom-user-agent string is configured by the MDM admin in the managed VPN configurations.

In the previous releases, the User-Agent string in the webview included the legacy Mozilla or WebKit compatibility information.

Restricting nFactor for Gateway

nFactor for gateway authentication does not happen if the following conditions are present.

1. The authnProfile is not set to NetScaler Gateway.

2. Advanced authentication policies are not bound to the authentication virtual server and the same authentication virtual server is mentioned in authnProfile.

3. The User-Agent string in the HTTP request matches the User-Agents configured in patset ns_vpn_client_useragents.

If these conditions are not met, the classic authentication policy bound to Gateway is used.

If a User-Agent, or portion of it is bound to the previously mentioned patset, requests coming from those user-agents do not participate in the nFactor flow. For example, the following command restricts configuration for all browsers (assuming all browsers contain “Mozilla” in the user-agent string):

bind patset ns_vpn_client_useragents Mozilla
<!--NeedCopy-->

LoginSchema

LoginSchema is a logical representation of the logon form. The XML language defines it. The Syntax of the loginSchema conforms to Citrix’s Common Forms Protocol specification.

LoginSchema defines the “view” of the product. An Administrator can provide a customized description, assistive text, and so forth of the form. The login schema includes the labels of the form itself. A customer can provide the success or failure message that describes the form presented at a given point.

Use the following command to configure a login schema.

add authentication loginSchema <name> -authenticationSchema <string> [-userExpression <string>] [-passwdExpression <string>] [-userCredentialIndex <positive_integer>]
[-passwordCredentialIndex <positive_integer>] [-authenticationStrength <positive_integer>] [-SSOCredentials ( YES | NO )]
<!--NeedCopy-->

Parameter description

• name - Name for the new login schema. This is a mandatory argument. Maximum Length: 127

• authenticationSchema - Name of the file for reading authentication schema to be sent for Login Page UI. This file contains the xml definition of the elements as per the Citrix Forms Authentication Protocol to be able to render the login form. If the administrator does not want to prompt users for other credentials but continue with previously obtained credentials, then noschema can be given as an argument. This applies only to loginSchemas that are used with the user-defined factors, and not the virtual server factor.

This is a mandatory argument. Maximum Length: 255

• userExpression - Expression for user name extraction during login. This can be any relevant advanced policy expression. Maximum Length: 127

• passwdExpression - Expression for password extraction during login. This can be any relevant advanced policy expression. Maximum Length: 127

• userCredentialIndex - The index at which the user entered user name must be stored in session. Minimum value: 1, Maximum value: 16

• passwordCredentialIndex - The index at which the user entered the password must be stored in session. Minimum value: 1, Maximum value: 16

• authenticationStrength - Weight of the current authentication Minimum value: 0, Maximum value: 65535

• SSOCredentials - This option indicates whether current factor credentials are the default SSO (SingleSignOn) credentials. Possible values: YES, NO. Default value: NO

LoginSchema and nFactor knowledge required

Pre-built loginSchema files are found in the following NetScaler location /nsconfig/loginschema/LoginSchema/. These pre-built loginSchema files cater to common use cases, and can be modified for slight variations if necessary.

Also, most single factor use cases with few customizations do not need the login schema configuration.

The administrator is advised to check the documentation for other configuration options that enable NetScaler to discover the factors. Once the user submits the credentials, the administrator can configure more than one factor to flexibly choose and process the authentication factors.

Configuring dual factor authentication without using LoginSchema

NetScaler automatically determines dual factor requirements based on configuration. Once the user presents these credentials, the administrator can configure the first set of policies at the virtual server. Against each policy there can be a “nextFactor” configured as a “passthrough.” A “passthrough” implies that the NetScaler must process the logon using the existing credential set without going to the user. By using “passthrough” factors, an administrator can programmatically drive the authentication flow. Administrators are advised to read the nFactor specification or the deployment guides for further details. See Multi-Factor (nFactor) authentication.

User name and password expressions

To process the login credentials, the administrator must configure the loginSchema. Single factor or dual factor use cases with few loginSchema customizations does not need a specified XML definition. The LoginSchema has other properties such as userExpression and passwdExpression that can be used to alter the user name or password that the user presents.

Login schemas are advanced policy expressions and can be used to override the user input as well. This can be achieved by appending a string for parameters in -authenticationSchema as shown in the following example.

Following are the examples to modify user inputs for user name and for password respectively.

• Change the user input for user name from username@citrix.com to username@xyz.com

   add authentication loginSchema user_schema -authenticationSchema LoginSchema/DualAuth.xml -userExpression "AAA.LOGIN.USERNAME.BEFORE_STR(\"@\").APPEND(\"@xyz.com\")"
   <!--NeedCopy-->
  

• Consider a scenario where the user provides a password and a passcode in the first factor as part of the login schema configured. To use the passcode provided by the user in the first factor and the password in the second factor, you can modify the existing login schema by using the following commands.

   add authentication loginSchema user_schema -authenticationSchema LoginSchema/DualAuth.xml -passwdExpression "AAA.LOGIN.PASSWORD2"
   <!--NeedCopy-->
  

   add authentication loginSchema user_schema_second -authenticationSchema noschema  -passwdExpression "AAA.LOGIN.PASSWORD"
   <!--NeedCopy-->
  

High-level steps in nFactor configuration

The following diagram illustrates the high-level steps involved in nFactor configuration.

GUI Configuration

The following topics are described in this section:

• Create a Virtual Server

• Create Authentication Virtual Server

• Create Authentication CERT Profile

• Create an Authentication Policy

• Add an LDAP authentication server

• Add an LDAP authentication policy

• Add a RADIUS authentication server

• Add a RADIUS Authentication Policy

• Create an Authentication Login Schema

• Create a Policy Label

Create a virtual server

1. Navigate to NetScaler Gateway > Virtual Servers.

2. Click the Add button to create a gateway virtual server.

3. Enter the following information and click OK.

   Parameter name	Parameter Description
   Enter the Name of the virtual server.	Name for the NetScaler Gateway virtual server. Must begin with an ASCII alphabetic or underscore (_) character, and must contain only ASCII alphanumeric, underscore, hash (#), period (.), space, colon (:), at (@), equals (=), and hyphen (-) characters. Can be changed after the virtual server is created. The following requirement applies only to the NetScaler CLI: If the name includes one or more spaces, enclose the name in double or single quotation marks (for example, “my server” or ‘my server’).
   Enter the IP Address Type for the virtual server	Select an IP Address or Non-addressable option from the drop-down menu.
   Enter the IP Address of the virtual server.	An Internet Protocol address (IP address) is a numerical label assigned to each device participating in the computer network that uses the Internet Protocol for communication.
   Enter the Port number for the virtual server.	Enter the port number.
   Enter the Authentication Profile.	Authentication Profile entity on virtual server. This entity can be used to offload authentication to authentication, authorization, and auditing virtual server for multi-factor (nFactor) authentication
   Enter the RDP Server Profile.	Name of the RDP server profile associated with the virtual server.
   Enter the Maximum Users.	Maximum number of concurrent user sessions allowed on this virtual server. The actual number of users allowed to log on to this virtual server depends on the total number of user licenses.
   Enter the Max Login Attempts.	Maximum number of logon attempts.
   Enter the Failed Login Timeout.	Number of minutes an account is locked if the user exceeds the maximum permissible attempts.
   Enter the Windows EPA plug-in Upgrade.	Option to set plug-in upgrade behavior for Win.
   Enter the Linux EPA plug-in upgrade.	Option to set plug-in upgrade behavior for Linux.
   Enter the MAC EPA plug-in upgrade	Option to set plug-in upgrade behavior for Mac.
   Login Once	This option enables/disables seamless SSO for this virtual server.
   ICA Only	When set to ON, it implies Basic mode where the user can log on using either the Citrix Workspace app or a browser and get access to the published apps configured at the Citrix Virtual Apps and Desktops environment pointed out by the Wihome parameter. Users are not allowed to connect using the Citrix Secure Access client and end point scans cannot be configured. The numbers of users that can log in and access the apps are not limited by the license in this mode. - When set to OFF, it implies SmartAccess mode where the user can log on using either the Citrix Workspace app or a browser or a Citrix Secure Access client. The admin can configure end point scans to be run on the client systems and then use the results to control access to the published apps. In this mode, the client can connect to the gateway in other client modes namely VPN and clientless VPN. The numbers of users that can log in and access the resources are limited by the CCU licenses in this mode.
   Enable Authentication	Require authentication for users connecting to NetScaler Gateway.
   Double Hop	Use the NetScaler Gateway appliance in a double-hop configuration. A double-hop deployment provides an extra layer of security for the internal network by using three firewalls to divide the DMZ into two stages. Such a deployment can have one appliance in the DMZ and one appliance in the secure network.
   Down State Flush	Close existing connections when the virtual server is marked DOWN, which means the server might have timed out. Disconnecting existing connections frees resources and in certain cases speeds recovery of overloaded load balancing setups. Enable this setting on servers in which the connections can safely be closed when they are marked DOWN. Do not enable DOWN state flush on servers that must complete their transactions.
   DTLS	This option starts/stops the turn service on the virtual server
   AppFlow Logging	Log AppFlow records that contain standard NetFlow or IPFIX information, such as time stamps for the beginning and end of a flow, packet count, and byte count. Also log records that contain application-level information, such as HTTP web addresses, HTTP request methods and response status codes, server response time, and latency.
   ICA Proxy Session Migration	This option determines if an existing ICA Proxy session is transferred when the user logs on from another device.
   State	The current state of the virtual server, as UP, DOWN, BUSY, and so on.
   Enable Device Certificate	Indicates whether the device certificate check as a part of EPA is on or off.

   

4. Select the No Server Certificate section of the page.

5. Click > under Select Server Certificate to select the server certificate.

6. Select the SSL Certificate and click the Select button.

7. Click Bind.

8. If you see a warning about No usable ciphers, click OK

9. Click the Continue button.

10. In the Authentication section, click the + icon in the top right.

Create an authentication virtual server

1. Navigate to Security > AAA – Application Traffic > Virtual Servers.

2. Click the Add button.

3. Complete the following Basic Settings to create the Authentication Virtual Server.

   Note: The * sign to the right of the setting name indicates mandatory fields.

   • Enter the Name for the new authentication virtual server.

   • Enter the IP Address Type. The IP Address Type can be configured as Non-addressable.

   • Enter the IP Address. The IP Address can be zero.

   • Enter the Protocol type of the authentication virtual server.

   • Enter the TCP Port on which the virtual server accepts connections.

   • Enter the domain of the authentication cookie set by the authentication virtual server.

4. Click OK.

5. Click the No Server Certificate section.

6. Click > under Select Server Certificate.

7. Choose the desired SSL Certificate and click the Select button.

   Note: The Authentication virtual server does not need a certificate bound to it.

8. Configure the Server Certificate Binding.

   • Check the Server Certificate for SNI box to bind one or more Cert keys used for SNI processing.

   • Click the Bind button.

   

Create an authentication CERT profile

1. Navigate to Security > AAA – Application Traffic > Policies > Authentication > Basic Policies > CERT.

2. Select the Profiles tab and then select Add.

3. Complete the following fields to create the Authentication CERT Profile. The * sign to the right of the setting name indicates mandatory fields.

   • Name - Name for the client cert authentication server profile (action).

   • Two factor – In this instance the two-factor authentication option is NOOP.

   • User Name Field – enter the client-cert field from which the user name is extracted. Must be set to either ““Subject”” or ““Issuer”” (include both sets of double quotation marks).

   • Group Name Field - enter the client-cert field from which the group is extracted. Must be set to either ““Subject”” or ““Issuer”” (include both sets of double quotation marks).

   • Default Authentication Group - This is the default group that is chosen when the authentication succeeds in addition to the extracted groups.

4. Click Create.

Create an authentication policy

Note

If you configure a first factor policy with a policy rule using AAA.login, then the following expression must be configured with OR condition for Citrix Workspace app to support the nFactor deployment.

|| HTTP.REQ.URL.CONTAINS("/cgi/authenticate")

1. Navigate to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy.

2. Select the Add button

3. Complete the following information to create an authentication policy. The * sign to the right of the setting name indicates mandatory fields.

   a) Name – enter the Name for the advance AUTHENTICATION policy. Must begin with a letter, number, or the underscore character (_), and must contain only letters, numbers, and the hyphen (-), period (.) pound (#), space (), at (@), equals (=), colon (:), and underscore characters. Cannot be changed after the authentication policy is created.

   The following requirement applies only to the NetScaler CLI: If the name includes one or more spaces, enclose the name in double or single quotation marks (for example, “my authentication policy” or ‘my authentication policy’).

   b) Action Type - enter the type of the Authentication Action.

   c) Action - enter the name of the authentication action to be performed if the policy matches.

   d) Log Action - enter the name of the message log action to use when a request matches this policy.

   e) Expression - enter the name of the NetScaler named rule, or a default syntax expression, that the policy uses to determine whether to attempt to authenticate the user with the AUTHENTICATION server.

   f) Comments – enter any comments to preserve information about this policy.

4. Click Create

Add an LDAP authentication server

1. Navigate to Security > AAA – Application Traffic > Policies > Authentication > Basic Policies > LDAP.

2. Add an LDAP server by selecting the Server tab and selecting the Add button.

Add an LDAP authentication policy

1. Go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy.

2. Click Add to add an Authentication Policy.

3. Complete the following information to Create an Authentication Policy. The * sign to the right of the setting name indicates mandatory fields.

   a) Name - Name for the advance AUTHENTICATION policy. Must begin with a letter, number, or the underscore character (_), and must contain only letters, numbers, and the hyphen (-), period (.) pound (#), space (), at (@), equals (=), colon (:), and underscore characters. Cannot be changed after the authentication policy is created.

   The following requirement applies only to the NetScaler CLI: If the name includes one or more spaces, enclose the name in double or single quotation marks (for example, “my authentication policy” or ‘my authentication policy’).

   b) Action Type - Type of the Authentication Action.

   c) Action - Name of the authentication action to be performed if the policy matches.

   d) Log Action - Name of message log action to use when a request matches this policy.

   e) Expression - Name of the NetScaler named rule, or a default syntax expression, that the policy uses to determine whether to attempt to authenticate the user with the AUTHENTICATION server.

   f) Comments - Any comments to preserve information about this policy.

4. Click Create.

Add a RADIUS authentication server

1. Navigate to Security > AAA – Application Traffic > Policies Authentication > Basic Policies > RADIUS.

2. To add a Server select the Servers tab and select the Add button.

3. Enter the following to create an Authentication RADIUS Server. The * sign to the right of the setting name indicates mandatory fields.

   1. Enter a Name for the RADIUS Action.

   2. Enter the Server Name or Server IP Address assigned to the RADIUS server.

   3. Enter the Port number on which the RADIUS server listens for connections.

   4. Enter the Time-out value in few seconds. The NetScaler appliance waits for a response from the RADIUS server until the configured timeout value expires.

   5. Enter the Secret Key that is shared between the RADIUS server and the NetScaler appliance. The Secret Key is required to allow the NetScaler appliance to communicate with the RADIUS server.

   6. Confirm the Secret Key.

4. Click Create.

Add a RADIUS authentication policy

1. Navigate to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy.

2. Click Add to create an Authentication Policy.

3. Complete the following information to create an authentication policy. The * sign to the right of the setting name indicates mandatory fields.

   1. Name - Name for the advance AUTHENTICATION policy. Must begin with a letter, number, or the underscore character (_), and must contain only letters, numbers, and the hyphen (-), period (.) pound (#), space (), at (@), equals (=), colon (:), and underscore characters. Cannot be changed after the AUTHENTICATION policy is created.

   The following requirement applies only to the NetScaler CLI: If the name includes one or more spaces, enclose the name in double or single quotation marks (for example, “my authentication policy” or ‘my authentication policy’).

   1. Action Type - Type of the Authentication Action.

   2. Action - Name of the authentication action to be performed if the policy matches.

   3. Log Action - Name of message log action to use when a request matches this policy.

   4. Expression - Name of the NetScaler named rule, or a default syntax expression, that the policy uses to determine whether to attempt to authenticate the user with the AUTHENTICATION server.

   5. Comments - Any comments to preserve information about this policy.

4. Click OK. The authentication policy that you created is listed in the list of policies.

   

Create an Authentication Login Schema

1. Navigate to Security > AAA – Application Traffic > Login Schema.

2. Select the Profiles tab and Click the Add button.

3. Complete the following fields to create an authentication login schema:

   1. Enter Name – Name for the new login schema.

   2. Enter Authentication Schema - Name of the file for reading the authentication schema to be sent for Login Page UI. This file must contain the xml definition of the elements as per the Citrix Forms Authentication Protocol to be able to render a login form. If an administrator does not want to prompt users for more credentials but continue with previously obtained credentials, then “noschema” can be given as an argument. This applies only to loginSchemas that are used with user-defined factors, and not the virtual server factor

   3. Enter User Expression - Expression for user name extraction during login

   4. Enter Password Expression - Expression for password extraction during login

   5. Enter User Credential Index - An index at which the user entered user name is stored in session.

   6. Enter Password Credential Index - An index at which the user entered password must be stored in session.

   7. Enter Authentication Strength - Weight of the current authentication.

4. Click Create. The login schema profile that you created must appear in the login schema profile list.

   

Create a policy label

A policy label specifies the authentication policies for a particular factor. Each policy label corresponds to a single factor. The policy label specifies the login form that must be presented to the user. The policy label must be bound as the next factor of an authentication policy or of another authentication policy label. Typically, a policy label includes authentication policies for a specific authentication mechanism. However, you can also have a policy label that has authentication policies for different authentication mechanisms.

1. Navigate to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy Label.

2. Click the Add button.

3. Complete the following fields to create an authentication policy label:

   1. Enter the Name for the new authentication policy label.

   2. Enter the Login Schema associated with the authentication policy label.

   3. Click Continue.

4. Select a Policy from the drop-down menu.

5. Choose the desired Authentication Policy and click the Select button.

6. Complete the following fields:

   1. Enter the Priority of the policy binding.

   2. Enter the Goto Expression – the expression specifies the priority of the next policy that will be evaluated if the current policy rule evaluates to TRUE.

   

7. Select the desired Authentication Policy and click the Select button.

8. Click the Bind button.

9. Click Done.

10. Review the Authentication Policy Label.

re-Captcha configuration for nFactor authentication

Starting from NetScaler release 12.1 build 50.x, NetScaler Gateway supports a new first class action ‘captchaAction’ that simplifies Captcha configuration. As Captcha is a first class action, it can be a factor of its own. You can inject Captcha anywhere in the nFactor flow.

Previously, you had to write custom WebAuth policies with changes to the RfWebUI as well. With the introduction of captchaACtion, you do not have to modify the JavaScript.

Important

If Captcha is used along with user name or password fields in the schema, the Submit button is disabled until Captcha is met.

Captcha configuration

Captcha configuration involves two parts.

1. Configuration on Google for registering Captcha.
2. Configuration on NetScaler appliance to use Captcha as part of login flow.

Captcha configuration on Google

Register a domain for Captcha at https://www.google.com/recaptcha/admin#list.

1. When you navigate to this page, the following screen appears.

   

   Note

   Use reCAPTCHA v2 only. Invisible reCAPTCHA is still in preview.

2. After a domain is registered, the “SiteKey” and “SecretKey” are displayed.

   

   Note

   The “SiteKey” and “SecretKey” are grayed out for security reasons. “SecretKey” must be kept safe.

Captcha configuration on the NetScaler appliance

Captcha configuration on the NetScaler appliance can be divided into three parts:

• Display Captcha screen
• Post the Captcha response to Google server
• LDAP configuration is second factor for user logon (optional)

Display Captcha screen

The login form customization is done through the SingleAuthCaptcha.xml login schema. This customization is specified at the authentication virtual server and is sent to UI for rendering the login form. The built-in login schema, SingleAuthCaptcha.xml, is at /nsconfig/loginSchema/LoginSchema directory on the NetScaler appliance.

Important

• Based on your use case and different schemas, you can modify the existing schema. For instance if you need only Captcha factor (without user name or password) or dual authentication with Captcha.
• If any custom modifications are performed or the file is renamed, Citrix recommends copying all login schemas from the /nsconfig/loginschema/LoginSchema directory to the parent directory, /nsconfig/loginschema.

To configure display of Captcha using CLI

-  add authentication loginSchema singleauthcaptcha -authenticationSchema /nsconfig/loginschema/SingleAuthCaptcha.xml

-  add authentication loginSchemaPolicy singleauthcaptcha -rule true -action singleauthcaptcha

-  add authentication vserver auth SSL <IP> <Port>

-  add ssl certkey vserver-cert -cert <path-to-cert-file> -key <path-to-key-file>
-  bind ssl vserver auth -certkey vserver-cert
-  bind authentication vserver auth -policy singleauthcaptcha -priority 5 -gotoPriorityExpression END
<!--NeedCopy-->

Post the Captcha response to Google server

After you have configured the Captcha that must be displayed to the users, the admins post the configuration to the Google server to verify the Captcha response from the browser.

To verify the Captcha response from the browser

-  add authentication captchaAction myrecaptcha -sitekey <sitekey-copied-from-google> -secretkey <secretkey-from-google>

-  add authentication policy myrecaptcha -rule true -action myrecaptcha
-  bind authentication vserver auth -policy myrecaptcha -priority 1
<!--NeedCopy-->

The following commands are required to configure if AD authentication is desired. Else, you can ignore this step.

-  add authentication ldapAction ldap-new -serverIP x.x.x.x -serverPort 636 -ldapBase "cn=users,dc=aaatm,dc=com" -ldapBindDn adminuser@aaatm.com -ldapBindDnPassword <password> -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberof -subAttributeName CN -secType SSL -passwdChange ENABLED -defaultAuthenticationGroup ldapGroup

-  add authenticationpolicy ldap-new -rule true -action ldap-new
<!--NeedCopy-->

LDAP configuration is second factor for user logon (optional)

The LDAP authentication happens after Captcha, you add it to the second factor.

-  add authentication policylabel second-factor
-  bind authentication policylabel second-factor -policy ldap-new -priority 10
-  bind authentication vserver auth -policy myrecaptcha -priority 1 -nextFactor second-factor
<!--NeedCopy-->

Administrator needs to add appropriate virtual servers depending on whether load balancing virtual server or NetScaler Gateway appliance is used for access. Administrator must configure the following command if a load balancing virtual server is required:

add lb vserver lbtest HTTP <IP> <Port> -authentication ON -authenticationHost nssp.aaatm.com`
<!--NeedCopy-->

nssp.aaatm.com – Resolves to authentication virtual server.

User validation of Captcha

Once you have configured all the steps mentioned in the previous sections, see the preceding user interface screen captures.

1. Once the authentication virtual server loads the login page, the logon screen is displayed. Log On is disabled until Captcha is complete.

   

2. Select I’m not a robot option. The Captcha widget is displayed.

   

3. You are navigated through a series of Captcha images, before the completion page is displayed.

4. Enter the AD credentials, select the I’m not a robot check box and click Log On. If authentication succeeds, you are redirected to the desired resource.

   

   Note:

   • If Captcha is used with AD authentication, the Submit button for credentials is disabled until Captcha is complete.
   • The Captcha happens in a factor of its own. Therefore, any subsequent validations like AD must happen in the nextfactor of Captcha.

Create a Gateway virtual server for nFactor authentication in NetScaler Standard license

1. Navigate to NetScaler Gateway > Virtual Servers.
2. On the NetScaler Gateway Virtual Servers page, click Add.
3. Enter the following details on the VPN Virtual Server page, click OK, and click Continue.
   • Name - Name of the NetScaler Gateway virtual server
   • Protocol - Select SSL
   • IP Address - IP address of NetScaler Gateway virtual server
   • Port - Enter 443

1. On the VPN Virtual Server page, click the plus icon next to Authentication Profile.

2. Click Add to configure the authentication profile.

   

3. Enter a name for the authentication profile and click Add.

   

4. Enter the following details on the VPN Virtual Server page, click OK, and click Continue.

   • Name - Name of the authentication, authorization, and auditing virtual server
   • Protocol - Select Non Addressable. Only a non-addressable authentication, authorization, and auditing virtual server can be bound to a Gateway/VPN virtual server in NetScaler Standard license.

   

   Note:

   • In the NetScaler Standard license, the steps for creating policy are the same as the Premium License for supported policy types.
   • NetScaler Standard license does not support an addition of new login schemas in the nFactor configuration.

References

For an end-to-end nFactor configuration example, see Configuring nFactor authentication.