Overview

NSX Identity Firewall (IDFW) allows security admins to control access to resources for logged in users on a machine (virtual or physical) over an VDI or RDSH.

In a simple example, users who belong to engineering group can access specific application, while users from HR group when logged in to the same machine cannot acces that specific application or resource.

In NSX-T 3.2 IDFW is supported on both DFW and Gateway firewall (T0s and T1s). NSX admin need only to enable IDFW on the required firewall and then configure firewall rules with AD groups as sources.

Lab Inventory

For software versions I used the following:

  • VMware ESXi, 7.0.2, 17867351
  • vCenter server version 7.0.3
  • NSX-T 3.2.0.1
  • TrueNAS 12.0-U7 used to provision NFS datastores to ESXi hosts.
  • VyOS 1.1.8 used as lab core router.
  • Two Ubuntu 20.04.2 LTS VMs as destination test servers.
  • One Windows 2016 DC edition VM where users will establish RDSH to.
  • Ubuntu 20.04.2 LTS as DNS and Internet gateway.
  • Ubuntu 20.04.2 LTS as Linux management host.
  • Windows Server 2012 R2 Datacenter as management host for UI access.

For virtual hosts and appliances sizing I used the following specs:

  • 2 x virtualised ESXi hosts each with 8 vCPUs, 4 x nics and 32 GB RAM.
  • vCenter server appliance with 2 vCPU and 24 GB RAM.
  • NSX-T Manager medium sized deployment with 6 vCPUs and 24 GB RAM (no reservations).

 

Preparing our Active Directory and enabling Remote Desktop on test VM

In order to use IDFW to apply security policies to your different groups and users, you need first to make sure that your Active Directory is up and running, correctly connected to NSX-T manager and NSX-T manager can list the available AD groups.

In my lab environment, I have created two AD groups Engineering and HR

I have then configured 2 active directory users, user engineer who belongs to engineering group and user hruser who belongs to HR group.

I have also deployed a Windows 2016 Data Centre server edition VM and connected it to one of my NSX-T segments called VDI, which is connected to one of my T1 gateways.

Make sure to enable remote login for both groups to the Windows VM. If you are not familiar on how to do this then you can follow the steps mentioned in this article under the resolution section. Finally, ensure that you have installed VMware tools inside this VM as I am using the guest introspection method to implement IDFW. You can also implement AD log scraping method or other 3rd parties log scraping (PaltoAlto Global protect for example, which requires loginsight) more about this can be found in VMware IDFW documentation.

Preparing NSX for IDFW

In this lab I am going to utilise DFW to enforce IDFW rules, however as I mentioned in the beginning of this blog post, NSX-T 3.2 added IDFW functionality to T1 and T0 gateways as well.

Enable IDFW on DFW and on workload cluster

From your NSX manager UI, navigate to Security > Distributed Firewall and then from the Actions drop down menu on the right choose General Settings

Ensure that Identity Firewall Status is On

Also ensure that under Identity Firewall Settings, IDFW is enabled on the cluster on which you want to use IDFW on. In my case, it is Workload cluster

Once IDFW is enabled on your DFW, we need to add our AD to NSX, so that NSX can pull the Active Directory security groups information.

Navigate then to System > Identity Firewall AD and add your AD information there and ensure that synchronization status is success. This ensures that NSX manager can pull security groups information from your Active Directory

Preparing NSX groups and configure IDFW policy and rules

Under Inventory > Groups > ADD Group add an AD group call Engineering and for membership choose Engineering AD group

Navigate then to Security and choose Distributed Firewall from the left pane, create a policy called IDFW with a rule that denies ICMP echo and echo replies to a group of VMs called Multicast_VMs which contains 2 Ubuntu VMs with IP address 100.100.100.10 and 200.200.200.20 respectively, from all users that are logged in from the Engineering AD group, however for other users from other AD groups the ping (ICMP traffic) should flow normally to both VMs.

Your DFW policy and rule should like the below

Note that the AD group must always be in the source of the rule definition.

Verifying IDFW policies

To verify the configured IDFW DFW policy, we will login to the Windows 2016 test server with user “engineer” who is member of AD Engineering group and try to ping 100.100.100.10, 200.200.200.20 and google.com. The first 2 addresses should fail as they are blocked by the IDFW DFW policy, while the ping to google.com should go through.

Then, we will login to the same VM via RDP using user “hruser” who is a member of HR AD group and redo the above ping test. This time all the ping tests should go through, as we do not have any deny rules for this AD group.

Test 1: login via RDP using engineer user

Test 2: login via RDP using hruser

Final Word

NSX IDFW is a powerful capability which enforces organisational wide security policy placement and provides micro-segmentation capability for RDSH and VDI use cases. Implementation is quite straight forward and yet powerful.

Hope you found this post useful and worth of your time.