EPA scan as a factor in nFactor authentication

Important:

Endpoint Analysis is intended to analyze the user device against pre-determined compliance criteria and does not enforce or validate the security of end-user devices. It is recommended to use endpoint security systems to protect devices from local admin attacks.

The following are some of the basic entities of nFactor EPA.

EPA Action: EPA Action is an action type introduced for nFactor EPA. It contains the following:

• Client device check expression: This expression is sent to the gateway EPA plug-in for evaluation.
• Success Group: This group, if configured, is inherited to the gateway session if the EPA result is true.
• Quarantine Group: This group, if configured, is inherited to the gateway session if the EPA result is false.
• killProcess: This represents the name of the process that the EPA process must terminate.
• deleteFiles: Specifies comma-separated paths to files that the EPA process must delete.

Groups can be used during the life of the session to determine whether the client meets certain EPA condition. If at a given factor, the EPA fails and the last action does not contain “Quarantine Group”, then authentication is terminated for that user. If “Quarantine group” exists, authentication is continued and the administrator can check for the group to give limited access. For more details, see EPA execution.

EPA Policy: In nFactor, all the policies are added with the same syntax “add authentication policy”. However, the type of the action qualifies the policy as an EPA policy.

EPA Factor: EPA factor is a regular policy label. There is no entity called EPA factor. Once EPA policy is bound to a factor, it inherits certain properties that make it an EPA factor.

Note:

The term “EPA Factor” is commonly used in this document to refer to a factor with EPA policies.

EPA – Quarantine: If at a given factor, all client device check expressions from all actions fail, and if the last action contains “Quarantine group”, that group is added to the session and the nextFactor is looked into. That is, despite the failure, the presence of the “quarantine group” qualifies the session to the next stage. However, due to the inheritance of a special group, the administrator can relegate the session to restricted access or extra authentication policies like OTP or SAML.

If there is no quarantine group at the last action, authentication terminates in a failure.

EPA in nFactor also uses the following entities:

• LoginSchema: XML representation of logon form. It defines the “view” of the logon form and also has properties of a “factor”.
• Policy label or policy factor: It is a collection of policies that are tried at a given stage of authentication.
• Virtual server label: Virtual server is also a policy label, that is one can bind policies to virtual server. However, the virtual server is the collection of various policy labels as it is the entry point for user access.
• next factor: It is used to specify the policylabel/factor to be taken once the given authentication policy succeeds.
• NO_AUTHN policy: Special policy whose action always succeeds.
• Passthrough factor: Is a policylabel/factor whose login schema does not contain view. It is an indication to the Citrix ADC appliance to continue authentication at the given factor without user intervention.

For more information, see nFactor concepts, entities, and terminology.

EPA Factor mutual exclusivity

EPA Factor contains one or more EPA policies. Once EPA policies are bound to a factor, regular authentication policies are disallowed on that factor. This restriction is to offer the best user experience and clean separation of endpoint analysis. The only exception to this rule is the NO_AUTHN policy. Since NO_AUTHN policy is a special policy used to simulate ‘on-failure-jump’, it is allowed in the EPA factor.

EPA Execution

At any given factor (including the virtual server factor), before serving the logon form, the Citrix ADC appliance checks if the factor is configured for EPA. If so, it sends a specific response to the client (UI) such that the EPA sequence is triggered. This sequence comprises the client requesting for client device check expressions and sending the results. Client device check expressions for all policies in a factor are sent at once to the client. Once results are obtained at the Citrix ADC appliance, each of the expressions in all actions are evaluated in a sequence. The first action that results in successful EPA terminates that factor, and DefaultGroup, if configured, is inherited into the session. If NO_AUTHN policy is encountered, it qualifies as automatic success. If the nextFactor is specified, the appliance continues with that factor. Otherwise, authentication terminates. This condition is applicable for the first factor as well. If there is no authentication policy factor after EPA at the virtual server, authentication is terminated. This is different from classic policy behavior where the user is always shown the login page after EPA. However, in the event of no successful EPA policy, then Citrix Gateway looks at the Quarantine Group configured for the last EPA policy in that factor or cascade. If the last policy is configured with the Quarantine Group, that group is added to the session and the nextFactor is inspected. If a nextFactor exists, authentication proceeds to that factor. Otherwise, authentication is completed.

Configure EPA scan to run after authentication

You can configure EPA scan to run after the authentication. In the following example, the EPA scan is used as a final check in a nFactor or multifactor authentication. In this setup, if the EPA scan fails during any such check, the session is terminated.

• User tries to connect to NetScaler Gateway Virtual IP.
• A login page with user name and password field is rendered to the user to provide login credentials. With these credentials, LDAP, or AD based authentication is performed at the back-end. If successful, the user is presented with a pop up to authorize the EPA scan.
• Once the user authorizes, the EPA scan is performed and based on the success or failure of user client settings, access is provided.
• If the scan is successful, the EPA scan is performed periodically to learn that the device check requirements configured are still met.
• If the EPA scan fails during any such check, the session is terminated.

Pre-requisites

It is assumed that the following configuration is in place:

• VPN virtual server, gateway, and authentication virtual server configuration
• LDAP server configurations and associated policies.

