cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3203
Views
30
Helpful
10
Replies

ISE Posture Compliance module upgrade

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.

1 Accepted Solution

Accepted Solutions

Mike.Cifelli
VIP Alumni
VIP Alumni

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!

View solution in original post

10 Replies 10

Mike.Cifelli
VIP Alumni
VIP Alumni

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!

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.

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!

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)

 

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!

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.

 

 

 

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!

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?

 

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. 

Panos Bouras
Level 1
Level 1

hi @Srinivasan Nagarajan 

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".

Thank you,Panos.
Please Rate Posts (by clicking on Star) and/or Mark Solutions as Accepted, when applies
Getting Started

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: