Product Documentation

nFactor for Gateway Authentication

Introduction

nFactor authentication enables a whole new set of possibilities with respect to authentication. Administrators using nFactor enjoy authentication, authorization, and auditing (AAA) 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.

Use-cases

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

  1. Dynamic username and password selection. Traditionally, Citrix clients (including Browsers and Receivers) use the active directory (AD) password as the first password field. The second password is usually reserved for the One-Time-Password (OTP). However, in order 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 login, user’s access levels vary on Citrix ADC 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. In some cases, different pairs of authentication policies are used to authenticate different sets of users. Providing pair policies increases effective authentication. Dependent policies could be made from one flow. In this manner, independent sets of policies become flows of their own that increase efficiency and reduce complexity.

Clients Support

The following table details configuration details. |Client|nFactor Support|Authentication Policy Bind Point|EPA| |—|—|—|—| |Browsers|Yes|Auth|Yes| |Citrix Receivers|No|VPN|N| |Gateway Plug in|No|VPN|Yes|

Authentication Response Handling

The Citrix 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.

Command Line Configuration

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

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

The authnVsName is the name of authentication virtual server. This virtual server is should 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>

Where authnProfile is the previously created authentication profile.

Interop Challenges

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

End Point Analysis (EPA)

Since the AAA subsystem does not support EPA for nFactor; yet, the Gateway virtual server performs EPA. After EPA, the login credentials are sent to the authentication virtual server using the aforementioned API. Once authentication is complete, Gateway continues to the post authentication 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 password(s) obtained are used for these factors. However, with nFactor the number of factors that could be configured is practically unlimited. Passwords obtained from the Gateway client are reused (as per configuration) for configured factors. Care must be taken such that one-time-password (OTP) should not be reused multiple times. Likewise, administrator must ensure that password reused at a factor is indeed applicable to that factor.

Defining Citrix Clients

The configuration option is provided to help Citrix ADC determine browser clients vs. thick clients such as Receiver.

A pattern set, ns_vpn_client_useragents, is provided for the administrator in order to configure patterns for all Citrix clients.

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

Restricting nFactor for Gateway

nfactor for Gateway authentication will not happen if the following conditions are present.

  1. The authnProfile is not set at Citrix Gateway.

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

  3. The User-Agent string in 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 aforementioned patset, requests coming from those user-agents do not participate in the nFactor flow. For example, the command below restricts configuration for all browsers (assuming all browsers contain “Mozilla” in the user-agent string):

bind patset ns_vpn_client_useragents Mozilla

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, etc. of the form. This includes the labels of the form itself. A customer can provide success/failure message that describe the form presented at a given point.

LoginSchema and nFactor Knowledge Required

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

Also, most single factor use cases with few customizations do not need loginSchema(s) configuration.

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

Configuring Dual Factor Authentication Without Using LoginSchema

Citrix ADC 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 could be a “nextFactor” configured as a “passthrough”. A “passthrough” implies that the Citrix ADC should 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. Please see https://docs.citrix.com/en-us/netscaler/12-1/aaa-tm/multi-factor-nfactor-authentication.html.

Username Password Expressions

In order 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 username/password that user presents. These are advanced policy expressions and can be used to override the user input as well.

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. Go to Citrix Gateway -> Virtual Servers.

    localized image

  2. Click on the Add button to create a Load Balancing Virtual server.

    localized image

  3. Enter the following information.

    Parameter name Parameter Description
    Enter the Name of the virtual server. Name for the Citrix 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 Citrix ADC 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 AAA vserver for multi-factor (nFactor) authentication
    Enter the RDP Server Profile. Name of the RDP server profile associated with the vserver.
    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 will be locked if user exceeds maximum permissible attempts.
    Enter the Windows EPA Plugin Upgrade. Option to set plugin upgrade behavior for Win.
    Enter the Linux EPA Plugin Upgrade. Option to set plugin upgrade behavior for Linux.
    Enter the MAC EPA Plugin Upgrade Option to set plugin upgrade behavior for Mac.
    Login Once This option enables/disables seamless SSO for this vserver.
    ICA Only When set to ON, it implies Basic mode where the user can log on using either Citrix Receiver or a browser and get access to the published apps configured at the XenApp/XenDesktop environment pointed out by the Wihome parameter. Users are not allowed to connect using the Citrix Gateway Plug-in 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 Smart Access mode where the user can log on using either Citrix Receiver or a browser or a Citrix Gateway Plug-in. 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 CVPN. 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 Citrix Gateway.
    Double Hop Use the Citrix 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 vserver
    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 device certificate check as a part of EPA is on or off.

    localized image

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

    localized image

  5. Click > to Select the Server Certificate.

    localized image

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

    localized image

  7. Click Bind.

    localized image

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

    localized image

  9. Click the Continue button.

    localized image

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

    localized image

