Jump to content
Updated Privacy Statement

Netscaler EPA post-auth scan for specific users only


Ross Bender

Recommended Posts

We are wanting to start doing EPA scanning post authentication on our Access Gateway endpoint. We want to only have the scan prompted for specific users (based on group membership) and all the other users will not be prompted to scan at all. However, I've found that the user is always being prompted to download the EPA plugin regardless of whether the policy targets the user for a scan or not.

 

I've tried the post-auth config both through nFactor policies (if user in group, target EPA policy) and through a session policy. The result is the same, that the client always the prompt to configure the plugin.

 

Is there a way to configure post-auth scan policies so that non-targeted users do not need to download/install the EPA plugin? We're wanting to roll out EPA scanning across our organization and minimize impact by targeting group by group.

Link to comment
Share on other sites

Ross, I only know how to do that via separate vpn vserver access points (based on the old classic epa behavior).  And I haven't had a chance to play with this granularly with the advanced policy integration in a while.

 

For advanced engine via nfactor, i have a few questions for which config you tried:

You said you did nfactor and used the session policy, did you have any EPA expressions in the authentication phase or was it in session policy phase only?

Did you bind the session policy to the AAA group only? OR did you bind the policy to the vpn vserver with a group filter attached? 

(If the latter, try the former instead as if it would limit the epa scan to only those groups, that would be the only time it would do so.)  If the epa policy was only bound to the aaa group level (and not applied to vpn vserver wtih group filter) and you still see the scan apply to users in groups without a scan applied, then I don't think you can separate. You would just need policy based on some sort of true/always valid condition so the scan will attempt but not stop processing for those exempted users.

 

If you can share your policy/expression configs that you have tried, it would help to see if there is a way to do what you want. 

 

  

Link to comment
Share on other sites

Thanks for the response. Here is some of my config:

 

add vpn vserver VDI-Test SSL 10.6.202.109 443 -downStateFlush DISABLED -Listenpolicy NONE -WindowsEPAPluginUpgrade Always -LinuxEPAPluginUpgrade Always -MacEPAPluginUpgrade Always -authnProfile WFH-nFactor

add authentication vserver WFH-nFactor SSL 0.0.0.0 -appflowLog DISABLED
bind authentication vserver WFH-nFactor -policy AuthAlwaysTrue -priority 100 -nextFactor PerformLdap -gotoPriorityExpression NEXT

add authentication policylabel PerformLdap -loginSchema UsernamePasswordType-2020
bind authentication policylabel PerformLdap -policyName LDAP -priority 100 -gotoPriorityExpression NEXT -nextFactor DetermineEpa

add authentication policylabel DetermineEpa -loginSchema LSCHEMA_INT
bind authentication policylabel DetermineEpa -policyName EpaRequired -priority 100 -gotoPriorityExpression END -nextFactor PerformEpa
add authentication Policy EpaRequired -rule "AAA.USER.GROUPS.CONTAINS_ELEMENT(\"My Group\")" -action NO_AUTHN
bind authentication policylabel DetermineEpa -policyName AuthAlwaysTrue -priority 110 -gotoPriorityExpression NEXT

add authentication policylabel PerformEpa -loginSchema LSCHEMA_INT
bind authentication policylabel PerformEpa -policyName EpaWindows-PostAuth -priority 100 -gotoPriorityExpression NEXT

add authentication Policy EpaWindows-PostAuth -rule true -action EpaWindows2020
add authentication epaAction EpaWindows2020 -csecexpr "sys.client_expr(\"app_0_ANTIVIR_0_0_RTP_==_TRUE[COMMENT: Generic Antivirus Product Scan]\")"

 

Login process would follow like:

- load login page -> login -> perform LDAP

- is user part of group?

      - if yes, perform EPA scan

      - otherwise continue with successful auth

 

With the above, I am seeing the agent plugin download regardless of whether I am in the group or not (have also tested with "true" and "false" values).

 

I'm also seeing when I remove the "DetermineEpa" as nextfactor from PerformLdap policy label, I am still seeing the same. So I'm wondering if EPA plugin download config is always presented to a user as soon as the "ICA Only" option is set to false on the access gateway server?

Link to comment
Share on other sites

If you do epa during authentication, it will have to load the epa agent first prior to doing group determination.

 

The only time you *might* be able to skip epa if if the epa option is solely handled via session policies based on aaa group bindings -- and I'll admit, I don't know if this would separate it anyway.  In this case, the epa agent might only run for users in certain groups; but I'm not certain.

At any other phase - preauthentication and tied to the nfactor policies epa client has to load even if the scan isn't in use.

 

Now, regarding the ICA Only option.  Note:  EPA scans can be done with vpn users or ica proxy users with epa client. 

The ICA ONLY option has to be false as this setting restricts the gateway to ICA Only (ICA Proxy BASIC mode) settings AND restricts consumption of licenses to ICA only licenses and not a vpn ccu/universal license. In this mode, you cannot do epa scans at all.

Link to comment
Share on other sites

On 6/5/2020 at 9:27 PM, Ross Bender said:

 

Login process would follow like:

- load login page -> login -> perform LDAP

- is user part of group?

      - if yes, perform EPA scan

      - otherwise continue with successful auth

 

With the above, I am seeing the agent plugin download regardless of whether I am in the group or not (have also tested with "true" and "false" values).

 

