In a previous post by my colleague, Stijn, discussed the new changes to how NSX for vSphere 6.4 handles Remote Desktop Session Host, RDSH, systems with the Identity-based Firewall and context-aware micro-segmentation.

RDSH 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 6.4 and the new changes to support RDSH hosts works with Citrix XenApp systems.

Citrix XenApp 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.  NSX has supported User Identity based firewalling for Virtual Desktops since the 6.0 release, but it did not address RDSH in which multiple user sessions are connecting to the same host  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 XenApp customers to follow, which brought about the use of Virtual IP addressing.

To combat the issue of each session having the same IP address in an RDS environment, Microsoft brought in Virtual IP technology back in Windows Server 2008 R2, which Citrix leveraged to provide a new IP address for each user session on an RDS host.

Virtual IP Technology

Pros

  • This helped provide more granular security by being able to institute security policies based on the session IP address
  • Useful for things like licensing of software where the IP and MAC address needs to be different

Cons

  • Requires DHCP infrastructure and more complexity added to the environment with creating loopback networking as well.
  • Requires changing registry entries on each of the RDS hosts.

Identify Firewalling for RDSH in NSX, does not require any changes to the guest OS system.  It does not require additional DHCP infrastructure and provides the same per-user session security that Virtual IP addressing can, with significantly less complexity and a similar operational experience to typical DFW rule set building.

Citrix provides the ability to access applications through the StoreFront web portal, or access RDS host systems to get a full published desktop for the user to consume.  This provides great flexibility in how a user can perform tasks.  In this post we will show that logging into a XenApp published application or an RDSH published desktop will allow us to granularly control security regardless of entry method.

NSX for vSphere 6.4 provides a more granular approach to creating Distributed Firewall policies for virtual user sessions by leveraging identity-based context.   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 Citrix 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

Citrix Configuration

In our environment we have one RDSH host for Citrix that serves not only published applications but can also provide a full published desktop if the end user requires it.  This system will be accessed by browsing to the StoreFront web interface, logging in and selecting the appropriate connections means, in this case both a web browser published app, and the web browser in the full desktop.

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 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 to from our clients to the StoreFront web site, and launch our connections to the Citrix RDSH server as each of these different users and check their access to their respective systems as well as check their block to systems they should not be accessing.

 

 

 

From these screenshots, 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.16.50.7.  Let’s check 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 NSX is no longer translating user ID’s to IP addresses in RDSH-enabled DFW sections.   NSX is translating these users into their respective Active Directory Security ID’s (SID) as part of the data plane ruleset.  Let’s double check Active Directory.

 

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

With Context-awareness, NSX for vSphere 6.4 introduces some great new capabilities, including the ability to provide per-user and per-user-session policy enforcement regardless of the underling RDSH host users are connecting to.   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.