nFactor authentication with NetScaler Unified Gateway

nFactor authentication with NetScaler provides a way to configure flexible, agile multi-factor authentication schemas based on factors such as who is connecting and from where users are connecting from or if users fail authentication. This allows NetScaler to provide authentication based on many different use cases and scenarios to provide secure access to backend applications and desktops.

nFactor is supported on NetScaler 11.0 build 62.x and onwards for Traffic Management use cases but 11.1 saw nFactor support added for NetScaler Gatway.

nFactor is also supported on Workspace app for Windows, and Workspace app for Mac when Citrix Gateway is running version 12.1.49.x.

With nFactor you can configure many numbers of authentication factors for users connecting based on location, corporate devices, non-corporate devices, employee status, group membership and so on. Take an example where users are connecting from non-corporate devices. You may like users to receive three factors of authentication. For corporate devices connecting in, let’s apply only two factors. If a device has a corporate certificate, extract the username from the certificate and only ask for the password. If the user device does not have a corporate certificate, ask for username, password and a token code.

Another example scenario could be around users from different domains connecting to NetScaler Gateway. Using a domains drop-down box, the selected domain can determine how many factors of authentication a user will now receive. Authentication portals can also be designed based again on the user so for example contractor users can be shown a different logon page than company employees.

Google reCaptcha with LDAP as next factor https://jgspiers.com/netscaler-nfactor-authentication-google-recaptcha-first-ldap-second-factor/

nFactor supports local authentication, RADIUS, LDAP, OAuth, TACAS, Certificates, SAML, Negotiate, Web and EPA.

Note: EPA Authentication Policies are only available in NetScaler 12.0.41.16 and above. EPA policies can only be bound to noschema Policy Labels. If you have non-EPA and EPA Authentication Policies attached to the same noschema Policy Label with expressions to filter what machines receive which Authentication Policy, EPA attempts to scan the machine regardless. You have to separate EPA authentication policies in to their own noschema Policy Labels.

Note: If creating an EPA action via the NetScaler 12.0.41.16 GUI, the expression generated is wrong and does not work. The expression should be the following: sys.client_expr(“sys_0_DOMAIN_SUFFIX_anyof_yourdomain.com”)
– This will be fixed in 12.0.51.x.

What do you need to get nFactor working?

  • An AAA vServer (NetScaler Enterprise or Platinum license supports AAA).
  • Authentication Profile – The Authentication Profile bound to a NetScaler Gateway vServer.
  • Login Schema – These are made up of XML files. These files are what makes up the GUI display to users logging on. It is possible to present multiple GUI logon screens to users using a multi-factor approach. A number of these files are located in /nsconfig/loginschema/LoginSchema by default. Additional files can be downloaded from Citrix or created by yourself. Citrix recommend you place Login Schemas you have created in /nsconfig/loginschema/. Login Schema files can be backed up by taking a Full NetScaler backup.1-min
  • Advanced Authentication Policies – Advanced Authentication Policies are composed of policy expressions and actions. An action can be an LDAP server, RADIUS, Certificate etc. This means that if the policy expression i.e. true is matched, the action is imposed on a user. For simplicity, we could bind an Advanced Authentication Policy which has the action of LDAP to an AAA vServer and this basically would present the connecting user (if expression is matched) with an LDAP authentication factor. nFactor can only use Advanced Authentication Policies and not Basic.
  • Basic Authentication Policies – Also composed of policy expressions and actions such as LDAP, Certificate or RADIUS etc. These Basic Policies contain server/profile/action entries that are normally associated with an Advanced Authentication Policy for nFactor use. It is not a requirement to actually create a Basic Policy (the policy section). Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Basic Policies -> LDAP -> Servers -> Add as an example of creating an LDAP server entry, which is then used within Advanced Authentication Policies for nFactor.
  • Policy Labels – Treat these as the secondary/user-defined factors of authentication. You can have any amount of Policy Labels/secondary factors of authentication. An Advanced Authentication Policy will link to a Policy Label which defines the next factor of authentication. Policy Labels are associated with a Login Schema. Multiple Authentication Policies can be bound to a Policy Label, and priorities associated.