I'm also seeing when I remove the "DetermineEpa" as nextfactor from PerformLdap policy label, I am still seeing the same. So I'm wondering if EPA plugin download config is always presented to a user as soon as the "ICA Only" option is set to false on the access gateway server?

Just to add my 2 cents on possible solution.

 

In first step you could ask only only for a username (username_only schema) > then do a group extraction > based on Group1 extraction apply NEXT factor as LDAP (full or password only) followed by EPA

                                                                                                                                                                                                  > based on Group2 extraction apply NEXT factor as LDAP only

Link to comment
Share on other sites

  • 2 weeks later...

I was successfully able to get this to work with nfactor policies (never circled back to try with session profiles). Here are a few things I ran into that might be helpful for someone else:

  • There is a bug in LOCAL policies (at least in 13 firmware) where the policy will never succeed evaluation (even with expression = true). Using NO_AUTHN worked though and I don't think there is really any difference.
  • Have a separate factor (policy label) that does the conditional logic for whether EPA should occur. That is, keep EPA policies in their own factor (policy label) and only invoke that factor if desired to scan. Once you add an EPA policy to a factor, it will trigger an EPA scan if that factor is hit.
  • EPA policy expressions based on things like HTTP.REQ are based on the requests from the client plugin, not the client browser. For example, if using HTTP.REQ.HEADER("User-Agent") in an EPA policy expression, this will be the user agent of the plugin on the person's device, not the browser they are connecting with.
Link to comment
Share on other sites

2 hours ago, Ross Bender said:

EPA policy expressions based on things like HTTP.REQ are based on the requests from the client plugin, not the client browser. For example, if using HTTP.REQ.HEADER("User-Agent") in an EPA policy expression, this will be the user agent of the plugin on the person's device, not the browser they are connecting with.

 

Ross - just to clarify this part, if the user connects with a web browser, then it should be the web-browser's user-agent header; if the user is connecting with  a workspace app it should see the workspace app user-agent

OR did you mean specifically for an EPA scan it sees the vpn client/workspace app user-agent only because the context of the epa scan is the agent executing the scan and NOT how the user is connecting to gateway?

Link to comment
Share on other sites

5 minutes ago, Rhonda Rowland1709152125 said:

 

Ross - just to clarify this part, if the user connects with a web browser, then it should be the web-browser's user-agent header; if the user is connecting with  a workspace app it should see the workspace app user-agent

OR did you mean specifically for an EPA scan it sees the vpn client/workspace app user-agent only because the context of the epa scan is the agent executing the scan and NOT how the user is connecting to gateway?

 

Your latter statement is true. Whereas previous factors with policy expressions of HTTP.REQ will have values for browser/workspace, the factor where EPA policies are bound will have those values populated with the plugin/agent details.

 

I did a packet capture and could see the two different TCP streams--one for browser/workspace and the second one for plugin/agent. So I guess for EPA the Netscaler knows to handle those policies with the plugin/agent detail.

 

It's kind of confusing how EPA policies work slightly differently (e.g. the act of binding them to a factor means they will trigger a scan, regardless of the expression in the policy), but once I got past that I was able to get it working.

  • Like 1
Link to comment
Share on other sites

I mean the "agent" makes sense after you point it out because the vpn client OR the epa agent is what's running the scan and it doesn't see more than it's perspective.  But until you pointed it out...i would have assumed the gateway is seeing the user connectino...but yes, epa scans run under context of the agent doing scan.

 

Now for the other thing about triggering the epa scans.

I had thought the nfactor MIGHT separate it but couldn't test to be sure.

In the old days with classic authentication, any inclusion of epa meant it was triggered for all whether applied or not; but post epa scans could be selective.

So I thought nfactor might allow us to limit if the epa scan was seen or not...but again, that week I couldn't test to see.  Basically - I thought it might work to solve the problem; but I wouldn't have been surprised if it didn't.

 

Glad we got information on both though.  You did the grunt work so we can all benefit :)

Link to comment
Share on other sites

  • 11 months later...
On 6/19/2020 at 5:03 PM, Ross Bender said:

I was successfully able to get this to work with nfactor policies (never circled back to try with session profiles). Here are a few things I ran into that might be helpful for someone else:

  • There is a bug in LOCAL policies (at least in 13 firmware) where the policy will never succeed evaluation (even with expression = true). Using NO_AUTHN worked though and I don't think there is really any difference.
  • Have a separate factor (policy label) that does the conditional logic for whether EPA should occur. That is, keep EPA policies in their own factor (policy label) and only invoke that factor if desired to scan. Once you add an EPA policy to a factor, it will trigger an EPA scan if that factor is hit.
  • EPA policy expressions based on things like HTTP.REQ are based on the requests from the client plugin, not the client browser. For example, if using HTTP.REQ.HEADER("User-Agent") in an EPA policy expression, this will be the user agent of the plugin on the person's device, not the browser they are connecting with.

 

Hey @Ross Bender I'm having the same requirement, are you able to share a little bit more details about your very helpful hints for filtering post EPA-Scan for different User-Agent Header AND Active Directory Groups? I mean, which is your priorization on nfactor login schemas, so the post epa scan is on the correct position?

 

Big Thanks in advance

Best Regards

Julian

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...