ISE CPP & Posture Check

[Ali]

Hi Community,

I have a doubt over the below scenario how it works.

If an Endpoint have AnyConnect Agent(4.5) installed with Posture module (4.5) and Compliance Module(3.6) and on ISE we have configured Client provisioning Policy and Posture Policy checks with Mandatory Requirements for the same Agent.

When an Endpoint connects to the network will it go through Client provisioning Policy (or) It will only go for Posture Policy Check (or) both Policy checks will be done.

Second one : is it necessary to have Client provisioning policy on ISE. We are manually deploying Any connect Agent installation with Posture Module and Compliance Module along with Windows image installation.

Need helpful clarification

[Octavian Szolga]

Hi Ali,

My understanding is the following:

CPP - should be the reason for which ISE considers an endpoint to be subject to a posture operation. If it's mentioned (by the means of a condition - OS + any other attribute) into an CPP and has an authorization policy that calls for posture status, it will kick in and check for posture status.

Put it differently, that's the reason why you have (in general settings) a default posture status for devices (it's meant for devices that don't support posture services).

By default it's compliant, meaning no CPP= compliant/ the device cannot be subject to a posture operation.

(Default posture status defines the status for clients that do not have a NAC Agent installed. If client provisioning is not being used, this value can be set to noncompliant.)

Hope that helps.

To sum up, you can skip CPP part if you provision endpoints using GPO, but change the default posture status to noncompliant and make sure that only those endpoints land on the posture check authorization rule.

Regards,

Octavian

[Ali]

Hi Octavian,

In the below possible scenarios how ISE determines posture status based on which condition.

1.Both Client Provisioning and Posture Policies are present – The compliance status is determined based on the posture check

2. Client Provisioning is missing and Posture Policy are Present - The compliance status is determined based on the posture check

3.Client provisioning policy is present, Posture policy is missing - How Compliance status is determine for this

(++ default Posture Status is set to Non-Complaint in Posture Setting)

4. Both Client Provisioning and Posture Policies are missing. How Compliance status is determine

Here we have the following options:
(++ default Posture Status(Administration -> System -> Settings -> Posture -> General Settings) is set to Non-Complaint what will be the Status ?

(++ default client provisioning configuration (Administration -> System -> Settings -> Client provisioning, “Native Supplicant Provisioning Policy Unavailable” option is set to “Apply defined authorization policy”). what will be the Status ?

(++ if we change “Native Supplicant Provisioning Policy Unavailable” to “Allow network access”) what will be the Status ?

[Octavian Szolga · Accepted solution]

Hi Ali,

Just as a disclaimer, I haven't touched ISE for over 6 months so all I'm saying here it's just pure imagination or at least how I remember things working :) 

Regarding your scenarios, Im not 100% sure about each outcome, so you'd have to test them to see if it works as intended.

My opinion about it is the following:

- you have to take into account the default posture status - compliant or not

- CPP has to be present if your default posture status is compliant

- your posture check authorization profile would have to match those devices that are also subject to CPP; if not, ISE will consider them to be compliant (if default status is compliant)

For all your scenarios:

It matters what's configured for CPP and Posture! For all of them. It's not enough to just say both of them are configured. To whom do they reffer to? To a specific OS, group, authentication method, etc?

For the sake of example, let's say you only have 802.1x EAP-TLS for Windows only and your authorization profile with posture conditions takes into account only EAP-TLS auth method. (it implies winodws only; other devices = MSCHAPv2 or whatever)

Scenario 1 - posture status = posture policy check/report (compliant or not)

Scenario 2 - if CPP is not present and default posture status is compliant, I would say the device would get full access/compliant even though according to the posture policy it's not

Scenario 3 - no posture policy but CPP present + non-compliant = not sure

Scenario 4 - not sure; you'd have to test it

Regarding Scenarios 3 and 4 I don't understand why do you care for a posture status when you're not configuring any policy for it? And viceversa. Even if you configure a CPP or posture policy for a device but actually don't call for a posture report in any authorization rule, you won't be affected in any way. It may be that your endpoint sends the report to ISE, Anyconnect will popup saying not compliant, but that won't affect your IP connectivity.

Regards,

Octavian