Note on Login Schemas – There is a bug where no schema files exist in NSv11.1 build 47.14. This seems to be resolved in build 48.10. If you do not have schema files you can manually copy them from a working NetScaler version or download schema files from Citrix. Login Schema files can be modified, take a copy of an existing schema file and place the file in the /nsconfig/loginschema/ directory and edit using a basic text editor. Citrix recommend using this directory to store modified login schema files so that changes are preserved even after reboots.

Another option is to modify the file within the NetScaler GUI by selecting a schema file and clicking on Edit. 3-min

 

Make required modifications and click Save.4-min

Sample Scenario

  1. Users with a corporate user certificate are only asked for a password. The user’s username is extracted from the certificate.
    1. If user does not have a certificate, user is asked for username.
  2. User presents username, group extraction is performed.
    1. If users are in Azure Multi-Factor security group, user is presented with password only box, then Azure MFA is used as second factor.
    2. If user is not in Azure Multi-Factor security group, user is presented with RADIUS login schema, asking for password and token code. Username is prefilled from previous factor.

This post assumes you already have NetScaler Unified Gateway configured.

To get started create an AAA vServer. Navigate to Security -> AAA -> Application Traffic -> Virtual Servers -> Add. Set the address as Non Addressable.

Bind a certificate to the AAA vServer. It does not matter which certificate you use.

Create an Authentication Profile and bind the AAA vServer you just created to this new profile. Specify any Authentication Host name of your choice.

Edit the Unified Gateway vServer and under Authentication Profile choose the profile you have just created. Make sure no other authentication policies are attached to Unified Gateway. All authentication policies going forward will be configured on the AAA vServer.

If you browse to the NetScaler Unified Gateway URL you will likely get a Cannot complete your request message without any further configuration.

To fix, navigate to Traffic Management -> Content Switching -> Policies and edit the existing CSW policy.

 

Append || HTTP.REQ.URL.CONTAINS(“nf/auth”) to the expression. Click OK.

 

The first factor of authentication is client certificates, so we need to create an LDAP server that accepts User Principal Names as a logon username attribute. This is because the username is extracted from the certificate in UPN format. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Basic Policies -> LDAP -> Servers -> Add.

Configure each field as you normally would. Using a load balanced address for LDAP is recommended. Under Server Logon Name Attribute specify userPrincipalName.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Basic Policies -> Cert -> Profiles -> Add.

Check Two Factor and under User Name Field make sure SubjectAltName:PrincipalName is selected.

You have to create Advanced Authentication Policies for both the CERT and LDAP actions you have just created. The Authentication Policies are then attached to the AAA vServer. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

For LDAP, choose the LDAP action you have just created. With an expression of true, click Create.

Also for CERT, choose the certificate action, use an expression of true and click Create.

To extract the username from a client certificate you can use a Login Schema. Mentioned at the beginning, Login Schemas are XML files which control the look and feel for each factor. Citrix have created XML schemas for many use cases including certificate username extraction. I have copied the schemas I need to separate files and made some slight adjustments. The certificate username extraction XML file I am using is pasted below. The schema is called CertExtract.xml.

Username Certificate Extraction XML code:

<?xml version="1.0" encoding="UTF-8"?>
<AuthenticateResponse xmlns="http://citrix.com/authentication/response/1">
<Status>success</Status>
<Result>more-info</Result>
<StateContext />
<AuthenticationRequirements>
<PostBack>/nf/auth/doAuthentication.do</PostBack><CancelPostBack>/Citrix/Authentication/ExplicitForms/CancelAuthenticate</CancelPostBack><CancelButtonText>Cancel</CancelButtonText>
<Requirements><Requirement><Credential><ID>login</ID><SaveID>ExplicitForms-Username</SaveID><Type>username</Type></Credential><Label><Text>Username</Text><Type>plain</Type></Label><Input><AssistiveText>Please supply either domain\username or user@fully.qualified.domain</AssistiveText><Text><Secret>false</Secret><ReadOnly>true</ReadOnly><InitialValue>${HTTP.REQ.USER.NAME}</InitialValue><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><ID>passwd</ID><SaveID>ExplicitForms-Password</SaveID><Type>password</Type></Credential><Label><Text>Password:</Text><Type>plain</Type></Label><Input><Text><Secret>true</Secret><ReadOnly>false</ReadOnly><InitialValue/><Constraint>.+</Constraint></Text></Input></Requirement>
<Requirement><Credential><Type>none</Type></Credential><Label><Text>Please enter your password</Text><Type>confirmation</Type></Label><Input /></Requirement>
<Requirement><Credential><ID>saveCredentials</ID><Type>savecredentials</Type></Credential><Label><Text>Remember my password</Text><Type>plain</Type></Label><Input><CheckBox>
<InitialValue>false</InitialValue></CheckBox></Input></Requirement><Requirement><Credential><ID>loginBtn</ID><Type>none</Type></Credential><Label><Type>none</Type></Label><Input><Button>Log On</Button></Input></Requirement></Requirements></AuthenticationRequirements>
</AuthenticateResponse>

Next bind the XML file to a Login Schema. Navigate to Security -> AAA – Application Traffic -> Login Schema -> Profiles -> Add.

Enter a name and then click the edit/pencil icon.

Select CertExtract.xml. You will be shown a preview of the XML Schema file and how it looks. Using the Edit button you can change some text labels, otherwise click Select.

Click Create.

The Login Schema is attached to a Policy Label. Policy Labels define which XML Login Schema is presented to the user and what types of authentication factors will be used to challenge the authenticating user. You can also link Policy Labels to additional Policy Labels for multiple factored levels of authentication which you will see later. For now, we have to bind the certificate extraction Login Schema and LDAP action to a Policy Label. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policy Labels -> Add.

Choose an appropriate name and under Login Schema select the certificate extraction Login Schema you just created. Click Continue.

Under Policy Binding click Click to select.

Choose the UPN LDAP Authentication Policy. Click Select.

Set Goto Expression to END. This simply means that if LDAP authentication fails, no other factor is considered. We aren’t using any additional factor anyhow so it doesn’t really matter. Click Bind.

The Authentication Policy Label shows as below. Users who connect are prompted for a certificate, if they successfully present one to NetScaler, the username is extracted and inserted in to the Cert-UserNameExtract-LoginSchemaProfile. LDAP is used as the second factor. At this stage we need to bind the certificate authentication policy and next-factor Policy Label to our AAA vServer.

Navigate and edit your AAA vServer. Under Advanced Authentication Poicies click No Authentication Policy.

Click Click to select.

Choose the certificate action.

Under Select Next Factor click Click to select.

Choose the Policy Label you just created for username extraction.

Keep Goto Expression as NEXT. Click Bind.

Click Done.

For client certificate authentication to work, we need to tell NetScaler to prompt for a certificate during the server & client SSL handshake. Navigate and edit your Content Switching vServer and click edit on SSL Parameters.

Check Client Authentication setting it to Optional. Optional allows non-corporate devices to fail certificate checking and receive the additional factors. Click OK.

The same must match on your Unified Gateway vServer. Set Client Authentication to Optional.

Bind your internal root CA certificate to the Content Switching Virtual Server. The NetScaler needs to be able to trust and verify the certificates being presented by your client. The user certificate must be scoped for Client Authentication and must include a private key. The Subject Alternate Name must match the user’s UPN.

Now upon browsing to the Unified Gateway URL, providing you have an appropriate user certificate, you are prompted to select one.

If the certificate is valid the username is extracted from the certificate and you are only asked for a password.

Enter the password and you are authenticated to NetScaler Unified Gateway.

You can also view the Policy Labels from NetScaler and notice the hit counter has increased. This informs you that the Policy Label including it’s authentication policies and Login Schema were used to authenticate this user account.

For those users who fail certificate authentication, we want to present them either with LDAP and Azure Multi-Factor Authentication or LDAP and RADIUS based on group membership. Firstly create an MFA LDAP action. For information on Azure MFA and how it integrates with NetScaler see https://jgspiers.com/azure-multi-factor-authentication-netscaler-unified-gateway/. Change the time out to a value that gives users time to complete the second factor phone prompt.

Create another LDAP server, this is simply for sAMAccountName attributes and will be used alongside RADIUS.

A final LDAP server should be created with Authetication unticked. This server will be used for Group Extraction purposes only. Group Extraction will be used to determine if the user is presented with LDAP/Azure MFA or LDAP/RADIUS.

You will end up with four LDAP servers in total.

  • LDAP-UserGroupExtraction – Used for Group Extraction only and accepts only a username.
  • LDAP-SAN – Used with RADIUS and accepts the sAMAccountName logon attribute.
  • LDAP-MFA – Used with Azure MFA, pointing LDAP requests to an internal MFA server.
  • LDAP-UPN – Used with certificate username extraction and accepts the userPrincipalName logon attribute.

Create Authentication Policies for each LDAP server you created.

UsernameOnly.xml schema will be used to determine who the user is. When a user browses to NetScaler Gateway and fails certificate authentication, they are presented with a username only Login Schema. Once they enter their username, group extraction is performed and next factor is LDAP/MFA or LDAP/RADIUS.

Username Only XML code:

<?xml version="1.0" encoding="UTF-8"?>
<AuthenticateResponse xmlns="http://citrix.com/authentication/response/1">
<Status>success</Status>
<Result>more-info</Result>
<StateContext></StateContext>
<AuthenticationRequirements>
<PostBack>/nf/auth/doAuthentication.do</PostBack>
<CancelPostBack>/nf/auth/doLogoff.do</CancelPostBack>
<CancelButtonText>Cancel</CancelButtonText>
<Requirements>
<Requirement><Credential><ID>login</ID><SaveID>ExplicitForms-Username</SaveID><Type>username</Type></Credential><Label><Text>Username</Text><Type>plain</Type></Label><Input><AssistiveText>Please supply either username as saamaccountname</AssistiveText><Text><Secret>false</Secret><ReadOnly>false</ReadOnly><InitialValue></InitialValue><Constraint>.+</Constraint></Text></Input></Requirement>
<Requirement><Credential><Type>none</Type></Credential><Label><Text> Please enter your username</Text><Type>confirmation</Type></Label><Input /></Requirement>
<Requirement><Credential><ID>saveCredentials</ID><Type>savecredentials</Type></Credential><Label><Text>Remember my password</Text><Type>plain</Type></Label><Input><CheckBox><InitialValue>false</InitialValue></CheckBox></Input></Requirement>
<Requirement><Credential><ID>loginBtn</ID><Type>none</Type></Credential><Label><Type>none</Type></Label><Input><Button>Log On</Button></Input></Requirement>
</Requirements>
</AuthenticationRequirements>
</AuthenticateResponse>

Next navigate to Security -> AAA – Application Traffic -> Login Schema -> Profiles -> Add.

Choose the UsernameOnly.xml Login Schema. Click Select -> Create.

Click Policies tab -> Add. Specify a name, choose the username only Login Schema you just created. Use an expression of true. Click Create.

Navigate to and edit your AAA vServer. Under Login Scemas click No Login Schema.

Choose the username only Login Schema. Click Select.

Click Done. Now when users fail certificate authentication, they receive the username only Login Schema. We need to create more Login Schemas. A PasswordOnly.xml Login Schema is used to extract the username from the first username only Login Schema and then ask the user for a password. The entered password is sent to the MFA LDAP server, which contacts Azure and prompts the user to approve the login on their mobile phone as the second factor.

Password Only XML code:

