Posture Exemption for Specific AD group - Remote Access VPN

[Srinivasan Nagarajan]

Hi Experts,

We’ve Remote Access VPN with the Posture configured. Once the users are authenticated,  users would being redirected to the CPP portal and  posture policies will be validated. Once authorized, they’re being pushed down with the group-policy configured on the ASA based on the AD groups on ISE.

Now, client would like to exempt an specific AD group from the posture and I’d like to configure it on the top of the existing one.

    1. I guess, if we didn’t use the ‘session posture status’ as an attribute, it’d be typical AuthZ policy and it’d work. Please correct me?

    2. Also, once the above rule is configured, hope users will not be redirected to the CPP portal. Please assist?

   3.We’ve Default Posture Status as ‘Non-compliant’ (under Administration -> Settings -> Posture -> Default Settings) and not sure if that would take effect, if the users are not matching the posture policy. Please suggest?

[Mike.Cifelli · Accepted solution]

  1. I guess, if we didn’t use the ‘session posture status’ as an attribute, it’d be typical AuthZ policy and it’d work. Please correct me?

-IMO you have several ways to accomplish this.  One being, remove any posture policy reference for the specific/desired group.  Just note though that if your default setting is non-compliant then these "exempt" clients are going to be noncompliant since no matches against posture policies for assessment.  (see my response to question 3).

    2. Also, once the above rule is configured, hope users will not be redirected to the CPP portal. Please assist?

-Clients are going to get redirected to the CPP if you have the redirect setup in the authz result profile & they match conditions in the CPP.  If you wish certain clients to not get redirected, then change the respective group authz result + remove the group from any CPP if referenced.

   3.We’ve Default Posture Status as ‘Non-compliant’ (under Administration -> Settings -> Posture -> Default Settings) and not sure if that would take effect, if the users are not matching the posture policy. Please suggest?

-This will take affect.  For clients with the posture module present, it will probe home perhaps on DFG change, or on a network connection attempt & even if a specific user does not match any conditions/posture/CPP policy ISE will present them with the 'Default Posture Status'.   To clarify:

In order to enforce policy on an endpoint, you must configure a corresponding Client Provisioning policy (Agent installation package). Otherwise, the posture status of the endpoint automatically reflects the default setting.

[Srinivasan Nagarajan]

Hi @Mike.Cifelli 

In the Client Provisioning Policy, We've ASA#Firewall as the condition and no AD groups are used. So in the AuthZ policy would be as follows:

AD group: Posture_Users_Exempted = Push the group policy (not the CPP direction policy)

From your above reply, even if we didn't use the ‘session posture status’ as an attribute in the Authorization policy,  Default Posture Status configured as ‘Non-compliant’ (under Administration -> Settings -> Posture -> Default Settings) will override the Authorization policy and still mark the users as Non-Compliant? Am I right?

Also, you have mentioned there are several ways to accomplish this in your first reply. Can you please provide them to gain better idea? We need to exclude specific AD groups from the posture assessment without changing the default posture status settings. Please assist.

Thank you.

[Mike.Cifelli · Accepted solution]

From your above reply, even if we didn't use the ‘session posture status’ as an attribute in the Authorization policy,  Default Posture Status configured as ‘Non-compliant’ (under Administration -> Settings -> Posture -> Default Settings) will override the Authorization policy and still mark the users as Non-Compliant? Am I right?

-Yes.

We need to exclude specific AD groups from the posture assessment without changing the default posture status settings.

-Will these excluded clients have the Posture module installed/present? AFAIK if it is installed and has reachability to ISE it will consume the default setting even if there is no match on posture policies.

[hslai]

Mike is mostly correct.

In case the exempted clients matched an authorization policy rule to get the proper network access, it should not matter whether the AnyConnect ISE posture module may attempt to discover ISE. If needed, we may block access to ISE on TCP 8443 and TCP 8905 for such clients.

[Srinivasan Nagarajan]

Hi @hslai 

Thanks for the update. As suggested by Mike, users will be hitting the default status which is non-compliant configured.

I've reached out to the TAC and they informed, it doesn't matter as the Posture attribute isn't used in the Authorization policy and so even if the client installed with the Compliance module, they'd not be hitting this policy rule as its not applicable to them.

This seems to be little different with Mike statement or am I missing something to understand?

Q: If we didn’t use the ‘session posture status’ as an attribute, it’d be typical AuthZ policy and it’d work. Will this be overridden by the Default posture status condition under settings?

[hslai]

The default posture status is applied while no matched found in ISE client provisioning policy rules for one of the ISE posture agent configuration (regular AnyConnect ISE posture, agentless, or temporal).

Even if a posture state set to this default as a result of no-match and if CoA issued, the client would not match with an authorization rule with a less permission or it depends on how the authorization policy rules are ordered.

Anyhow best to test it out in the lab. Since you already engage TAC, the assigned engineer should be able to help with your test and analysis.