VDI Access Control with ISE

[SiJian Bao]

Hi Guys,

Can ISE do the Access Control for the VDI users with thinclients like PCs? Now we wanna to setup the 802.1x authentication for the VDI users, but i'm not sure if this can be done by ISE. Do we just need to configure the access switch ports to open 802.1x as usual and the switch then will relay the radius to ISE?

[harvisin · Accepted solution]

Hello,

The link below might help you out:-

http://blogs.cisco.com/borderless/using-trustsec-to-simplify-virtual-desktop-infrastructure-vdi-deployment/

[SiJian Bao]

Hi Harvinder,

Thanks for your link. So it means that a nexus switch is necessary in such a situation as the SGT is the only way to identify the data of each VDI?

[aqjaved]

IT must have a strategy for protecting business data on all devices whether corporate managed or employee self-supported and managed. This may include a secure business partition on the device which acts as a container of corporate data that can be tightly controlled and may also include the need for a Virtual Desktop Infrastructure (VDI) application to allow access to sensitive or confidential data without storing the data on the device.

For configuration, please visit

http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/byoddg.html

[Muhammad Munir]

In virtual mode applications exist on the application server in the data center (or cloud) and are represented through a VDI client on the device. Data is not stored locally on the BYOD device. Only display information is exchanged and rendered on the BYOD device. While this method provides maximum data security, user experience may be a compromise due to the translation from an application server to the form-factor and OS native to the BYOD device.

For more information please go to this link:

https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=70396897&rKey=8522644a31d2b126

[SiJian Bao]

yup, you are correct. But according to the doc that Harvinder provided above, each user can be authenticated by anyconnect 3.0 and there data can be controlled by SGT feature. But for now I don't have the nexus 1000v so that i cannot use the SGT. I'm wondering if I can use the multi-auth to authenticate the whole application server so that i can control the access permission of the virtual machines.

[MARK BAKER]

SiJian,

Is the Nexus 1000v required for the solution depicted in the doc provided by Harvinder? I don't see it listed. I would appreciate any information about this solution. I'm having troubling finding any details about it. I keep coming across that one document.

My infrastructure:

Cisco UCS blade servers (VDI)

6248FI

Nexus 5548UP

Cisco ACS

The 6248FI is directely connected to the 5548 and is where I was planning to enforce the SGT/SGACLs. Would setup support this solution? Do I need the Nexus 1000v?

Thank you,
Mark

[Tarik Admani]

Mark,

For enforcement you can use the 5500 based on the guide below.

http://www.cisco.com/en/US/solutions/collateral/ns170/ns896/ns1051/solution_overview_c22-591771.html

Tarik Admani
*Please rate helpful posts*

[MARK BAKER]

Tarik,

There are different types of devices capable of doing the enforcment based on SGT. The real unknown for me and what I am having the most trouble finding information on is how AnyConnect 3.0 installed on the VM desktop is used to authenticate the user and set the tag. Is the VM desktop using the Vsphere dSwitch or does it require the 1000v switch? From my understanding, neither the dSwitch, nor the 1000v does 802.1x authentication. What is triggering the authentication, and what it the communication path (EOPoL, Layer3, tunneled, EoIP) between AnyConnect 3.0 and the authenticating/tagging device (ISE, ACS)?

Thank you,

Mark

[SiJian Bao]

Hi Mark,

From my experience of my project and the information from cisco TAC. There are three ways to do the authentication of VDIs.

1. Use SGT by nexus 1000v or n5k, etc.

2. Deploy an ASA inside your LAN to be the intranet VPN gateway. Every virtual machine should use anyconnect to dial the VPN and this will trigger the 802.1x authentication. But I don't think this will be a good choice, it means that all the data should be centralized to the ASA and this may be the bottleneck.

3. Use the multi-auth mode on the port of the switch which is connected directly to the UCS. But this needs the port to be an access port which means there can only exist 1 VLAN in the UCS and there cannot exist any channel port.

[MARK BAKER]

After again going through the document at the link provided by Harvinder, I have to assume EAPoL is passed through the dSwitch to the VM host connected access switch at which point 802.1x is triggered. That brings up another question. Since many times VM host to access switch connections are etherchannel trunk ports, is 802.1x possible and can it be configured on a certain vlan or is it enabled on all VLANs of the trunk?

Thank you,

Mark

[SiJian Bao]

I'm sure that 802.1x cannot be supported at neither trunk ports nor etherchannel ports

[MARK BAKER]

SiJian Bao,

That was what I was finding as well. The document that I was ready seemed to contridict itself though. One section said 802.1x is not supported on trunk or etherchannel ports. Then, in another section it said 802.1x VLAN assignment was not supported on trunk ports. Why include that statement if 802.1x is not supported on trunk ports at all?

I have to now assume you would have to have a single non-trunk connection for the VLAN of the VM desktops you want to authenticate and tag. That would be a lot of cables if you had many VLANs you wanted to configure with this feature.

I guess the concept is that you wouldn't need many VLANs because now you are tagging the traffic based on the user that logged into whichever desktop. IP address assignment would no longer be a concern (unless you consider VM desktop to VM desktop traffic from different security groups a concern).

Thank you,

Mark

[SiJian Bao]

Hi Mark,

Yup, you are correct. Using SGT to do the authentication has nothing to do about 802.1X. It's all about the endpoints which means the authentication cell is the VM. No need to trigger dot1x. The ISE, nexus and switch or asa will do it automatically, that leads to the no-perception authentication to VDI users.

[MARK BAKER]

SiJian,

Thank you for the post listed the 3 options. I hadn't considered option 2. I am looking into that one right now. The VMs that need access controls on my project would not be used frequently and would not be that numerous. This is an option worth consideration for us. Another option that came to mind after seeing that option, is to use the ASA Identity-based firewall feature. Do you or anyone else have experience using it?

Thank you,

Mark