EPA scan as a factor in nFactor authentication

September 15, 2021

Contributed by:

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, seeEPA execution.

EPA Policy——在nFactor,所有的政策都添加了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, seenFactor 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 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 undervpn session action. The following logic is used as an example for implementing EPA scan as a factor in nFactor authentication.

EPA in nFactor flow sequence

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.

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.

EPA in nFactor policy and policy label mapping

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 labelpost-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.
Configureldap-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 
```
whereldap_server1is the LDAP policy andldap-authis the policy name.
Bringing it all together, associateldap-auth policyCitrix ADC AAA虚拟服务器的下一个step pointing to the policy labelpost-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.

References

The official version of this content is in English. Some of the Citrix documentation content is machine translated for your convenience only. Citrix has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Citrix product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Citrix, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Citrix will not be held responsible for any damage or issues that may arise from using machine-translated content.

EPA scan as a factor in nFactor authentication

September 15, 2021

Contributed by:

September 15, 2021

Contributed by:

EPA scan as a factor in nFactor authentication

EPA Factor mutual exclusivity

EPA Execution

Configure periodic EPA scan as a factor in nFactor authentication

Pre-requisites

CLI configuration of the logic

References

In this article