Navigation
- Change Log
- Overview
- AAA Virtual Server
- Login Schema
- Advanced Authentication Policies
- Authentication Policy Label
- nFactor for NetScaler Gateway
- Sample Configurations:
💡 = Recently Updated
Change Log
- 2018 Feb 4 – updated the Sample Configurations section to match the nFactor 12 article
Overview
nFactor lets you configure an unlimited number of authentication factors. You are no longer limited to just two factors. Each authentication factor performs the following tasks:
- nFactor requests credentials from the user. These credentials can be anything supported by NetScaler including:
- SAML
- Certificate
- oAuth
- Kerberos
- Forms-based authentication (traditional web-based logon page) for LDAP, RADIUS, etc.
- Multiple passwords can be collected with one form.
- Or prompt the user multiple times throughout the authentication chain.
- The logon page can contain a domain drop-down.
- nFactor evaluates the credentials. The results can be:
- Authentication success
- Authentication failure
- Group extraction
- Attribute extraction from SAML, Certificate, etc.
- Based on the evaluation results, do one of the following:
- Allow access
- Use authentication evaluation results to select next factor
- Deny access
- Multiple factor evaluations can be chained together. The chosen next factor is based on the results of the prior factor. This can continue indefinitely. The next factor can do one of the following:
- Prompt the user for more credentials
- Evaluate the already entered next set of credentials
- Use policy expression to select another next factor (no authentication). This is typically used with group extraction so that groups determine the next factor.
- NetScaler Gateway can perform Endpoint Analysis (EPA) and use the scan results to select nFactor authentication factors.
Here are some nFactor use cases, but the combinations are almost limitless:
- 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 certificate, or ask user for LDAP password. If LDAP, the username doesn’t need to be entered again.
- Ask for Certificate first:
- If certificate, perform LDAP only.
- If no certificate, perform LDAP + RADIUS
- Two-factor with passwords checked in specific order: 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 passes, perform LDAP only.
- If fails, perform LDAP + RADIUS
You configure nFactor in the AAA feature, and then bind it to NetScaler Gateway Virtual Servers. Because of AAA, NetScaler Enterprise Edition is required.
- Note: nFactor works with browser clients, but it does not work with Receiver Self-Service (native Receiver).
nFactor configuration summary (detailed instructions below):
- Each factor is a combination of Advanced Authentication Policies and Login Schema.
- Advanced policy means it uses an Advanced (Default Syntax) expression as opposed to the classic syntax expression traditionally used in NetScaler Gateway authentication policies.
- Login Schema is a custom HTML form where users enter credentials.
- The first factor (Advanced Authentication Policies and Login Schema) is bound directly to a AAA Virtual Server.
- Next factors are bound to Authentication Policy Labels. These Labels are then chained to Advanced Authentication Policies in prior factors.
- Authentication Profile links AAA nFactor with NetScaler Gateway.
Also see Citrix CTX222713 Concepts, Entities and Terms used for nFactor Authentication through NetScaler. 💡
AAA Virtual Server
Create AAA Virtual Server
To use nFactor with NetScaler Gateway, you first configure it on a AAA Virtual Server. Then you later bind the AAA Virtual Server to the NetScaler Gateway Virtual Server.
- If AAA feature is not already enabled, go to Security > AAA, right-click AAA, and Enable Feature.
- Go to Security > AAA > Virtual Servers.
- On the right, click Add.
- Give the Virtual Server a name.
- If you are only using this AAA Virtual Server for NetScaler Gateway, then you can change the IP address Type to Non Addressable. It’s also possible to content switch to AAA.
- Click OK.
- In the Certificates section, click where it says No Server Certificate.
- Click to select.
- Select 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.
- Click Bind.
- Click Continue.
- You probably don’t have any Advanced Authentication Policies yet, so just click Continue.
AAA Portal Theme
If this AAA Virtual Server is used not just for NetScaler Gateway, but also for traffic management (Load Balancing, Content Switching), then you might want to change the AAA Portal theme.
- Go to NetScaler Gateway > Portal Themes and add a theme.
- After adjusting it as desired, at the top of the portal theme editing page, Click to Bind and View Configured Theme.
- Change the selection to Authentication.
- Use the Authentication Virtual Server Name drop-down to select the AAA Virtual Server, and click Bind and Preview.
Client Certificate Authentication
If one of your authentication Factors is certificate, then you must perform some SSL configuration on the AAA Virtual Server:
- 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.
- Go to Security > AAA > Virtual Servers, and edit an existing AAA Virtual Server.
- On the left, in the SSL Parameters section, click the pencil icon.
- If you don’t see this section, then Default SSL Profiles are probably enabled. You’ll need to create a custom SSL Profile at System > Profiles > SSL Profile. Unfortunately, it’s not possible to bind the custom SSL Profile to AAA vServer using the GUI, but you can do it using the CLI (
set ssl vserver MyAAAvServerName -sslProfile MySSLProfileName
)
- Check the box next to Client Authentication.
- Make sure Client Certificate drop-down is set to Optional, and click OK.
- On the left, in the Certificates section, click where it says No CA Certificate.
- Click to select.
- Select the root certificate for the issuer of the client certificates, and click Select.
- 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 scenarios, users could be presented with multiple logon screens.
Or you can have one Factor gather information that can be passed on to later 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 proceed to the second 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 a Login Schema from being shown to the user, select noschema (LSCHEMA_INT) in the Authentication Policy Label.
Several Login Schema .xml files are included with NetScaler under /nsconfig/loginschema/LoginSchema.
NetScaler 11.1 lets you edit the labels from within the GUI. When the labels are changed, NetScaler copies the Login Schema to a new .xml file.
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 login schema can also 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.
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. For example:
Login Schema Profile
To configure a Login Schema Profile:
- Create or Edit a Login Schema .XML file based on your nFactor design.
- Go to Security > AAA > Login Schema.
- On the right, switch to the Profiles tab, and click Add.
- In the Authentication Schema field, click the pencil icon.
- Click the LoginSchema folder to see the files in it.
- Select one of the files. You can see a preview on the right. The labels can be changed by clicking the Edit button on the top right.
- When you Save the changes, a new file is created under
/nsconfig/LoginSchema
.
- On the top right, click Select.
- Give the Login Schema a name, and click More.
- You typically need to use the entered credentials elsewhere. For example, you might need to use the username and one of the passwords to later Single Sign-on to StoreFront. Near the bottom of the Login Schema Profile, enter unique values for the indexes. These values can be between 1 and 16.
- You can also configure these values on your noschema profiles so that passwords received from a previous factor can be put into a different Index.
- Later you reference these index values in a Traffic Policy/Profile by using the expression HTTP.REQ.USER.ATTRIBUTE(#).
- Click Create.
- Note: if you later edit the Login Schema .xml file, the changes might not be reflected until you edit the Login Schema Profile and select the .xml file again
Login Schema Policy
Login Schemas can be bound directly to a AAA Virtual Server. If one of the Advanced Authentication policies bound directly to the AAA Virtual Server is forms-based, then bind the Login Schema directly to the AAA Virtual Server. If you are binding the Login Schema directly to a AAA Virtual Server, then you must first create a Login Schema Policy expression that is linked to the Login Schema Profile.
Or Login Schemas can be bound to an Authentication Policy Label (described later). If you are binding a Login Schema to an Authentication Policy Label, then there’s no need to create a Login Schema policy expression.
To create and bind a Login Schema Policy:
- On the left, go to Security > AAA > Login Schema.
- On the right, switch to the Policies tab, and click Add.
- Use the Profile drop-down to select the Login Schema Profile you already created.
- Enter a Default Syntax expression in the Rule box, and click Create.
- On the left, go to Security > AAA > Virtual Servers, and edit an existing AAA Virtual Server.
- On the right, in the Advanced Settings column, click Login Schemas.
- On the left, in the Login Schemas section, click where it says No Login Schemas.
- Click to select.
- Select the Login Schema policy, and click Select. Only Login Schema Policies appear in this list. Login Schema Profiles (without a policy) do not appear.
- Click Bind.
Advanced Authentication Policies
Authentication policies are a combination of policy expression and policy action. If the expression is true, then evaluate the action.
The Action is always an authentication server (LDAP, RADIUS, etc.).
The policy expression can be either in classic syntax, or in the newer default syntax.
The policy type is either Basic or Advanced. Basic policies can only use classic syntax. Advanced policies only use the newer default syntax. Both types of policies use the same Actions (authentication servers).
nFactor requires Advanced Authentication Policies; Basic policies won’t work.
Create Advanced Authentication Policy
You will need Authentication Actions/Servers (e.g. LDAP, RADIUS, CERT, SAML, etc.)
When creating an Advanced Authentication Policy, there’s a plus icon that lets you create Authentication Actions/Servers.
Or you can create Authentication Actions prior to creating the Advanced Authentication Policy. The Authentication Actions are located under the Security > AAA > Policies > Basic Policies > <Action Type> node. On the right, switch to the Servers tab to create the Actions/Servers. Once the Actions are created, use the instructions below to create the Advanced Authentication Policy. There’s no need to create a Basic Authentication Policy.
To create an Advanced Authentication Policy:
- Go to Security > AAA > Authentication > Advanced Policies > Policy.
- On the right, click Add. You typically create at least one Authentication Policy for each Factor. When you create multiple Authentication Policies for one Factor, NetScaler checks each policy in priority order until one of them succeeds.
- Use the Action Type drop-down to select the Action Type (e.g. LDAP). The Action Type depends on your nFactor flow design.
- If you don’t currently have any Actions configured, of if you want to create a new one, click the plus icon next to the Action drop-down. The Actions/Servers are created in the normal fashion.
- 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. Click Create when done.
- Create more Advanced Authentication Policies as needed for your nFactor design.
Bind Advanced Authentication Policy to AAA
Only the Advanced Authentication Policies for the first Factor are bound directly to the AAA Virtual Server. The Advanced Authentication Policies for the remaining Factors are bound to Authentication Policy Labels as detailed in the next section.
- Go to Security > AAA > Virtual Servers.
- Edit an existing AAA Virtual Server.
- On the left, in the Advanced Authentication Policies section, click where it says No Authentication Policy.
- Click to select.
- Select the Advanced Authentication Policy, and click Select.
- 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.
- 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 Factor is evaluated. If it is set to END, of if there are no more Advanced Authentication Policies bound to this Factor, then authentication is finished and marked as failed.
- Click Bind.
LDAP Group Extraction
Sometimes you only want to extract a user’s groups from Active Directory, but have don’t actually want to authenticate with LDAP. These groups can then be used to select the next authentication Factor.
To configure an LDAP Action/Server for only group extraction:
- When creating or editing an LDAP Server, make sure Authentication is unchecked.
- Make sure Group Attribute and Sub Attribute Name are filled in.
Authentication Policy Label
When configuring the first Factor, you bind two objects to the AAA Virtual Server:
- Login schema – for forms-based authentication
- Advanced Authentication Policy
When binding the Advanced Authentication Policy to the AAA Virtual Server, there’s a field to Select Next Factor. If the Advanced Authentication Policy succeeds, then the Next Factor is evaluated.
The Next Factor is actually an Authentication Policy Label.
Authentication Policy Labels contain three objects:
- Login Schema
- Advanced Authentication Policies
- Next Factor – the next Authentication Policy Label
Here’s the flow:
- User connects to AAA or NetScaler Gateway Virtual Server.
- If forms-based authentication, the Login Schema bound to the AAA Virtual Server is displayed.
- Advanced Authentication Policies bound to the AAA Virtual Server are evaluated.
- If the Advanced Authentication Policy is successful, go to the configured Next Factor, which is an Authentication Policy Label.
- If Next Factor is not configured, then authentication is complete and successful.
- If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
- If none of the Advanced Authentication Policies are successful, then authentication failed.
- If the Advanced Authentication Policy is successful, go to the configured Next Factor, which is an Authentication Policy Label.
- If the Next Factor Authentication Policy Label has a Login Schema bound to it, display it to the user.
- Evaluate the Advanced Authentication Policies bound to the Next Factor Authentication Policy Label.
- If the Advanced Authentication Policy is successful, go to the configured Next Factor, which is an Authentication Policy Label.
- If Next Factor is not configured, then authentication is complete and successful.
- If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
- If none of the Advanced Authentication Policies are successful, then authentication failed.
- If the Advanced Authentication Policy is successful, go to the configured Next Factor, which is an Authentication Policy Label.
- Continue evaluating the Next Factor Authentication Policy Label until authentication succeeds or fails. You can chain together an unlimited number of Authentication Policy Labels.
If you are binding a Login Schema to an Authentication Policy Label, then you only need the Login Schema Profile. There’s no need to create a Login Schema Policy.
Not every Factor needs a Login Schema (logon page). 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:
- Authentication Policy Labels are configured at Security > AAA > Policies > Authentication > Advanced Policies > PolicyLabel.
- On the right, click Add.
- Give the Policy Label a name.
- Select a Login Schema Profile. This can be one that is set to noschema if you don’t actually want to display anything to the user. Then click Continue.
- In the Policy Binding section, Click to select.
- Select an Advanced Authentication Policy that evaluates this Factor. Click Select.
- 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.
- In the Select Next Factor field, if you chain another Factor, Click to select, and bind the next Authentication Policy Label (Next Factor).
- Or don’t select anything, and if this Advanced Authentication Policy succeeds, then authentication is successful and complete. This ends the chaining.
- Click Bind when done.
- You can click Add Binding to add more Advanced Authentication Policies to this Policy Label (Factor). Or you can bind Advanced Authentication Policies to the next Policy Label (Next Factor). Click Done.
Bind Authentication Policy Label
Once the Policy Label (Factor) is created, you bind it to an existing Advanced Authentication Policy binding. This is how you chain Factors together.
- Either edit an existing AAA Virtual Server that has an Advanced Authentication Policy already bound to it.
- Or edit a different Authentication Policy Label.
- On the left, in the Advanced Authentication Policies section, click the bindings.
- Click the ellipsis next to an existing binding, and click Edit Binding.
- In the Select Next Factor field, Click to select.
- Select the Policy Label for the Next Factor, and click Select.
- Click Bind.
- Click Close.
nFactor for NetScaler Gateway
AAA Authentication Profile
Authentication Profile lets you bind a AAA Virtual Server to NetScaler Gateway. This is what enables nFactor on NetScaler Gateway.
- Go to NetScaler Gateway > Virtual Servers.
- On the right, edit an existing Gateway Virtual Server.
- Note: the new RfWebUI theme seems to interfere with Login Schema rendering. Consider changing your Gateway Portal Theme to X1 instead.
- On the right, in the Advanced Settings section, click Authentication Profile.
- On the left, click the plus icon next to the Authentication Profile drop-down.
- Give the Authentication Profile a name.
- In the Authentication Virtual Server field, Click to select.
- Select the AAA Virtual Server that has Login Schema, Advanced Authentication Policy, and Authentication Policy Labels configured. The AAA Virtual Server does not need an IP address. Click Select.
- Then click Create.
- And click OK.
- 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.
- When you browse to your Gateway, you’ll see the nFactor authentication screens.
Unified Gateway
If you have Unified Gateway (Content Switch in front of NetScaler Gateway), then edit the Content Switching policy and add the following expression:
|| HTTP.REQ.URL.STARTSWITH("/nf")
Gateway Client Certificate Authentication
If one of your authentication Factors is certificate, then you must perform some SSL configuration on the NetScaler Gateway Virtual Server:
- 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.
- Go to NetScaler Gateway > Virtual Servers, and edit an existing NetScaler Gateway Virtual Server that is enabled for nFactor.
- On the left, in the SSL Parameters section, click the pencil icon.
- Check the box next to Client Authentication.
- Make sure Client Certificate drop-down is set to Optional, and click OK.
- On the left, in the Certificates section, click where it says No CA Certificate.
- Click to select.
- Select the root certificate for the issuer of the client certificates, and click Select.
- Click Bind.
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, then you need to create a Traffic Policy/Profile to override the default nFactor behavior.
- Go to NetScaler Gateway > Policies > Traffic.
- On the right, switch to the Traffic Profiles tab.
- Click Add.
- Give the Traffic Profile a name.
- In the Protocol section, select HTTP.
- Enable Single Sign-on. Scroll down.
- In the SSO Expression fields, enter an HTTP.REQ.USER.ATTRIBUTE(#) expression that matches the indexes specified in the Login Schema.
- Click Create.
- On the right, switch to the Traffic Policies tab, and click Add.
- Give the policy a name.
- Select the previously created Traffic Profile.
- Enter a classic expression (e.g. ns_true) and click Create.
- Edit an existing NetScaler Gateway Virtual Server.
- Scroll down to the Policies section and click the plus icon.
- Select Traffic > Request, and click Continue.
- Select the previously created Traffic Policy and click Bind.
Endpoint Analysis and nFactor
When combining nFactor with NetScaler Gateway (or Universal Gateway), you can use Endpoint Analysis scans to control nFactor flow.
- Create a Preauthentication Profile (NetScaler Gateway > Policies > Preauthentication > Preauthentication Profiles).
- In the Default EPA Group field, enter a new group name. If the EPA scan succeeds, users are added to this group. This group name can then be used later in policy expressions (e.g. HTTP.REQ.USER.IS_MEMBER_OF(“Corporate”))
- Switch to the Preauthentication Policies tab and add a policy.
- Give the policy a name and select the Preauthentication Profile.
- Configure the EPA expression by using the OPSWAT EPA Editor or Expression Editor links on the right. More details at https://www.carlstalhood.com/smartaccess-smartcontrol-netscaler-11-1/#epa.
- You can create a Preauthentication Policy with expression ns_true to capture all failed EPA scans. The Preauthentication Profile would place users in EPA group that indicates the scans failed.
- Edit your Gateway vServer, scroll to the Policies section, and click the plus icon to bind the Preauthentication policies.
- If you have a catchall (ns_true) Preauthentication Policy, make sure it has the highest priority number so it is evaluated last.
- In your 1st factor AAA Advanced Authentication Policies, use expressions similar to HTTP.REQ.USER.IS_MEMBER_OF(“MyEPAGroup”). The group name should match whatever group name you specified in the Preauthentication Profile.
- For the 1st factor, bind the Advanced Authentication Policies directly to the AAA vServer. Configure the Next Factor based on your nFactor design (e.g. Next Factor = RADIUS if EPA fails).
- In your Login Schema Policies (1st factor), use the same type of expression.
- For the 1st factor, bind the Login Schema Policies directly to the AAA vServer.
- See below for a sample EPA / nFactor configuration.
Note: if the user skips the EPA scan, then this message will be displayed. This appears to be a limitation of EPA with nFactor.
Sample Configurations
From Citrix Docs: Sample deployments using nFactor authentication:
- Get two passwords up-front, pass-through in next factor. Read
- Username and 2 passwords with group extraction in third factor. Read
- Configure nFactor to process the second password before the first password, Read
- Modify first factor username for 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 group. Read
- Google reCAPTCHA first factor, LDAP second. Read (George Spiers)
- Supporting reCaptcha with NetScaler nFactor. Read
- CTX225938 nFactor – Customizing UI to Display Images – e.g. Swivel
- 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
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:
- User connects to NetScaler Gateway.
- NetScaler Gateway asks user for certificate.
- If user selects a certificate, NetScaler Gateway compares certificate signature to the CA certificate that is bound to the NetScaler Gateway. If it doesn’t match, then user certificate is ignored.
- Bound to the NetScaler Gateway Virtual Server is an Authentication Profile, which links NetScaler Gateway to AAA nFactor.
- Certificate authentication: The lowest priority number authentication policy on the AAA Virtual Server is Certificate. If there’s a valid user certificate:
- Extract the user’s userPrincipalName from the certificate.
- Next Factor = policy label that displays a logon screen (Single-factor Login Schema)
- The username field is pre-populated with the userPrincipalName attribute extracted from the certificate.
- User is prompted to enter the LDAP password only.
- LDAP policy/server is configured to use userPrincipalName to login to LDAP.
- If successful, NetScaler Gateway authentication is complete. Next step is to Single Sign-on to StoreFront.
- If LDAP authentication fails, then NetScaler Gateway authentication fails, and the user is prompted to try LDAP-only authentication again.
- LDAP authentication: If certificate authentication fails, try next authentication policy bound to the AAA Virtual Server, which is a different LDAP Policy.
- Bound to the AAA Virtual Server is a Dual Factor Login Schema that asks for username, LDAP password, and RADIUS password.
- LDAP policy/server is configured to use sAMAccountName to login to LDAP. SAMAccountName means users don’t have to enter full userPrincipalName.
- If LDAP authentication is successful:
- 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.
- Proceed to next factor (Policy Label), which is RADIUS.
- If LDAP authentication fails, NetScaler Gateway login fails, and the user is prompted to try two-factor authentication again.
- 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.
- 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).
- RADIUS policy/profile attempts authentication.
- If RADIUS authentication is successful, NetScaler Gateway authentication is complete. Next step is Single Sign-on to StoreFront.
- If RADIUS authentication fails, NetScaler Gateway login fails, and the user is prompted to try two-factor authentication again.
- Single Sign-on to StoreFront: NetScaler 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.
- Bound to the NetScaler Gateway Virtual Server is a Traffic Policy.
- 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 doesn’t match the authentication flow because some objects have to be created before others.
# 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
Enpoint Analysis Scan: If succeed, LDAP only. If fails, LDAP+RADIUS.
The authentication process flows like this:
- User connects to NetScaler Gateway.
- The Gateway has Preauthentication Policies, which causes Endpoint Analysis scan to occur.
- Preauthentication Profiles put users in different AAA Groups depending on results of the scan.
- The Login Schema Policies bound to the AAA vServer have user group expressions based on the Preauthentication Profile EPA Groups.
- If scan passed (Corporate group), show Login Schema with one password only.
- If scan failed (NonCorporate group), show Login Schema with two password fields.
- The Advanced Authentication Policies bound to the AAA vServer have user group expressions based on the Preauthentication Profile EPA Groups.
- If scan passed (Corporate group), evaluate LDAP password only. No Next Factor.
- If scan failed (NonCorporate group), evaluate LDAP, then Next Factor to RADIUS Policy Label.
Here’s a sample config:
# Two Login Schema Profiles - one with one password only, one with two passwords add authentication loginSchema TwoFactor -authenticationSchema "/nsconfig/loginschema/DualAuth_new.xml" -userCredentialIndex 1 -passwordCredentialIndex 2 add authentication loginSchema LDAPOnly -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuth.xml" # Login Schema Policies based on EPA Groups add authentication loginSchemaPolicy NonCorporateSchema -rule "http.REQ.USER.IS_MEMBER_OF(\"NonCorporate\")" -action TwoFactor add authentication loginSchemaPolicy CorporateSchema -rule "http.REQ.USER.IS_MEMBER_OF(\"Corporate\")" -action LDAPOnly # LDAP Action 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 -nestedGroupExtraction ON -groupNameIdentifier sAMAccountName -groupSearchAttribute memberOf -groupSearchSubAttribute CN # Two LDAP Policies based on EPA Groups. Same Action for each. add authentication Policy NonCorporateLDAP -rule "http.REQ.USER.IS_MEMBER_OF(\"NonCorporate\")" -action LDAP-Corp add authentication Policy CorporateLDAP -rule "http.REQ.USER.IS_MEMBER_OF(\"Corporate\")" -action LDAP-Corp # RSA Action add authentication radiusAction RSA -serverIP 10.2.2.42 -serverPort 1812 -radKey MyKey -accounting ON add authentication Policy RSAAdv -rule true -action RSA # RSA Policy Label for Next Factor add authentication policylabel Non-Corporate-RADIUS -loginSchema LSCHEMA_INT bind authentication policylabel Non-Corporate-RADIUS -policyName RSAAdv -priority 100 -gotoPriorityExpression NEXT # AAA vServer add authentication vserver aaanFactor SSL 0.0.0.0 # AAA vServer - bind Login Schema Policies bind authentication vserver aaanFactor -policy CorporateSchema -priority 100 -gotoPriorityExpression END bind authentication vserver aaanFactor -policy NonCorporateSchema -priority 110 -gotoPriorityExpression END # AAA vServer - bind LDAP Auth Policies. Failed EPA has Next Factor configured. bind authentication vserver aaanFactor -policy CorporateLDAP -priority 100 -gotoPriorityExpression NEXT bind authentication vserver aaanFactor -policy NonCorporateLDAP -priority 110 -nextFactor Non-Corporate-RADIUS -gotoPriorityExpression NEXT # Preauth Profiles have EPA Groups (AAA Groups) defined add aaa preauthenticationaction Corporate ALLOW -defaultEPAGroup Corporate add aaa preauthenticationaction NonCorporate ALLOW -defaultEPAGroup NonCorporate # Preauth Policies use EPA Expressions. ns_true captures all failed EPA scans. add aaa preauthenticationpolicy CorporateEPA "CLIENT.SYSTEM(\'DOMAIN_SUFFIX_anyof_corp.local[COMMENT: Domain check]\') EXISTS" Corporate add aaa preauthenticationpolicy NonCorporate ns_true NonCorporate # Authentication Profile add authentication authnProfile nFactor-Gateway -authnVsName aaanFactor # Gateway vServer - Create and bind Auth Profile add vpn vserver UG_VPN_UG SSL 0.0.0.0 -dtls ON -loginOnce ON -Listenpolicy NONE -tcpProfileName nstcp_default_XA_XD_profile -appflowLog ENABLED -authnProfile nFactor-Gateway # Gateway vServer - Bind Preauthentcation Policies bind vpn vserver UG_VPN_UG -policy CorporateEPA -priority 100 bind vpn vserver UG_VPN_UG -policy NonCorporate -priority 110 # Gateway vServer - Bind Traffic Policy for SSON to StoreFront bind vpn vserver UG_VPN_UG -policy nFactorSSO -priority 100 # Gateway vServer - remaining configuration is normal (session policies, STA, SSL cert, etc.)
Hi Carl , thank you for this great article
we have a requirement where the first screen should display user name and password (LDAP authentication) and post authentication if the user is an admin user they should be prompted with next authentication (RSA) if not the user should be able to login.
Please let me know the high level configuration to achieve this.
Bind LDAP to the AAA vServer.
Next Factor is a policy label with two noauth policies. First noauth checks for admins. If true, then it has a Next Factor for RSA. Second noauth is just “true” for people that don’t match the first noauth.
Hello Carl,
Can we implement CAPTCHA for an application that is configured as LB Vserver or CS Vserver? All I’m finding is configuring CAPTCHA for NetScaler Gateway.
Thanks in advance!!
nFactor is configured on a AAA vServer, which can be used to authenticate LB and CS vServers.
Hi Carl
Another great write-up! Hope you can help with this query?…I have a 3 factor setup,
1st factor gives the standard login page, contacts LDAP and retrieves the attribute “pwdLastset”.
2nd factor runs an expression based on this attribute and has a “noschema”.
3rd factor then simply displays a message (via another Loginschema) to the user depending on the results of the expression. No authentication prompts.
Once the user clicks “Continue” on the 3rd factor it opens up the Storefront page, but gives “Cannot Complete your request”.
I can access the gateway URL from the storefront server.
if I unbind the AAAVserver from the Gateway and then bind the LDAP policy to the gateway (so not using AAAvserver) the connection works fine.
Any suggestions?
Thanks
Kal
Did you also configure the Traffic Policy with the HTTP.REQ.USER.ATTRIBUTE that contains the user’s password?
Ok i may have set this up the incorrect way, but I have a Traffic policy which is bound to the gateway. This contains the expression ” HTTP.REQ.USER.ATTRIBUTE(1) ” within both the User and Password expressions. I have then configured the 3rd factor login schema with a ” 1″ in both the user and password Credential Index Fields.
3rd factor is the one with the user’s AD password?
What are you seeing in StoreFront Server > Event Viewer > Applications and Services > Citrix Delivery Services?
Carl,
Great content as always! I’m looking to create the following workflow, do you thinks it is achievable with nFactor on 11.1?
1. User goes to Access Gateway URL
2. Access Gateway is bound to Content Switch VServer
3. User is challenged for Username
A. If user is member of Group X then challenge for Password
a. User is granted access to Clientless Applications only
B. If user is member of Group Y then challenge for Password and RSA Pin
b. User is granted access to Clientless Applications and Citirx Receiver Applications (ICA Proxy)
4. Wold Peace suddenly ensues.
NFactor can certainly ask for different factors for members of different AD groups. First factor is LDAP group extraction only. Then next factor is based on HTTP.REQ.USER.IS_MEMBER_OF.
If the same users get the same Session Policy every time they connect, then that’s a simple matter of creating AAA Groups on the NetScaler that match the AD groups, and then linking Session Policies to those AAA Groups.
Thank you for this! Seems LDAP extract has to be first factor, otherwise results in a file download behavior. Had a different combination and couldn’t get it working until LDAP extract was first factor.
Hi Carl
Great article!
Maybe you can give some hints.
Environment:
– NetScaler release NS11.1 53.11.nc
– Authentication Virtual Server for form based authentication
– Portal theme configured and bound to the authentication virtual server -> set to German language
– Login schema configured and bound to the authentication virtual server, to get a customized form based login site
– Login schema xml file has been edited, to replace english words with german ones (Username -> Benutzername / Password -> Kennwort / Logon -> Anmelden)
This is working as needed, except if the username/password are entered incorrectly. In that case the resulting error message is displayed again in English “Try again or contact your help desk”. I have to change it to German. As the error message is displayed dynamically, there’s no way to include it directly in the login schema xml file.
Is this a bug? Is there any way to use a rewrite policy / action to change the error message text, and how in detail has it to be configured (type / exact syntax)? The browser shows the “doAuthentication.do” file (F12 in Internet Explorer), which contains the error message.
.
.
ERRORnoneTry again or contact your help deskerror
Hey Carl: Is there a way to allow only trusted devices connect through Netscaler and connect to SaaS based App, maybe something like only allowing domain joined company devices/company owned machines connect to SaaS Salesforce App using SAML. We don’t want personal devices connect to salesforce App
NetScaler 12 has native support for EPA in nFactor.
Hello Carl:
Thanks for the quick response
Would it be possible to leverage private Certs(generated using internal CA) on domain based machines and allow them access to Netscaler11 UG and then use SAML for SaaS Apps. So if a personal machine connects through Gateway vServer without those certs we block them or fail authentication.
Thanks
Of course. If the certs are user-based, then simply go to SSL Parameters and enable client certificate authentication. If they are device certs, then you need Endpoint Analysis and NetScaler Gateway.
Hello,
Is nFactor supported with Citrix Receiver?
Thanks,
Yunier
Kind of. 11.1 build 52 and later adjusts nFactor Login Schemas to use the language that Receiver expects. https://support.citrix.com/article/CTX223386
I’ve implemented as you explain above, in order to prompt for UPN/password, i then LDAP auth and then MFA auth. I only have one Schema applied to gather UPN/PW…the next screen “Loading Apps”. I’d like to apply a Schema to the MFA policy label so that just info is displayed. Something like “Notification sent to mobile device. Respond to that notice to complete the login process.” User would not take any action on this Schema and the factor would end after MFA notice is acknowledged. It seems using the provided .xmls, I never get to the second auth since it’s waiting for user input. Even if I delete most of the content in the xml file and just list my information to display. Is it possible to just have an info Schema and have the next factor process while info Schema is displayed to user?
Have you tried binding the NO_AUTHN policy to the label that includes your Login Schema?
I have not. I’m not finding anything around NO_AUTHN policy. Do you have any details on what the action/expression for that would be? I have my MFA pol bound to the label using the LSCHEMA_INT (which gives the results I mentioned above).
Create an Advanced Auth Policy with expression true. Select the NO_AUTHN Server. Bind it to the same label.
I may not have my relationships/bindings correct here. On my AAA server, I have Adv Auth Pol for LDAP. In that binding, I have Next Factor = Label1. In Label1, I have Login Schema = noresponse_schema (display the info to user) and I have MFA pol (priority=100, NEXT) then NO_AUTHN pol (priority = 110, END). I also reversed these two policies (NO_AUTHN the MFA) but still no dice. NS auth logs show that ldap completes, but my UPN never gets passed to MFA. All I see on the login screen is a blank theme page. I’m starting to think an easy workaround is to just change the “First Factor” blurb to be the info I want to display to the user. 🙂
I made it a little further…I created an Info_pol_label which using a schema xml file which only displays one sentence. I’ve bound the Info_pol_label as a Next Factor with an MFA auth policy bound. When i do this, I get the info page, but aaad.debug shows my UPN never gets passed to the MFA auth server so login dies at that point. If I switch to my other MFA_label which uses no schema all works fine and I see UPN pass to MFA. So it doesn’t like something about the use of that label/info schema. Any help or where to look next, is appreciated!
Might also be interesting: If you use certificate auth in a non-first factor, you can delay requesting the client certificate until the moment the certificate factor is required. For this to work the Gateway vServer and AAA vServer must have SSL profile that allows SSL Renegotiation and has Client Authentication DISABLED
In ‘Login Schema’ section you talk about customizing the xml that is used in the web form based sign-on to the NS, that’s great for that form and tuning the prompts is helpful…it appears though that the gateway plug-in has hardcoded html nsload.exe and that prompt did not change when the schema is updated. Is there some other mechanism required to override the text in nsload.exe?
Carl, is there a way to set up a Cert auth and if no cert is found then to fallback into generating a certificate? Are we talking SAML/FAS in that type of scenario? I will confess right away that I don’t know much about the SAML/FAS setup other than it seems to be the swiss army knife of authentication with tons of stuff plugging into it.
My ultimate goal is to completely migrate away from passwords as I have users authenticating remotely with many other credentials they have to take care of and its starting to fall apart and they keep asking me via telephone to reset their passwords. Prime phishing land.
FAS will generate temporary certificates for users. These certificates are used to login to Windows. All that’s required is that StoreFront receive a username that matches an AD account UPN.
With regard to the certificate issued, you said its temporary. Is a password required to re-authenticate every session or something like that? I would ideally like to issue certs for a year, most of these to users that don’t have domain joined PC’s. Is that possible?
The FAS certificate logs the user into the VDA. Once on the VDA, the user has a Kerberos ticket that can be used to access other Kerberos auth systems (e.g. File shares).
If you want to push certs to Windows client devices not in a domain, that’s what MDM is for (e.g. Intune). 🙂
Hi Carl,
and thank you for your awesome site! number 1 citrix-related site on the web 🙂
I tried to implement nfactor as you explained, cert+ldap, or ldap+radius, on an unified gateway vserver.
I first made it work with basic auth policies, LDAP + RADIUS.
With nFactor I have a SSO problem to Storefront with LDAP + RADIUS in nfactor:
I can login with my credential and token, but on the client choice page, when I click on the “xenapp” tile I get the ” cannot complete your request” error.
in the event viewer of my storefront server, i have a sequence of 3 events when I try to access storefront via the gateway:
– “citrix domain services” id 1:
An authentication attempt was made for user: JOHN that resulted in: Failed (Windows Error Code: 1326) Password expiry information was requested but none was returned.
– “citrix authentication service” id 7 :
Échec de l’authentification unique CitrixAGBasic car la vérification des informations d’identification a échoué. Raison : Failed. Les informations d’identification fournies étaient ;
user : john
domaine : internaldomain.lan
(sorry for french, can’t find the translation)
– “Citrix Receiver for Web” id 10:
A CitrixAGBasic Login request has failed, (long text i can post) with a forbidden 403
I double checked with KB and howtos around, but can’t find anything.
I’m Netscaler platinum 11.1 51.10, storefront 3, xenapp 7.12, all fresh installs
sincerely
Did you create the Traffic Policy with the Authentication Attribute number? https://www.carlstalhood.com/nfactor-authentication-for-netscaler-gateway-11-1/#nfactorsson
hi Carl,
I solved it just now 🙂
i my login schema profile for ldap + radius, i have to set
user cred index: (none)
password cred index: 1
and in my traffic policy for storefront SSO:
SSO user expression; (none)
SSO pwd expression: http.req.user.attribute(1)
thank you !
best regards,
Bertrand
Can you please share what exact syntax was changed?
Hey Carl
Is there anyway to do LDAP only or LDAP + Radius based on source IP address. Bassiclly whitelisting certain IP addresses so they will not have to use radius. Since its possable todo cert and then LDAP + Radius I’m thinking yes but I’m having a hard time with the flow.
Thanks!
If you do them as two separate Login Schemas – one for LDAP, and a different one for RADIUS. So 1st policy has client IP expression. If true, evaluate LDAP and no Next Factor. Second policy evaluates LDAP, and if true, then has Next Factor for RADIUS with 2nd Login Schema.
Hi Carl,
can you confirm that loginschemas are missing on a brand new 11.1 VPX installation under /nsconfig/loginschema/?
The folder is empty and under Security – AAAApplicationTraffic – Login Schema – Profiles there are no xml files/ templates for loginschemas.
Yep. I reported it and they escalated it as a bug.
Awesome. Well … not really. Actually I mean that you can confirm it.
Is there another ressource to download the login schemas?
On a old instance of 11.0 I also didn’t finde any? 🙁
They should be on your appliance. Also, the many KB articles I linked to each have login schema downloads.
Hey Carl,
Thanks for the article. Are you able to clarify a couple things for me in regards to Client Certificate fallback mechanisms and where things need to be bound? I have a Content Switch sitting in front of several websites that I want to configure with a single AAA vServer doing a smart card check, with fallback to LDAP form if a certificate is not present. I want to eventually translate to kerberos on the backend afterwards.
I’ve got my AAA vServer up with my cert policy to check subjectaltname set with GOTO=NEXT and Next Factor as nothing. I also have my LDAP policy bound at a lower priority so if the certcheck fails it will go to the LDAP policy.
Where am I supposed to bind my loginschema for this type of configuration, and for which of those policies should I be creating a PolicyLabel (if any)? The documentation at http://support.citrix.com/article/CTX201734 doesn’t seem to be comprehensive.
Login Schema goes on the AAA vServer. It’s used by the LDAP policy, if you’re using forms-based auth instead of 401.
It doesn’t look like you need a PolicyLabel. If cert succeeds, then you’re done. If cert fails, try LDAP. If LDAP succeeds, then you’re done.
The link you posted doesn’t have fallback auth if cert auth fails.