nFactor is the new authentication framework that allows an administrator to configure complex authentication scenarios fairly easily. It reduces complexity through flexible and extensible authentication mechanisms. This framework could be used to configure all the authentication modes currently possible with Citrix NetScaler.
For basic entities involved in nFactor and concepts overview, please refer to https://support.citrix.com/article/CTX222713

nFactor Support for Gateway

nFactor authentication has been supported for AAA-TM (AAA for Traffic Management) module from 11.0 version of NetScaler, although 11.1 is the recommended version due to advanced authentication integration. Similarly, you can achieve dual factor authentication in native gateway clients using nFactor configuration on NetScaler 11.1-52.x onwards. nFactor at Gateway is supported by leveraging authentication (or AAA) virtual server. For supporting nFactor, one would need to configure a new entity ‘authenticationProfile’ on Gateway. This entity, in turn, points to AAA virtual server that has nFactor configuration. This way, same virtual server can be reused for AAA-TM and Gateway. Here are the commands for supporting nFactor at Gateway:

>add authnProfile nfactor_prof –authnVsName <name-of-aaa-vserver>
>set vpn vserver gatewayVserver –authnProfile nfactor_prof

nFactor Support previous to NetScaler 11.1 (52.x)

Although Gateway module also supports nFactor, its support was split based on the clients that connect to Gateway.

Predominantly, these clients can be categorized as:

• Native clients

Gateway plugin and Citrix Receiver on all platforms. These clients communicate with Gateway using legacy Gateway protocol

• Browser clients
  • All browsers. These clients communicate using new protocol.

Prior to NetScaler version 11.1 52.x, nFactor is supported only for browser clients. This meant that all the Native Clients (that speak legacy Gateway protocol) used authentication policies configured at Gateway. In contrast, browser clients use policies configured at AAA virtual server.
This forced administrator to create two sets of policies, one set for native clients and another for browser clients. Native client authentication policies are at Gateway virtual server and browser client authentication policies are at AAA virtual server.
 
This is depicted by the diagram below:

 

nFactor at Gateway from 11.1 52.x

Beginning 11.1 52.x, both Native and Browser clients use policies configured at AAA virtual server. This means administrator need not maintain different sets of policies unless required for specific processing.
These policies should be advanced authentication policies bound at AAA virtual server. This way, there is only one place to configure the policies.
 

What does it not mean?

Although Native Clients can now leverage advanced authentication policies, they still interact using legacy Gateway protocol. That is, gateway does not present a second login screen to the clients. Gateway would act intelligently based on the clients that are interfacing with it. That is, for Browser client, Gateway would redirect to advanced login page with all customizations. For a Native client, Gateway would respond according to the legacy protocol.
 
 

Caveats with nFactor for Legacy Clients

 Native Clients behaved in a rigid way. They had specific ways to figure out the configuration on Gateway. For example, Native clients learn whether 2-factor is configured based on the cookie in response to /vpn/index.html. Likewise, they learn about certificate authentication in addition to AD authentication using a cookie.
In summary, Native plugins look at below cookies in response to /vpn/index.html

1. Pwcount – If this cookie has a value “2”, Native clients assume there are 2 factors and hence they need to render two password fields
2. NSC_CERT – Presence of this cookie implies that there are authentication factors followed by certificate authentication. That is,
   1. NSC_CERT cookie and pwcount with “0” implies 1 factor after certificate authentication.
   2. NSC_CERT cookie and pwcount with “2” implies 2 factors after certificate.

 
 

Solutions to support nFactor with Legacy clients

In nFactor, all UI customizations are defined by LoginSchema policies at vserver (or LoginSchema at user defined factors). For introduction to LoginSchema please refer to https://support.citrix.com/article/CTX222713. Configured LoginSchema is sent to browser clients that interpret the contents to render logon form.
On the same lines, loginSchema will be used to provide certain hints to the Native Clients. Since Native clients do not process LoginSchema (even if it sent), Gateway processes the configured LoginSchema, learns the configured factors, and sends hint to the clients in response to /vpn/index.html.
 
That is, when processing “/vpn/index.html” request from Native Client, Gateway refers to configured LoginSchema policies. It picks the first “true” policy and parses the schema definition. If the schema file defines two password fields, it sends pwcount cookie with a value of 2.
Similarly, if Gateway finds a credential defined for the certificate, it sends NSC_CERT cookie to the client. This way, by configuring loginSchema policies specific to Native clients, the administrator would be able to achieve legacy two-factor at Native clients.
Described below are examples for some use-cases.
 

Examples LoginSchema Policies for NativeClients

Two-factor schema

For supporting two factors with Native clients, one could create below loginSchema and bind it to AAA vserver.
>add loginSchema native_clients_two_factor_schema –authenticationSchema DualAuth.xml
>add loginSchemaPolciy native_clients_two_factor_schema_policy –rule http.req.header(“User-Agent”).contains_any(ns_vpn_client_useragents) –action native_clients_two_factor_schema
>bind authentication vserver <> -policy native_clients_two_factor_schema_policy –pri 100
 

Cert + LDAP

For supporting certificate authentication with additional factor, below LoginSchema could be used
>add loginschema native_clients_cert_single_factor_schema –authenticationSchema ClientCertSingleAuthDeviceID.xml à this could be modified to remove the deviceID credential. Future revisions of NetScaler will have specific loginSchema file.
>add loginschemaPolicy native_clients_cert_single_factor_schema_policy –rule http.req.header(“User-Agent”).contains_any(ns_vpn_client_useragents) –action native_clients_cert_single_factor_schema
>bind authentication vserver <> -policy native_clients_two_factor_schema_policy –pri 100
 
Similarly, one could configure loginSchema policies for certificate authentication followed by 2factors using the builtin loginSchema file called ClientCertDualAuthDeviceID.xml.
 
 

SSO Credentials with Native Clients

Apart from the pwcount issue, another caveat that exists with nFactor at Native clients is the SSO password (or SSO credentials). This is not a problem as long as the last authentication factor is AD. By default, with nFactor, the last password becomes the default SSO password.
However, if LDAP does not happen to be the last factor, then administrator needs to configure below configuration on the loginSchema associated with LDAP/AD factor.
Let us say “ldap_schema” is the loginSchema associated with LDAP factor. Below configuration needs to be set on that schema.
>set loginschema ldap_schema –SSOCredentials YES
 
If LDAP happens to the first factor, the loginSchema associated with LoginSchema policies at virtual server should be configured with above option.
For example,
>set loginschema native_clients_two_factor_schema –SSOCredentials YES
 
 

Legacy Protocol with Browsers

By default, all the browsers used advanced wire protocol or nfactor wire protocol when communicating with the gateway. Use of nfactor changes not only the control protocol that the client uses to communicate with the gateway, it also changes the way UI is rendered. nFactor’s UI is customized in a different way than the legacy UI.
To summarize, both UI rendering/customization and wire protocol are different with nFactor.
However, there could be legacy customizations on old portal themes that might have to be changed when moving to nFactor UI. In the interim, if customers would like to preserve legacy portal theme but use advanced/nfactor authentication policies on Gateway, it is possible to do that with below configuration.
>bind patset ns_vpn_client_useragents Mozilla
 
Above command qualifies all browsers as legacy clients. Once Gateway determines a client as a native client, it does not redirect the browser to an advanced login page. Instead, it lets the browser use the legacy portal theme and legacy protocol to communicate with Gateway. Once the logon post arrives at Gateway, the administrator could still use nfactor authentication policies to make conditional policies.
 
A downside of above command is that once browsers use legacy rendering, you cannot go to the browser a second time for login credentials. That is, all the credentials have to obtained once, and going to the client only for challenge-response flows such as password expiry or radius challenges.