The following section captures the required policies and policy label configurations and also the mapping of policies and policy label to an authentication profile.

On the CLI

1. Create an action to perform the EPA scan and associate it with an EPA scan policy.

   add authentication epaAction EPA-client-scan -csecexpr "sys.client_expr(\"proc_2_firefox\")"
   
   add authentication Policy EPA-check -rule true -action EPA-client-scan
   <!--NeedCopy-->
   

   The preceding expression scans if the process ‘Firefox’ is running. The EPA plug-in checks for the process existence every 2 minutes, signified by the digit ‘2’ in the scan expression.

2. Configure the policy label post-ldap-epa-scan`, which hosts the policy for the EPA scan.

   add authentication policylabel post-ldap-epa-scan -loginSchema LSCHEMA_INT
   <!--NeedCopy-->
   

   Note:

   LSCHEMA_INT is an inbuilt schema with no schema(noschema), that means no additional webpage is presented to the user at this step.

3. Associate the policy configured in step 1 with the policy label configured in step 2.

   bind authentication policylabel post-ldap-epa-scan -policyName EPA-check -priority 100 -gotoPriorityExpression END
   <!--NeedCopy-->
   

   This completes the authentication mechanism.

4. Create a login schema with SSO enabled.

    add loginSchema lSchema -authenticationSchema LoginSchema/SingleAuth.xml -SSOCredentials Yes
    <!--NeedCopy-->
   

5. Create an authentication virtual server.

   add authentication vserver av_vs ssl -ip address 10.104.130.129 -port 443
    <!--NeedCopy-->
   

6. Add a login schema policy.

   add loginSchemaPolicy lschema_pol -rule true -action lSchema
   <!--NeedCopy-->
   

7. Bind the login schema policy to the authentication virtual server.

   bind authentication vserver av_vs -policy lschema_pol -priority 100
   <!--NeedCopy-->
   

8. Configure ldap-auth policy to and associate it with an LDAP policy that is configured to authenticate with a specific LDAP server.

   add authentication Policy ldap-auth -rule true -action ldap_server1
   <!--NeedCopy-->
   

   where ldap_server1 is the LDAP policy and ldap-auth is the policy name.

9. Bringing it all together, associate ldap-auth policy to the authentication, authorization, and auditing virtual server with the next step pointing to the policy label post-ldap-epa-scan to perform an EPA scan.

   bind authentication vserver MFA_AAA_vserver -policy ldap-auth -priority 100 -nextFactor post-ldap-epa-scan -gotoPriorityExpression NEXT
   <!--NeedCopy-->
   

   Note:

   In periodic EPA configured as multiple factors, the latest factor with periodic EPA configuration is considered.

   In the earlier example, EPA is the first factor where the scan looks for the process ‘Firefox’.

   • If the EPA scan is successful, it leads to LDAP authentication, followed by the next EPA scan, that looks for the process ‘Chrome’.
   • When multiple periodic scans are configured as different factors, the latest scan takes the precedence. In this case, the EPA plug-in scans for the process ‘Chrome’ every 3 minutes after the login is successful.

On the GUI (using nFactor Visualizer)

You can configure advanced EPA scan as a factor using the nFactor visualizer on the GUI. In the following example, we have used LDAP as the first factor and EPA as the next factor.

1. Create a first factor for the nFactor flow.

   • Navigate to Security > AAA-Application Traffic > nFactor Visualizer > nFactor Flows and click Add.

   • Click + to add the nFactor flow.
   • Add a factor and click Create.

   

2. Create a login schema and a policy for the first factor.

   • On the first factor tile, click Add Schema to add a login schema. You can either select an existing authentication login schema from the drop-down list or create a login schema.

   • To create an authentication login schema, click Add. For detailed information about authentication login schema, see Configuring nFactor authentication.

     

   • Click Add Policy to add the LDAP policy. If the LDAP policy is already created, you can select the same. Click Add.

     Note:

     If an LDAP policy is not created, you can create one. Click the Add button next to the Select Policy drop-down list. In the Action field, select LDAP. For details about adding an authentication LDAP server, see https://support.citrix.com/article/CTX123782.

     

3. Create a next factor and connect it to the first factor.

   • Click the green or red colored + icon, to add EPA as the next factor.
   • Create the next factor on the Next Factor to Connect page.
   • Leave the Add Schema section blank, to have the default no schema applied for this factor.

4. Add a policy for the next factor.

   • Click Add policy to add the post authentication EPA policy and action.
   • You can either choose from an existing list of policies or create a policy. To choose from the existing policies, select a policy from the Select Policy drop-down list, provide the binding details, and click Add.
   • To create a policy, click the Add button next to the Select Policy drop-down list.

   

5. After the nFactor flow is complete, click Done.

6. Bind the nFactor flow to an authentication server.

   • Navigate to Security AAA - Application Traffic > nFactor Visualizer > nFactor Flows.
   • Select the nFactor and click Bind to Authentication Server.

   

References

• nFactor concepts, entities, and terminology
• How to Configure LDAP Authentication on Citrix Gateway
• LDAP authentication
• Advanced Endpoint Analysis scans