Specific CPP Policy based on different AD groups for RA VPN Users

[Srinivasan Nagarajan]

Hi Experts

I'm reaching out to you seeking assistance on the ISE CPP policy based on AD groups. I've been asked to upgrade the CM 3.6 to 4.X to support the new posture AV conditions for RA VPN Users.

Typically, I've noticed CPP policy conditions one for Wired and separate one for wireless but here we'd like to different CPP policy based on the AD groups for the VPN users in a phased approach.
Pilot users will be upgraded to 4.X and the all AD/domain users (as a fallback) will be continue using 3.X. Once tested and working, we'll start moving the users to the pilot AD groups on the phase by phase approach.
Is it correct and will it work ? 

New CPP Policy:-

Rule Name: CPP Policy for Pilot users

Identity group: any

Operating System: windows
other Conditions: Pilot_AD_Group and Device is Firewall
Result: AC_Config_Anyconnect4.8_CM_4.3

Existing CPP Policy

Rule Name: CPP Policy for all AD users

Identity group: any

Operating System: windows
other Conditions: Device is Firewall
result: AC_Config_Anyconnect4.8_CM_3.6

1. We've set the other conditions as Device type: firewall for the existing working users. Should I mention the AD group 'Domain users' as a condition in the second CPP policy, as the first CPP policy specifies the Pilot AD group +firewall while the second one is 'any'. I hope this will NOT break the existing connectivity for the 'Domain Users' who will be continue authenticating with the CM 3.X?

New Posture Policy Sets with CM 4.X:-
Rule Name: Posture Policy for Pilot users

Identity group: any

Operating System: Windows
Compliance Module: 4.X or later
other Conditions: Pilot_AD_Group
Result: New_AV_Requirements

Existing Posture Policy Sets with CM 3.X:-

Rule Name: Posture Policy for All AD users

Identity group: any

Operating System: Windows
Compliance Module: 3.X or earlier
other Conditions: any
Result: Existing_Condition_1

Rule Name: Posture Policy_1 for All AD users

Identity group: any

Operating System: Windows
Compliance Module: 3.X or earlier
other Conditions: any
Result: Existing_Condition_1

2.As a Posture Policy is a 'match all' condition, Can you please confirm whether the CM will be upgraded only for the Pilot AD users and new posture conditions will be applicable only for the 4.X users?

3. Will CM 3.X is enough to act as a distinguisher to differentiate between the CM 3.X and CM 4.X posture policies? 

4. Should I mention the AD group instead of other condition as 'any' for the existing policy where domain users use for policy checks?

Please confirm, so, new posture policies are not validated for the 3.X users.

Note:

Once authenticated, users based on the Pilot AD groups+ if compliant= full access will be granted

Once authenticated, users based on the All AD groups+ if compliant= full access will be granted

Please assist. Thanks in advance.

[hslai]

As you already stated, ISE will match from top to down for client provisioning policy rules. Thus, it should work as long as more specific rules are placed towards the top.

You are correct that CM 3.x v.s. 4.x should be enough differentiate for your purposes. However, you might want also to add AD groups as conditions just in case.

[Srinivasan Nagarajan]

Hi @hslai 

Thanks for the reply. 

1. New CPP Policy (4.X) with the other condition set based on 'AD groups' + firewall while the 'All AD users' will continue using the existing CPP policy (3.X) with the other condition set to 'Device type: Firewall'. Please let me know should we need to add the 'domain users' in the fallback group to avoid breaking of the connectivity as the tops rule specifies the AD rule ?

2. Under Posture -> Software Updates -> Client Provisioning ->  enable automatic download is set to disable. Should this be enabled for the users to download the new CPP connectivity? 

3. As mentioned, Users who are part of domain users will be moved to the Pilot AD group on a phase by phase approach. Should users be restarting their devices to get redirected to download new CM or by just disconnecting and connecting back their VPN would suffice?

[hslai]

On 1, not needed, if the fallback is fine to match one of the existing policy rules.

On 2, not related to end user. This update option is to fetch the client provisioning resource files from ISE CP feed and then an ISE admin may use them in ISE to update the policy rules or other policy elements.

On 3, nope, unless ISE posture module not yet installed. Once installed, the module will discover the ISE PSN for binary and profile updates.

[Srinivasan Nagarajan]

Hi @hslai 

Thanks for the assistance and apologies in advance for asking multiple questions

1. With regards to ISE PSN discovery, we've set the server list to * (wildcard). Is this enough for the new CM module to detect PSN or should we need to add the PSN IP addresses in call home and discovery host as well ?

2. We've set the policy to 'Mandatory' and for some reason, if we change it to 'optional',  by just disconnecting and connecting back their VPN is fine enough or is there any timer which should expire for the new policies to take effect?

3. We've the 'Enable Autologin' in the CPP portal which I've not seen in other portals. Should the Authentication Method and the Authorized groups be in place to take effect or just the NAD redirection is fine for the ISE to allow them access to CPP portal for remediation and upgradation?

[hslai]

On 1, please set Discovery Host and/or Call Home List. More info, see ISE Posture Style Comparison for Pre and Post 2.2

On 2, yes.

On 3, When the users redirected to this portal, the ISE PSN will check whether it has an existing session. If yes, auto-logon. If not, it will ask the user to login.

[Srinivasan Nagarajan]

Thanks @hslai  You've been so helpful. Final one

1. For the auto login to work, under the CPP portal 'Authorized groups' should be entered/allowed I assume for the auto-login to work to validate the user session directory against the AD groups allowed. Pls correct me if i'm wrong?

2. We've two ISE nodes used for VPN authentication at each DCs. Should both be entered separated by commas. Am I right? Please be informed, currently, its working fine without the callhome/discovery host values and only the server list is entered as *.

3. On ASA's we've set the VPN ISE nodes (DMZ) under aaa-server but when we navigate to CPP portal and click on 'portal test URL' it's taking me to the ISE node which is used for Wired/Wireless (Internal). Any idea on this one?

4. Incase of any issues and to restore normalcy, disabling the posture policies would work or just removing the 'session posture condition' from the AuthZ policy sets would work? I believe with this, it'll be typical AuthZ policy and posture condition will not be applied if they're even non-compliant.

Please assist.