<?xml version="1.0" encoding="UTF-8"?><AuthenticateResponse xmlns="http://citrix.com/authentication/response/1">
<Status>success</Status>
<Result>more-info</Result>
<StateContext /><AuthenticationRequirements>
<PostBack>/nf/auth/doAuthentication.do</PostBack>
<CancelPostBack>/Citrix/Authentication/ExplicitForms/CancelAuthenticate</CancelPostBack>
<CancelButtonText>Cancel</CancelButtonText>
<Requirements><Requirement>
<Credential><ID>login</ID><SaveID>ExplicitForms-Username</SaveID><Type>username</Type></Credential>
<Label><Text>Username</Text><Type>plain</Type></Label>
<Input><AssistiveText>Please supply either domain\username or user@fully.qualified.domain</AssistiveText><Text>
<Secret>false</Secret><ReadOnly>true</ReadOnly>
<InitialValue>${HTTP.REQ.USER.NAME}</InitialValue>
<Constraint>.+</Constraint>
</Text></Input>
</Requirement>
<Requirement><Credential><ID>passwd</ID><SaveID>ExplicitForms-Password</SaveID><Type>passwd</Type></Credential>
<Label><Text>Password:</Text><Type>plain</Type></Label>
<Input><Text><Secret>true</Secret>
<ReadOnly>false</ReadOnly>
<InitialValue/><Constraint>.+</Constraint>
</Text></Input></Requirement>
<Requirement>
<Credential><Type>none</Type></Credential>
<Label><Text>Please enter your password to login</Text>
<Type>confirmation</Type>
</Label><Input /></Requirement>
<Requirement><Credential><ID>saveCredentials</ID>
<Type>savecredentials</Type>
</Credential><Label><Text>Remember my password</Text>
<Type>plain</Type></Label>
<Input><CheckBox><InitialValue>false</InitialValue></CheckBox></Input>
</Requirement><Requirement><Credential><ID>loginBtn</ID>
<Type>none</Type></Credential><Label><Type>none</Type>
</Label><Input><Button>Log On</Button>
</Input></Requirement></Requirements></AuthenticationRequirements>
</AuthenticateResponse>

A RADIUS Login Schema is also required for users that are required to authenticate using RADIUS. The username field will be pre-filled with the username obtained from the first Login Schema (username only schema). 

RADIUS XML Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AuthenticateResponse xmlns="http://citrix.com/authentication/response/1">
<Status>success</Status>
<Result>more-info</Result>
<StateContext></StateContext>
<AuthenticationRequirements>
<PostBack>/nf/auth/doAuthentication.do</PostBack>
<CancelPostBack>/nf/auth/doLogoff.do</CancelPostBack>
<CancelButtonText>Cancel</CancelButtonText>
<Requirements>
<Requirement>
<Credential><Type>none</Type></Credential>
<Label><Text>Please log on</Text><Type>heading</Type></Label>
<Input/>
</Requirement>
<Requirement>
<Credential><ID>login</ID><SaveID>login</SaveID><Type>username</Type></Credential>
<Label><Text>Username:</Text><Type>plain</Type></Label>
<Input><Text><ReadOnly>false</ReadOnly><InitialValue>${HTTP.REQ.USER.NAME}</InitialValue><Constraint>.+</Constraint></Text></Input>
</Requirement>
<Requirement>
<Credential><ID>passwd</ID><SaveID>passwd</SaveID><Type>password</Type></Credential>
<Label><Text>Password:</Text><Type>plain</Type></Label>
<Input><Text><Secret>true</Secret><Constraint>.+</Constraint></Text></Input>
</Requirement>
<Requirement>
<Credential><ID>passwd1</ID><SaveID>passwd1</SaveID><Type>password</Type></Credential>
<Label><Text>Passcode:</Text><Type>plain</Type></Label>
<Input><Text><Secret>true</Secret><Constraint>.+</Constraint></Text></Input>
</Requirement>
<Requirement>
<Credential><ID>savecredentials</ID><SaveID></SaveID><Type>savecredentials</Type></Credential>
<Label><Text>Remember my credentials</Text><Type>plain</Type></Label>
<Input><AssistiveText></AssistiveText><CheckBox><InitialValue>false</InitialValue></CheckBox></Input>
</Requirement>
<Requirement>
<Credential><ID>Logon</ID><Type>none</Type></Credential>
<Label><Type>none</Type></Label>
<Input><Button>Submit</Button></Input>
</Requirement>
</Requirements>
</AuthenticationRequirements>
</AuthenticateResponse>

