04-09-2018 02:06 AM - edited 02-21-2020 10:53 AM
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
Solved! Go to Solution.
04-11-2018 04:57 AM
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
04-10-2018 07:38 AM
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
04-11-2018 01:54 AM
04-11-2018 04:57 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide