Identity-based firewall for RDSH with VMware NSX-T 2.4

After a long break in blogging, I am back to share my experience with VMware NSX Datacenter. Today, we talk about Context-Aware Micro-Segmentation by implementing the NSX Identify-based Firewall (IDFW) feature. IDFW allows an administrator to create Active Directory user-based Distributed Firewall (DFW) rules. It can be used for Virtual Desktops (VDI) or Remote desktop session (RDSH support).
This post describes how to configure NSX Datacenter with IDFW in order to allow user access to a specific application via Remote Desktop Session Host (RDSH) systems.

Topology 

First, let's take a look at the lab topology.



  • We have two (2) users: Bob from the HR team and Charlie from the DevOps team. Both are using the same Remote Desktop host to reach their respective applications IceHRM and Planespotter via HTTP and HTTPS.
  • On the network side, we have a NSX Tier0 Gateway connected to:
    • NSX Tier1 Gateway to access to the following applications:
      • HR application (172.16.100.100) connected to the application segment
      • DevOps application (172.16.100.101) connected to the application segment
      • RDSH (172.16.200.101) connected to the RDSH segment
    • The management network to communicate with the Active Directory domain controller based on Windows Server (10.9.99.150)
    • The outside network for external communication - We used a specific Destination NAT rule to reach the RDSH VM based on Windows Server (10.0.10.209 <=> 172.16.200.101)

IDFW flows 

The following diagram shows interaction between each component.
  1. First, the NSX Management has to be synchronized with the AD domain controller in order to access to AD groups: HR and DevOps groups.
  2. A user logs in to a RDSH VM.
  3. The user starts a network connection, by opening a web browser with the application URL.
  4. Each time, a user logs in to the RDSH, the thin agent vmtool will send an event to the Context Engine in the hypervisor ESXi with connection information and identity information.
  5. The context engine forwards the information to NSX Distributed Firewall (DFW), residing in the hypervisor, for any applicable rule enforcement.
  6. For the first connection, the Context Engine sends the connection information and identity information to the NSX manager.

Technical Requirements

  • We are using NSX-T 2.4 in the lab environment.
  • The Microsoft Active Directory Windows Server can be 2008/2012/2012R2 - here, I use 2012 R2.
  • The Microsoft Remote Desktop Windows Server can be 2012R2/2016 - here, I use 2012 R2.
  • VMware tool version 10.3.10 or later full installation (including NSX File Introspection driver, NSX Network Introspection driver, VMCI driver) on the Microsoft Remote Desktop Windows Server.
  • Remote Desktop Service Role installed on Remote Desktop Windows Server.
  • Same NTP server configured on NSX manager, AD domain controller and the RDSH.

Configuration

Let's see the configuration now on NSX Manager.

1. Enable IDFW

The following diagram shows on to enable the IDFW feature on a specific cluster. Be sure to enable IDFW on the compute cluster where applications and RDSH are located.

2. Add AD domain controller

In order to allow a user to access to a specific application based on his active directory profile, NSX manager must communicate with the AD domain controller.
Notes: 
  • Step 6 - the Base Distinguished Name format has to be "DC=ovn,DC=local"
  • Step 8 - don't need to change default the LDAP port and use the AD credentials.

3. Check the AD connection and Synchronization

To validation the communication between NSX manager and the AD domain controller, you can check:
  1. The connectivity status on the network side.
  2. The Synchronization status on the aplication side.

 

4. Create AD Security Groups

When you have done with the AD synchronization, you can now create Security Groups based on AD group information. In the following picture, you can see that "DEVOPS" group is available.
 In my case, I created:
  • Two (2)  Security Groups based on AD Groups: DevOps-Users-SG and HR-Users-SG.
  • Two (2)  Security Groups based on VM name to identify applications: DevOps-Apps-SG and HR-Apps-SG.
  • One (1) Security Groups based on NSX Tags and Scope to identify the RDSH: RDSH-Machine-SG
  • Optional - Two (2)  Security Groups based on NSX Scopes to identify environments: Prod-Environment and Dev-Environment (not shown below - the purpose is to block any communications between Dev and Prod environment)

5. Create Firewall rules

Finally, it's time to create firewall rules based on Security Groups created in the previous step.
 For both applications, here is the logic behind those firewall rules:
  1. Allow access from AD Users group to the specific application. This is where we use IDFW feature. I applied it to RDSH-Machine-SG and X-Apps-SG
  2. Allow access from RDSH to the specific application. This is required to get responses from X-Apps-SG. This FW rule is applied only to X-Apps-SG, otherwise all users will be able to access to the X-Apps-SG.
  3. Allow external communication from the specific application. Applied to X-Apps-SG.
  4. Drop all non specified traffic.  Applied to RDSH-Machine-SG and X-Apps-SG.

Validation

As expected, the user Bob from the HR team is able to reach only the HR application (172.16.100.100). This is true also for the user Charlie with the DevOps application (172.16.100.101). We demonstrated the IDFW capability with RDSH use case.

Troubleshooting

To go deeper, here are some commands for troubleshooting purpose.

On the Control Plane:

  1. Log in to the NSX Manager, go to the Security and Distributed firewall sections and enable logs on a specific firewall rules
  2. On the Advanced UI, go to the Security and Distributed firewall sections, open the specific section, you should be able to see FW rule ID. The FW rule ID is used in the Data Plane to identify hitted firewall rules.

On the Data Plane:

Below, you can see the correlation between the AD domain controller and the ESX hypervisor. They use the same Security IDentifier (SID) to identify the AD User Group.

Moreover, if you want to see realtime logs and validate which firewall rule is hitted, you can use the command: tail -f /var/log/dfwpktlogs.log on the ESX server.

I would like to thank Geoff Wilmington, our NSX/EUC guru for helping me on the troubleshooting section and Erik Hinderer for his great post on the same topic with more details on NSX deployment. See below for references.

If you have any questions or comments, feel free to contact me. 

References


Comments

Post a Comment