For the RADIUS Login Schema, enter number 1 inside the Password Credential Index box. This will allow the LDAP password to be presented to StoreFront for SSO and prevent the RADIUS password from being used. Click OK.

Create a noschema Login Schema. This Login Schema is used after Group Extraction. So, the user is instead directed to the next Policy Label which contains the correct Login Schema based on the users group membership (RADIUS Login Schema or Password Only Login Schema for LDAP/MFA).

In total you should have 6 Login Schema profiles.

As mentioned, the RADIUS Login Schema has a password credential index of 1. Now you need to create a Traffic Policy to ensure this password is used to authenticate with StoreFront. Navigate to NetScaler Gateway -> Policies -> Traffic Policies, Profiles and Form SSO Profiles -> Traffic Profiles -> Add.

Enter a name. In the SSO Password Expression field enter http.REQ.USER.ATTRIBUTE(1). Click Create.

Click on the Traffic Policies tab -> Add. Enter a name and expression of ns_true. Choose the single profile you just created. Click Create.

Edit the Unified Gateway vServer, click on the + sign beside Policies.

Choose Traffic and Request. Click Continue.

Select the Traffic Policy. Click Bind.

Now that the Traffic Policy is attached to Unified Gateway, click Done.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Basic Policies -> RADIUS -> Servers -> Add.

Enter your RADIUS server details. Click Create.

Create an Authentication Policy for RADIUS.

Choose the RADIUS action you just created with an expression of true.

Create another Authentication Policy for RADIUS with Action Type set to NO_AUTHN. This means authentication will not be performed and instead users will reach the next factor. Use an expression of true.

Create another NO_AUTHN Authentication Policy for LDAP. Use an expression of HTTP.REQ.USER.IS_MEMBER_OF(“MFA Users”). This policy will be evaluated only if the connecting user is a member of the MFA Users group in Active Directory.

In total you will have 8 Authentication Policies.

To finish we need to create some more Policy Labels. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policy Labels -> Add.

Create a Policy Label for Password Only. Choose the Password Only Login Schema. Click Continue.

Under Select Policy click Click to select.

Select the MFA LDAP policy.

Set the Goto Expression to END. Click Bind.

The Password Only Policy Label should look like below. Your username is asked for first, group extraction is performed, if you are part of the MFA Users group you receive the PasswordOnly-MFA-PolicyLabel which challenges you with LDAP and Azure MFA.

Create another Policy Label for RADIUS using the noschema Login Schema. Click Continue.

Bind the RADIUS policy to this Policy Label with a Goto Expression of END.

Create a second RADIUS Policy Label only this time using the RADIUS Username/Password/Passcode Login Schema.

Bind the sAMAccountName LDAP policy  to this Policy Label with a Goto Expression of NEXT. For Next Factor, choose the RADIUS noschema Policy Label. This Policy Label contains the RADIUS server action.

Create a Policy Label using the noschema Login Schema. This Policy Label will be used to determine which factors of authentication users will receive based on group membership.

Bind the LDAP-noauthn-Policy to the Policy Label with next factor as PasswordOnly-MFA-PolicyLabel.

Bind the RADIUS-noauthnPolicy to the Policy Label with next factor as RADIUS-PolicyLabel. A higher priority will be used here so that LDAP-noauth-Policy is evaluated first.

We will specify this Policy Label as the next factor to username LDAP group extraction. After username group extraction is performed, the noschema-PolicyLabel Policy Label is evaluated. noauthn policies simply are there to determine if the connecting user based on their group receives Password Only or RADIUS Policy Labels for next factor. If Password Only, that Policy Label presents the Password Only Login Schema and an LDAP policy which authenticates the user with Active Directory and Azure MFA. If user is not a member of the MFA group, they receive the RADIUS Policy Label which asks firstly for LDAP credentials, then links to another Policy Label (using noschema) which asks for the RADIUS token code.

