01-27-2021 07:48 AM - edited 01-27-2021 07:49 AM
Hi Experts,
Currently running with ISE 2.6 Patch 8 installed. We've an Remote Access VPN being authenticated by the ISE with the posture checks configured. Currently, Anyconnect version is 4.8 and the compliance module is 3.6 with the Service (running) and AV with Def.version checked.
We've got the AuthZ policy sets as follows:-
If User is part of AD group A & Compliant = grant access
If User is part of AD group B & Compliant = grant access
If User is part of All Users VPN group & Compliant = grant access (Fallback AD group for everyone)
We've got an new requirement now to add a new AV condition (Windows Def) which isn't supported in 3.6 due to Cisco Bug and TAC suggested to upgrade to compliance module 4.3. We do NOT want it to roll it out to everyone and would like to get it tested for the pilot/testing AD group as follows:-
In the CPP Policy, under the 'other condition' we're planning to create the new AD group to map it to the new Anyconnect configuration which has the new CM integrated.
Rule Name: New_CM_4.3 for testing users
Identity Group: Any
OS: Windows
Other Conditions: If User is part of AD group X (Different from the AuthZ policies AD group)
Result: Anyconnect_CM_Module_4.3
Is this correct approach or will it break the VPN existing as this AD group isn't specified in the AuthZ policies?
Can someone please assist.
Solved! Go to Solution.
01-27-2021 07:57 AM
AFAIK this should work from my experiences. Just note that once your test group/s get upgraded that checks requiring compliance module 3.x will no longer work against those clients with 4.x now. The compliance upgrade via ISE webdeploy is actually pretty smooth too. Another condition you could utilize to target is specific ASA tunnel-groups (which works great for segregation purposes & I typically utilize for VPN RA Users) is this condition: Cisco-VPN3000:CVPN3000/ASA/PIX7x-Tunnel-Group-Name EQUALS <groupname>. Definitely recommend to test and utilize the proper conditions that meet your reqs and desires though. HTH!
01-27-2021 07:57 AM
AFAIK this should work from my experiences. Just note that once your test group/s get upgraded that checks requiring compliance module 3.x will no longer work against those clients with 4.x now. The compliance upgrade via ISE webdeploy is actually pretty smooth too. Another condition you could utilize to target is specific ASA tunnel-groups (which works great for segregation purposes & I typically utilize for VPN RA Users) is this condition: Cisco-VPN3000:CVPN3000/ASA/PIX7x-Tunnel-Group-Name EQUALS <groupname>. Definitely recommend to test and utilize the proper conditions that meet your reqs and desires though. HTH!
01-27-2021 08:11 AM - edited 01-27-2021 08:12 AM
Hi Mike,
Thanks for the reply. My another consideration is to test the CM upgrade with the DC2 ASA firewalls before proceeding with the DC1. We've the ASA firewalls configured under the Network Devices as follows:
Name: DC1 ASA firewall
IP: X.X.X.X
Type: VPN firewalls
Location: DC1
Name: DC2 ASA firewall
IP: X.X.X.X
Type: VPN firewalls
Location: DC2
What if we restrict the other condition under CPP policy to the Device location rather using Device Types? Which one is better? Is it good to go ahead with the AD groups (phase by phase testing but not sure whether it'd work) or DC2 VPN (no AD groups) followed by the DC1
Please assist. Thanks in advance.
01-27-2021 08:41 AM
What if we restrict the other condition under CPP policy to the Device location rather using Device Types? Which one is better? Is it good to go ahead with the AD groups (phase by phase testing but not sure whether it'd work) or DC2 VPN (no AD groups) followed by the DC1
-IMO either would work. This comes down to a preference on which condition to utilize. Truthfully it may be easier to use device type or device location. What I mean by this is less OR statements in the other condition column (two device locations versus X number of AD sec groups). However, the AD sec groups may be better if you want to get more granular. HTH!
01-27-2021 11:58 PM - edited 01-28-2021 12:01 AM
Hi Mike,
Thanks for the assistance. What we discussed so far for the testing 'AD group X' is under the CPP/Posture policy.
Do we need to create a new AuthZ policy sets for AD group X, as users who are part of the AD group X is also part of the ‘All Users VPN group’ which is a Fallback AD group for everyone (Similar to Domain Users) ?
Please be informed, these AD groups are being created based on group-policies on ASA firewall.
Currently, We've got the AuthZ policy sets as follows:-
If User is part of AD group A & Compliant = grant access
If User is part of AD group B & Compliant = grant access
If User is part of All Users VPN group & Compliant = grant access (Fallback AD group for everyone)
01-28-2021 05:42 AM
Do we need to create a new AuthZ policy sets for AD group X, as users who are part of the AD group X is also part of the ‘All Users VPN group’ which is a Fallback AD group for everyone (Similar to Domain Users) ?
-This is up to you. Since the AD group X are a member of your fallback All Users VPN Group technically, no. If at some point you will migrate all clients to 4.x module and run things the same way you do now it may be easier to just truck forward with using the bottom authz as your compliant catch all until migration is complete. HTH!
01-29-2021 05:17 AM - edited 01-29-2021 05:46 AM
Hi Mike,
First of all, many thanks for helping me out.
Final one and I promise I won’t trouble you much I’d like to seek your expertise on the below.
So when users connected, they’ll be hitting the Unknown status with the ‘All Users VPN group’ and redirected to the CPP portal
Now, if they’re part of the specific ‘AD group X’ , they’ll be asked to upgrade the CM module and posture policies are applied for those AD users
If compliant, again they’ll hit the ‘All Users VPN group’ and granted access.
If my understanding is correct, will it work?
We've Users connect to single tunnel-group on ASA and once each AD group is authenticated, a separate group-policy is being pushed to those users which are selected under the ‘ASA VPN’ section in ISE.
01-29-2021 06:22 AM
Yes your workflow is right. Do note that if you wanted to just do the module upgrade and keep the 4.x posturing tests separate you could do so by disabling the checks at first just to ensure the upgrade via CPP works as expected (note that posture status in this scenario would depend on your default posture status in settings: non compliant or compliant). One other last thing to consider is, if you wanted to be more granular to ensure your flow/implementation works as expected you could make another CPP with a more specific condition for 1 client you wish to test the module/posture upgrades/checks against. The condition I am referring to is the calling-station-id attribute. This would allow you to only test your 4.x concerns against one test client first before doing it to an entire AD group. This way, should something go wrong it only affects the one test client. Good luck & HTH!
01-29-2021 06:40 AM
Hi Mike
As this is being authenticated for Remote Access VPN, Does it need any modification in the group-policy or any connect XML profiles which is configured for the specific AD groups?
01-29-2021 07:26 AM
No because you are relying on ISE CPP to perform your upgrade, and your current in place solution is already configured/working. Just test one client via specific ISE policies to ensure you have things in order.
01-27-2021 08:08 AM
This should work, but make sure that this policy is above your original one.
You can also create the new posture policy and apply on the same AD Group under "Other conditions".
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: