nFactor Authentication with Native Clients from NetScaler 11.1

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, Gateway module also supports nFactor in 11.1 for browser clients.

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
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:

User-added image

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.

Although Native Clients can now leverage advanced authentication policies, they still interact using legacy Gateway protocol. That is, Native Clients do not yet support nFactor wire protocol. 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.

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.

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.

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.

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

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.

User-added image

Related:

How to Configure ADFS on Microsoft 2012 Server to Use with NetScaler Appliance

  • To configure a signing certificate, go to Relaying Party > Properties and add the signing certificate.

    Note: If the specified signing certificate is less than 2048 key size, ADFS will throw a warning message that can be ignored.

    If the deployment is for a test environment, clear the signing certificate cancellation check on the Relaying party. Otherwise, ADFS will try the CRL provided in the signing certificate to validate the certificate.

    C:UsersAdministrator> Set-ADFSRelyingPartyTrust -SigningCertificateRevocationCheck None -TargetName Netscaler

  • Related:

    • No Related Posts

    How to Configure Office365 for Single Sign-on with NetScaler as SAML Identity Provider

    Software Solution Disclaimer

    This package contains a software solution that has been replaced by a more recent version available for download from the Citrix support website (support.citrix.com). It is provided merely for your convenience. Citrix recommends applying the most up-to-date version of the software, which addresses the fix or enhancement being targeted. Later versions of the release may include multiple changes that address different areas including security vulnerabilities, code fixes, and enhancements. Installation of this software should only be performed on test or developmental environments. This software is not supported and is provided “AS IS.” You are solely responsible for your selection and use of the software. Any reported issues will require the most current revision of the software (http://www.citrix.com/English/SS/supportThird.asp?slID=5107&tlID=1861652). Please visit our security site for additional security notices and information (support.citrix.com/securitybulletins ).

    CITRIX MAKES NO REPRESENTATIONS OR WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE WITH RESPECT TO THE PROVIDED SOFTWARE SOLUTION. THE SOFTWARE SOLUTIONS ARE DELIVERED ON AN “AS IS” BASIS WITH NO SUPPORT. YOU SHALL HAVE THE SOLE RESPONSIBILITY FOR ADEQUATE PROTECTION AND BACK-UP OF ANY DATA USED IN CONNECTION WITH THE SOFTWARE SOLUTION. IN NO EVENT SHALL CITRIX BE LIABLE FOR (i) SPECIAL, INDIRECT, DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, OR (ii) ANY OTHER CLAIM, DEMAND OR DAMAGES WHATSOEVER RESULTING FROM OR ARISING OUT OF OR IN CONNECTION WITH THE SOFTWARE SOLUTION, WHETHER AN ACTION IN CONTRACT OR TORT, INCLUDING NEGLIGENCE, OR OTHERWISE.

    Related: