09-03-2019 05:43 AM - edited 02-21-2020 11:09 AM
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.
Solved! Go to Solution.
09-03-2019 06:31 AM
09-04-2019 07:00 AM
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.
09-04-2019 01:49 PM
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.
If these dont work then you can consider falling back to DAP. But I dont think you want that.
-Krishnan
09-03-2019 06:31 AM
09-03-2019 09:09 PM
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.
09-03-2019 09:19 PM
Do you have link I can check how to do two vpn profiles that can separate corporate and non-corporate machines?
09-04-2019 05:53 AM
09-04-2019 06:00 AM
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.
09-04-2019 07:00 AM
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.
09-04-2019 01:49 PM
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.
If these dont work then you can consider falling back to DAP. But I dont think you want that.
-Krishnan
09-05-2019 10:28 PM
09-06-2019 05:47 AM
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.
09-09-2019 01:53 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide