EPA scan as a factor in nFactor authentication
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 Security 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 security 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.
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 security expressions and sending the results. Client security 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 periodic EPA scan as a factor in nFactor authentication
You can configure periodic EPA scan as a factor in nFactor authentication using the advanced policy infrastructure.
Note: In classic policy, Periodic EPA was configured as part of session policy under
vpn session action.
The following logic is used as an example for implementing EPA scan as a factor in nFactor authentication.
- 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 ascertain that the security requirements configured are still met.
- If the EPA scan fails during any such check, the session is terminated.
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.
CLI configuration of the logic
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
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.
Configure the policy label
post-ldap-epa-scan`, which hosts the policy for EPA scan.
add authentication policylabel post-ldap-epa-scan -loginSchema LSCHEMA_INT
Note: LSCHEMA_INT is an inbuilt schema with no schema(noschema), that means no additional webpage is presented to the user at this step.
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
This completes the authentication mechanism.
ldap-auth policyto 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
ldap_server1is the LDAP policy and
ldap-authis the policy name.
Bringing it all together, associate
ldap-auth policyto the Citrix ADC AAA virtual server with the next step pointing to the policy label
post-ldap-epa-scanto perform an EPA scan.
bind authentication vserver MFA_AAA_vserver -policy ldap-auth -priority 100 -nextFactor post-ldap-epa-scan -gotoPriorityExpression NEXT
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.