Create Authentication Virtual Server

  1. Go to Security -> AAA – Application Traffic -> Virtual Servers.

    localized image

  2. Click the Add button.

    localized image

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

    Note: The mandatory fields are indicated by an * to the right of the setting name.

    a) Enter the Name for the new authentication virtual server.

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

    c) Enter the IP Address. The IP Address can be zero.

    d) Enter the Protocol type of the authentication virtual server.

    e) Enter the TCP Port on which the virtual server accepts connections.

    f) Enter the domain of the authentication cookie set by Authentication virtual server.

  4. Click OK.

    localized image

  5. Click on the No Server Certificate.

    localized image

  6. Select the desired Server Certificate from the pull down.

    localized image

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

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

    localized image

  8. Configure the Server Certificate Binding.

    • Check the Server Certificate for SNI box to bind the Certkey(s) used for SNI processing.

    • Click the Bind button.

    localized image

Create Authentication CERT Profile

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

    localized image

  2. Select the Profiles tab and then select Add.

    localized image

  3. Complete the following fields to create the Authentication CERT Profile. The mandatory fields are indicated by an * to the right of the setting name.

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

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

    • User Name Field – enter the client-cert field from which the username 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 extracted groups.

  4. Click Create.

    localized image

Create an Authentication Policy

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

    localized image

  2. Select the Add button

    localized image

  3. Complete the following information to Create Authentication Policy. The mandatory fields are indicated by an * to the right of the setting name.

    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 AUTHENTICATION policy is created.

    The following requirement applies only to the Citrix ADC 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 messagelog action to use when a request matches this policy.

    e) Expression - enter the name of the Citrix ADC 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

    localized image

Add an LDAP Authentication Server

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

    localized image

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

    localized image

Add an LDAP Authentication Policy

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

    localized image

  2. Click Add to add an Authentication Policy.

    localized image

  3. Complete the following information to Create Authentication Policy. The mandatory fields are indicated by an * to the right of the setting name.

    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 AUTHENTICATION policy is created.

    The following requirement applies only to the Citrix ADC 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 messagelog action to use when a request matches this policy.

    e) Expression - Name of the Citrix ADC 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

    localized image

Add a Radius Authentication Server

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

    localized image

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

    localized image

  3. Enter the following to create an Authentication RADIUS Server. The mandatory fields are indicated by an * to the right of the setting name.

    a) Enter a Name for the Radius Action.

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

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

    d) Enter the Time-out value in a number of seconds. This is the value that the Citrix ADC appliance waits for a response from the RADIUS server.

    e) Enter the Secret Key that is shared between the RADIUS server and the Citrix ADC appliance. The Secret Key is required to allow the Citrix ADC appliance to communicate with the RADIUS server.

    f) Confirm the Secret Key.

  4. Click Create

    localized image

Add a Radius Authentication Policy

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

    localized image

  2. Click Add to create an Authentication Policy.

    localized image

  3. Complete the following information to Create Authentication Policy. The mandatory fields are indicated by an * to the right of the setting name.

    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 AUTHENTICATION policy is created.

    The following requirement applies only to the Citrix ADC 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 messagelog action to use when a request matches this policy.

    e) Expression - Name of the Citrix ADC 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 OK

    localized image

  5. Verify that your Authentication Policy is listed.

    localized image

Create an Authentication Login Schema

  1. Go to Security -> AAA – Application Traffic -> Login Schema.

    localized image

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

    localized image

  3. Complete the following fields to Create Authentication Login Schema:

    a) Enter Name – this is the name for the new login schema.

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

    c) Enter User Expression - this is the expression for username extraction during login

    d) Enter Password Expression - this is the expression for password extraction during login

    e) Enter User Credential Index - this is the index at which user entered username should be stored in session.

    f) Enter Password Credential Index - this is the index at which user entered password should be stored in session.

    g) Enter Authentication Strength - this is the weight of the current authentication.

  4. Click Create

    localized image

    1. Verify that your Login Schema Profile is listed.

    localized image

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. Go to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Policy Label.

    localized image

  2. Click the Add button.

    localized image

  3. Complete the following fields to Create Authentication Policy Label:

    a) Enter the Name for the new authentication policy label.

    b) Enter the Login Schema associated with authentication policy label.

    c) Click Continue.

    localized image

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

    localized image

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

    localized image

  6. Complete the following fields:

    a) Enter the Priority of the policy binding.

    b) 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.

    localized image

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

    localized image

  8. Click the Bind button.

    localized image

  9. Click Done.

    localized image

  10. Review the Authentication Policy Label.

    localized image