In a previous post my colleague, Stijn, discussed the enhancements to how NSX for vSphere 6.4 handles Remote Desktop Session Host, RDSH, systems with the Identity-based Firewall and Context-Aware Micro-segmentation.

Remote Desktop Services is an underlying technology from Microsoft that many vendors take advantage of to provide overlay management and application deployment technologies for.  In this post, we’re going to discuss how NSX for vSphere 6.4 allows customers to run RDS hosts with granular security for VMware Horizon systems.

VMware Horizon can provide multiple users the ability to connect to a single system to access their applications using the RDSH technology.  These users can be of the same type, for example all HR users, or of multiple types, HR and Engineering users.  In previous versions of NSX, it was not possible to individually secure user sessions and create Distributed Firewall (DFW) rule sets according to the user session logged into an RDSH server.  This meant less flexibility in controlling what users could access data center application servers without isolating one set of users to one RDSH server.  This model created a very rigid architecture for Horizon customers to follow.

Horizon allows customers to spin up Windows Server systems with the RDSH components installed on them and the Horizon agent, for users to connect into.  These systems can be brought up and down as needed.  Users can also connect through the Horizon Client and gain access to published Applications.  These applications are hosted on RDSH servers and security can be provided the same way regardless of entry point into the RDSH back-end.  In this post, we will show that logging into an RDSH desktop or through the Horizon published application, will allow us to granularly control security.

NSX for vSphere 6.4 provides a very granular security approach to providing Identity-based context to creating DFW rule sets for RDSH systems.  We’re going to look at the problem identified above, how to allow both HR and Engineering users access to the same RDSH system, but only allow each user to access specific data center application servers and block access to ones they shouldn’t have.

In our environment, we have Horizon installed with an RDSH system configured for access by our HR and System Engineering users, Bob and Alice.

Requirements

  • Bob requires access to the HR Application
  • Alice requires access to ENG Application
  • Bob should not have access to ENG Application
  • Alice should not have access to the HR Application

Environment

Horizon Configuration

In our environment we have one RDSH system for Horizon that serves not only published applications but can act as an RDSH session host and provide a full desktop to the end user if required.  This server will be the connection point to launch a browser to access the respective applications and to launch a full RDS desktop to access the application.

NSX Configuration

The first thing we need to do is configure Active Directory synchronization in the NSX Manager.  Look at this documentation on how to add an Active Directory domain to the NSX Manager.  We should see a Last Synchronization State of ‘SUCCESS’ and a corresponding timestamp that is valid.

We can configure and NSX Security Groups and add in the Directory Groups for HR and Engineering into their own Security Groups.  We will use these Security Groups to create our DFW rule sets.

NSX rules can now be built using the NSX Security Groups for each set of users.  RDSH session identity is established in the DFW by creating a new DFW Section and enabling the ‘Enable User Identity at source’ checkbox.  This will tell the DFW to look at the source as containing user Identities and will make the translation to their Active Directory Group SID for enforcement.

We need to write our rules for each of these AD Groups and users accordingly.

We put the Security Group for HR in the source of one rule, the server running the application that the HR users require access to run the application.  We do the same for the Engineering Security Group and add in the ENG Web Server as the destination application server for them to access.  Below this we will write a Block rule to the destination for each of the user groups, preventing them from accessing resources they shouldn’t be.


With the DFW rules in place, we can connect using the Horizon client as both users.  Once logged as each of these different users we can check their access to their respective systems as well as check their block to systems they should not be accessing.

From this screenshot, we can see that Bob has access to the HR application as he should, and that Alice cannot access the HR Application.  Let’s see if Bob and Alice can access the ENG Application.

We can see now that Alice, our engineer, is able to access the ENG Application (Horizon Administrator) and that when Bob attempts to access, he’s met with denial as should be expected.  This demonstrates that NSX can help micro-segment RDSH systems, even if they are published applications on the same machine with different logged in users.  Next, we’ll try this with an actual RDS Desktop.

Both Bob and Alice are logged in to their respective RDS session and we can see that they are indeed two different desktops, but are both being presented by the same RDS server.  Now we can perform the same tests we did when we logged into the published application.

We’ll try the reverse and attempt to access the other applications, and we see that we’re getting the same results.  Alice can now get to her application and Bob is denied access as expected.

Looks like our rules are working as they should.  In NSX for vSphere 6.4, we can click on the Security Group for each of the user groups and see the last logged on user in that group and from what server they’re logged into.  We can see that both Bob and Alice are accessing the same RDSH host with an IP address of 172.25.16.53.  Let’s check the DFW Security Groups and then the filter rules to show how the information the DFW is using for each rule set.

NSX is showing proper identities in the Security Group details for each user and their respective Active Directory Group.  But let’s look at these rules at the data plane level.

The main takeaway here is that for RDSH-enabled sections in the DFW, NSX uses the Active Directory Group SID instead of the IP address for mapping rule sets.  NSX translates these users into their respective Active Directory Security ID’s (SID) as part of the data plane rule set.  Let’s double check Active Directory to verify the group SIDs.

We can see that the SIDs ending in 1314 and 1315 represent the Active Directory group SIDs and hence we have our match.

NSX for vSphere 6.4 introduces some great new capabilities in being able to secure RDSH systems at a per-session and per-user level.  This granular security approach means less operational complexity overall for customers and more flexibility in which users can connect and run their applications on which host system.