Navigate to your AAA vServer and edit the Advanced Authentication Policies. Click Add Binding.

Add the LDAP-GroupExtraction-Policy Authentication Policy with next factor as noschema-PolicyLabel. You are now ready to test the different authentication schemas.

Watching it all work

Corporate machine has a user certificate, connect to Unified Gateway URL. Username is extracted from certificate. User asked to enter password.

Authentication is successful.

Delete the user certificate.

Add user account to the MFA Users group.

Certificate authentication fails so I am presented with the username only Login Schema. Once my username is entered, group extraction is performed.

NetScaler detects I’m in the MFA Users group so the Password Only Login Schema is presented. Entering my username will authenticate myself with LDAP and then Azure MFA.

Phone receives a push-notification from Authenticator app asking me to approve sign-in.

Authentication is successful.

Now I am removing my user account from the MFA Users group.

As normal, certificate authentication fails and I am asked for my username.

Group Extraction this time determines that I am not an MFA User so presents me with the RADIUS Login Schema.


19 Comments

  • Mark Du Plessis

    September 23, 2016

    Nice write up !

    I came across a “problem” with device certificate checking on the Access gateway not authenticating the certificate against the CA or intermediate CA cert (whichever issued the client\device cert). Both of these where attached to the Gateway vServer.

    It turned out that because I had it behind a Content Switch you have to bind the CA and Intermediate CA certs to the Content Switch and not the Gateway vServer.

    I’m guessing the same would be for your nFactor setup above if your Gateway vServer is behind a content switch vServer.

    Reply
  • Clement

    April 4, 2018

    Hi George, I across your article as we are trying to similar to what you have outlined in this article. Good writeup!

    I’m just running into couple issue hope you can point in right direction. Running Netscaler 12

    Following your guide (very useful), I’m able to extract the user and differentiate MFA users vs RSA users to the next login schema policy.

    RSA users get promoted for LDAP and RSA, can login and see resources.
    MFA users get prompted for LDPA password and logged in after enter password, they don’t the Push notification for MFA request. Is there a configuration that I’m missing?

    Btw.. If I test on Gateway with LDPA and Radius (MFA), I get the push notification on my phone and login work.

    Any suggestions?

    Thanks for your help.
    Clement

    Reply
    • George Spiers

      April 5, 2018

      The LDAP profile which is attached to the LDAP Policy presented to MFA users should be configured to point to the IP of your MFA server/load balanced VIP.
      I would check that, also MFA should be configured to point to the NetSaler SNIP (if load balancing MFA) or else the NSIP if using a single MFA server.

      Reply
      • Anonymous

        April 5, 2018

        Thanks George. I created a new policy label “MFA Schema policy label” similar to Radius Schema policy label, pointing to MFA Radius. Then edited the change passwordMFAonly label to go MFA Schema policy label. Bingo MFA prompt worked. Thanks again.

        Reply
  • Anonymous

    October 30, 2018

    Hi George
    Thanks a lot for the procedure.. For a user with no certifcate, i have the user prompt but when i enter the username, i don’t have the password field.. it redirect me to the 2 factor authentication page with the passcode for radius..
    I checked the Netscaler and i have no hit on the PasswordOnly Policy label… 🙁

    Reply
    • George Spiers

      October 31, 2018

      Check the authentication policy bindings on your AAA vServer. Not sure what your fullly desired flow is, but should be something like LDAP policy (Username Extract/Authentication unchecked) -> Policy Label which has LDAP policy bound for next factor.

      Reply
  • Jens

    November 22, 2018

    Hello George,
    thanks a lot for your article. When i enable cert based authentication, then everything goes fine till i try to start an application. I get the second time the certificate popup. When i click ok, then the receiver throws “Client error 1110”

    Reply
    • George Spiers

      November 22, 2018

      Hi Jens. To avoid the second popup generally what I do is create a second Gateway vServer with the same IP but on a different port, and with Client Authentication disabled. Then modify the StoreFront’s Gateway settings with the new URL/port. It is explained here: https://support.citrix.com/article/CTX200193

      Reply
  • Paul R

    June 10, 2019

    This is a fantastic example of nFactor in action. Thank you for your work. I’m looking at doing something similar, however it’s somewhat more straight forward. EndUser is on a non-trusted endpoint so no certificates to worry about and no RADIUS. To improve user acceptance, I need to prompt for UN/PWD from the RfWebUI and then AzureAD MFA (Cloud SAML). however on these non-trusted workstations in my current config the users are getting prompted for UN/PWD again from Microsoft, so I’m missing something.

    Reply
    • George Spiers

      June 16, 2019

      You’ll need a SAML policy, and also FAS to make this work.

      Reply
  • Goudduif

    November 7, 2019

    We lii set-up the EPA check for domain users, only on systems, that have the EPA Addon already installed. Citrix is able to check if the EPA client is installed, otherwise, it prompt you to install them.
    Now we like it when the EPA Client isn’t installed, the users receive only the Basic Access we provide to them. Full access only available when EPA Client confirm that the user connect from a Domain system.
    Can you tell me how I can configure the check if the EPA addon is installed or not?

    Reply
  • Phil

    November 7, 2019

    Hi George:

    Looking for a variation on username extraction from cert. My scenario: 2FA using LDAP and RADIUS. LDAP input is UPN, which bears no resemblance to the SAM (say first.last@mydomain.com for UPN versus last07 for SAM) . RADIUS input must be SAM. What I want to do is have user login with UPN, extract samAccountName and feed that to RADIUS next factor as input for username (Password ptompt Only Schema). If I build the LDAP server specifying UPN as Server Logon and SAM as SSO Attribute, I can see the SAM being extracted. How do I pass that to next factor?

    If:
    1st factor LDAP
    2nd factor RADIUS.
    Is there an edit I do on schema of first factor?

    Reply
    • George Spiers

      December 3, 2019

      Try in your LDAP Server/Profile setting Attribute 1 to “sAMAccountName” and then edit your RADIUS Login Schema XML file, so the username field is configured with: ${HTTP.REQ.USER.ATTRIBUTE1}

      Reply
      • Phil

        May 8, 2020

        Thought I replied some time ago … worked great.

        Reply
  • Lance Baumgartner

    January 24, 2020

    My first time asking a question George. I am only looking to perform a device preauth which if successful, will go into MFA for the user. MFA is not an issue here. My issue is with making sure the device is really authenticated and not checking static content that can be created by any local admin on any device. So when you say “For corporate devices connecting in, let’s apply only two factors. If a device has a corporate certificate, extract the username from the certificate and only ask for the password”. How do we know it’s the corporate certificate and not just any certificate? My company does use OSCP, so is there another way to ensure the device cert is authed?

    Reply
    • George Spiers

      February 17, 2020

      Hello. ADC will not trust the certificate issued by the client unless it is from the corporate issuing CA.

      Reply
  • omer siddique

    August 6, 2020

    Hello

    needed your help. I have followed this article to every letter. Point is that client wants to use LDAP as first factor, and use RSA/ azure MFA nps based on group. They want to eventually move away from RSA and move to NPS.

    https://blog.markdepalma.com/?p=411

    i have made the login schemas, policies, POLICY label, AAA server and i am on the login page now for AAA virtual server. LDAP credentials are accepted, and it moves on to either RSA ( based on group) or MFA NPS azure. The end user is able to get the Radius codes for both (RSA and NPS), however when the user puts in the code, the error event ID number 10 comes in Citrix Receiver for Web ( Cannot complete your request) .

    Reply
  • Phil

    September 30, 2020

    For accessability, I’m looking to provide assistive text that appears on the hover, e.g., “Enter Password,” but which does NOT appear in the field. Is there a tag that I can use in my login schema for that?

    Reply
  • Udom

    November 10, 2023

    Does EPA work in split tunneling setup?

    Reply

Leave a Reply to Mark Du Plessis Cancel reply