cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2050
Views
0
Helpful
7
Replies

Cisco ISE with Anyconnect and Posture

Steven Williams
Level 4
Level 4

I have been struggling to find decent videos and documentation on how to actually get the posturing to work with my VPN setup.

 

We have the need to check for "compliance" on corporate machines before they get access to the network. So windows firewall, updates, AV checks, etc, etc. 

 

We also have three AD groups that when authenticated via VPN and ISE it gives them different dACLs based on group membership. 

 

Most examples I am seeing are "domain users" being authenticated, but that is a very broad scope. 

 

Is posture included into the same policy set as the authentication for the VPN users? I assume it is, but I uncertain how to integrate it. 

 

Currently I have authorization policy that is called "Users Unknown" and it states if you are part of the domain users group and the "WasMachineAuthenticated" true and the PostureStatus is unknown, and then it gets a user unknown authorization profile that is tied to a dACL. 

 

But what makes a status unknown? If this is my first line rule everyone is going to hit it due to domain users. So how do I make sure my IT AD groups is the IT dACL and the CSR AD group is getting the CSR dACL?

7 Replies 7

paul
Level 10
Level 10

You have 3 states of posture when you starting using that condition:

  1. Unknown- this is the default state everything would come in as because ISE has not received a posture report.  In this phase you need to make sure the posture module can find the correct ISE PSN to report posture to.  I usually do this by applying a redirect for enroll.cisco.com (72.163.1.80), making sure that IP is included in the VPN split tunneling ACL if doing split tunneling.  Once the posture module finds the PSN posture should be reported.  You should also be applying a DACL in this state to restrict access as you don't know the posture (you could start out in audit mode though).
  2. Compliant- posture module reports the device is compliant they get full network access based on your rule for compliant devices
  3. Non-Compliant- posture fails and you decide how you want to handle it.

So in full production your VPN rules may look like this:

  1. Domain Users AND Posture Compliant = full access
  2. Domain Users and Posture Non-Compliant = quarantine DACL or deny access
  3. Domain Users AND Posture Unknown = client provisioning redirect ACL to assist with posture discovery + DACL to restrict access to the PSNs so posture report can be submitted.

It is the same setup for wired and wireless basically except wireless doesn't have DACLs.

If you are only testing with a specific AD group you rules would be:

 

  1. IT AD Group AND Posture Compliant = full access
  2. IT AD Group and Posture Non-Compliant = quarantine DACL or deny access
  3. IT AD Group AND Posture Unknown = client provisioning redirect ACL to assist with posture discovery + DACL to restrict access to the PSNs so posture report can be submitted.
  4. Domain Users then allowed full access.

My authentication policies are set now as if user = member of IT group then they get IT dACL.

So then I would map the dacls in the posture policy?

I guess im asking if I need different policy sets for posture and vpn access. I dont think so I just cant grasp the logic of it.

I do not want all domain users to be able to access the network via vpn, this is why we have groups for it. But it would be nice if all the domain users would get the nac client but that is going to require 802.1x on the wire i assume for all clients to get it.

VPN is another situation because the client has to have the client to connect. But what if they just have the anyconnect client and not the nac client? Does one of the policys redirect them to download it?

Sorry this is all new to me so many questions.

I would read this if you haven't

 

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210523-ISE-posture-style-comparison-for-pre-and.html

 

That might help explain how things work.  You can use the client provisioning portal to install the posture module, but I wouldn't. I would have it installed either by the ASA or SCCM (or whatever the client uses for software distribution). 

 

 

No SCCM here, but how do you deploy using ASA, I thought you could only deploy the anyconnect client, the posture client is separate. 

The information provided by Paul is accurate and helpful.  To add some thoughts:

 

If you do not have SCCM you could always just add the Anyconnect Client into your image that you use to image your workstations.  As for the PostureStatus EQUALS Unknown you can then use an authorization profile to redirect the user to the portal Paul mentioned.  The portal will allow the user to download the posture module required for what you are attempting to accomplish.  I actually use the portal in my environment and it works great.  

 

For additional policy conditions that you can use in your policies to make them more granular you can use:

Cisco-VPN3000-CVPN3000/ASA/PIX7-Tunnel-Group-NAME EQUALS 'your tunnel group client profile'

Using the client provisioning portal can get you into trouble on wireless/wired if you aren't careful with your redirects. With OS portal detection mechanics and Outlook trying to connect right away you could cause a lot of confusion or SSL warning if you redirect to the client provisioning portal. As a rule I never use the client provisioning portal to actually do anything. I only redirect traffic to enroll.cisco.com or the default gateway to the client provisioning portal for the sole purpose of posture discovery.