Identify Corporate vs. Non-Corporate Machine Connecting to Anyconnect VPN with ISE as radius server

[misinsuan2229]

Hi Cisco Community,

We are deploying ISE Posture over our Anyconnect VPN endpoint where AD users will be posture based on AM and PM definition. We also wanted to add to differentiate corporate and non-corporate machine used by AD users connecting to VPN so we can have different policy set and posture policy for each. Checking - I can't find to seem any info coming from the machine like hostname or domain that we can use as attribute to differentiate machine.

Anyone has idea or similar problem that has resolution already? Can't seem to find good documentation or solution on the internet.

[Mike.Cifelli · Accepted solution]

Under your posture policy in 'Other Conditions' you can match on tunnel group name (Cisco-VPN3000:CVPN3000/ASA/PIX7x-Tunnel-Group-Name EQUALS <NAME>)

Essentially you could configure two separate client profiles for both VPN use cases (domain/non-domain) and leverage that tunnel group condition. Under the vpn profile configuration.xml that goes under a hidden path on workstations (C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile) the tunnel group name matches on <UserGroup> under <HostEntry> field.

As far as a posture check to determine if host is a member of domain you could do this:
Registry condition check:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History\
MachineDomain
String Equals
<DOMAIN NAME>

Good luck & HTH!

[misinsuan2229]

Hi Mike,

I am not sure about the separate client profiles, is that in ASA-VPN config to check?

For the registry condition check, can I use this as condition in posture policy so I can set different requirements for corporate and non-corporate machines?

What we wanted to achieve is that for AD users, we wanted that during vpn connection when they are using corporate machine then they will be only ise posture (audit), but if they use non-corporate machine on connection that is when we do ise posture as mandatory.

[misinsuan2229]

Do you have link I can check how to do two vpn profiles that can separate corporate and non-corporate machines?

[Mike.Cifelli]

For the registry condition check, can I use this as condition in posture policy so I can set different requirements for corporate and non-corporate machines?
You will need to use other conditions in your client provisioning policy prior to using the reg check. The reg check would be used during posture checks. Something you can utilize to differentiate via conditions could be AD:ExternalGroup EQUALS Whatever security group you wish.

I strongly recommend watching free tutorials to get a better understanding:
http://www.labminutes.com/video/sec
Here is a cisco doc as well that may assist:
https://www.cisco.com/c/en/us/td/docs/security/asa/asa97/configuration/vpn/asa-97-vpn-config/vpn-groups.html

Good luck & HTH!

[misinsuan2229]

Yeah, currently connecting to VPN is via users AD login and AD check is based on that security group. Not sure how to differentiate corporate to non-corporate laptop from the ISE.

[paul · Accepted solution]

Skip the registry check in my opinion.  If the only thing you want to do is differentiate corporate from non-corporate then have the ASA do a cert check for the corporate VPN connection.  You would setup 3 group URLs on your VPN setup:

https://vpn.mycompany.com/corporate

https://vpn.mycompany.com/personal

https://vpn.mycompany.com/vendor

The corporate group URL would be setup to do AAA + certificate.  The ASA will check for a certificate right away.  If the device does not present a certificate from your internal CA the VPN connect is terminated. 

For the personal group URL you can let them connect with AD credentials but then apply a DACL or and access-list to limit where they can go because they aren't connecting from a corporate device.  Usually I tell customers to only allow RDP access so they can RDP into a VDI solution or RDP back to their corporate desktop/laptop.

The vendor group URL would be to allow vendors to connect and you would apply DACLs or access-lists based on the vendor and what they need access to.

[kthiruve · Accepted solution]

Here are few options based on coversation above and also using ACIDEX

1. Registry check is good if you can check something unique about the machine.

2. Certificate check is good as long as your corporate laptop has machine certificate.

3. You can also use MAC address if you have a list of MAC addresses already. You can gather the MAC address information via ACIDEX attributes. This is independent of posture. you can use the attributes to verify the MAC of corporate machine and allow access.

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/118944-technote-anyconnect-00.html

If these dont work then you can consider falling back to DAP. But I dont think you want that.

-Krishnan

[misinsuan2229]

Actually - we will be deploying posture endpoint assessment and wanted to separate corporate and non-corporate so they'll have different posture policies to be check. Checking on the conditions/other conditions I can check on vpn group so your suggestion looks to be more suitable in our environment - but the concern here is client can just import the internal certificate to their non-corporate machine then we cannot determine that, right?

Anyway, do you have some more options for this setup? Or VPN group is the one we can do to separate machines and do different posture policy for each?

[paul]

You can't just import a certificate and have it do anything. In order for a certificate to be used in authentication you have to also be able to export the private key.  If your users are able to easily export a corporate CA issued cert/private key you might as well trash your current CA as its trustworthiness is no longer there.

If you can separate the users into two different group URLs (corp and non-corp) then you can use the tunnel group name to separate your posture policies. 

Let's say for now you skip the certificate thing.  Still create two group URLs which are defined at the tunnel group level:

Tunnel Group= Corp (URL-https://vpn.mycompany.com/corp)

Tunnel Group= Non-Corp (URL- https://vpn.mycompany.com/non-corp)

In your posture policies you can use the VPN 3000 Tunnel Group attribute to check for corp or non-corp.  Then check corp users for domain registry entry, corp AV, SCCM, etc.

[misinsuan2229]

Thank you.