I found several blogs on Internet about how to setup IDFW on NSX-T, but did not find any (might have missed them) about the full process, from setting the NSX-T part, deploying VMs from Horizon View, having users connecting to desktops and IDFW rules being applied with finally seeing what is written where in terms of logs.
In this article, I will put the emphasis on the NSX-T part, the prerequisites on the desktops themselves, and the how it works at the end.
Here we have a vCenter 6.7u3 with a cluster having NSX-T 2.5.1 (works the same with 3.0 btw) configured and IDFW enabled, and Horizon View 7.8 provisioning Desktops using IDFW rules
As part of a NSX micro-segmentation approach, we can use the capabilities of NSX firewall based on AD membership (IDFW) to restrict administrative flows to VMs only to those who are in charge of managing them.
To do this, it is essential to use a VM that is in the NSX fabric and have opted for a VDI-type solution (Horizon View 7.8), with provisioning on the fly and destruction of the VM as soon as it is switched off.
Prerequisites to IDFW
I will not cover the how-to setup a desktop pool in Horizon View, but you will find the prerequisites that are necessary in the desktop (Windows only) to have IDFW working:
On the master you will update/install the VMtools to the latest release but perform an interactive install and choose at least the NSX File Introspection driver and NSX Network Introspection driver. VMware Tools full installation adds these by default.
Understand that the IDFW rules in NSX-T only apply to source, thus must be applied to the VDI desktops. It doesn’t work if the rule is applied on the destination. You can make it easier and create the IDFW rules in a section that is applied to everything, but it’s not part of the best practices at all.
Configure Active Directory domain in NSX-T
- in the NSX-T manager go to System -> Active Directory -> ADD Active Directory
- set the informations
- add LDAP Servers
- wait for the first synchronization to complete
Enable IDFW on the cluster
- first check if IDFW is enabled :
- enable the desired cluster
Create the AD-IDFW NSGroups
- 1 NSGroup per IT Service has to be created, here for the IT Service S3
- go to Advanced Networking & Security -> Inventory -> Groups ->Groups Add
- go in the Members, select AD Group as a type an chose the AD security group you want to use
Create a new general section for the VDI
- in NSX-T I will create a new section called VDI-Secu that will apply to the VDI dedicated overlay
- I will create the following 4 rules in this section:
- one that allows the traffic in the VDI overlay,
- one that allows the VDI overlay to communicate with what is necessary to the VDI to actually work (connexion brokers, security gateway),
- one that denies the access to tagged VMs (here every VMs for which I want to use IDFW to connect to),
- the last one (was necessary for my use case) allows the overlay to access the rest of the network.
Create a AD-IDFW-Rules section
I will create a new section in which every IDFW rules will be created. This section has to be above the VDI section created previously and will apply to the VDI dedicated overlay
Create the AD-IDFW-Rules’ Rules
One firewall rule in the AD-IDFW-Rules section per IT Service has to be created. Here for the S3 IT Service.
- Go to Advanced Networking & Security -> Security -> Distributed Firewall -> Add rule in the AD-IDFW-Rules section
- In the source you will specify the Identity NSGroups for the service admins created in the previous steps
- and as destination you’ll use the NSGroup of the IT Service VMs
- Enable logs, use the rule name as tag (will be useful in the monitoring part of this article) and select the good direction OUT
- Don’t forget to publish!
I have here 2 rules for 2 different services.
IDFW in action
First I would like to highlights where to find the logs. Of course, the logs of the NSX-T firewall rules are either in the manager log or in a centralized logging system (here vRealize LogInsight).
But what about the IDFW log, how are we certain that, when a user logs into a VDI, the information is correctly passed to NSX-T? These particular logs are on the NSX Managers/Controllers. But you have to see in every manager node the IDFW logs that are populated in the “current ESXi Host’s controller node” 🙁
On a personal note, I have opened a RFE to VMware, in order to have these logs forwarded into syslog
On the node(s):
- Use st en to enter engineering mode (root privileged mode)
- Now on each node search in the log files to find Login and Logout entries,
- Here in the example the node #3 has the entries from a IDFW activity (USER_LOGIN in a VDI that have guest introspection),
- Run the following command:
cat /var/log/proton/nsxapi.log | grep IDENTITY-FIREWALL | egrep -i “login|logout”
- Here you find the the user [INTRANET\krejci] logged in
- Finding these entries indicates that the VM correctly pass the login information to the hosts, and that the IDFW mechanism is working at this level.
- Once this part is checked, you can go on vRLI to see the Firewall rules logs.
Example 1
From a VDI, user INTRANET\Krejci will try to connect to ssh to a VM in the S3 service.
The user INTRANET\Krejci is in the AD security group for the S3 Service. Thus he will be granted to ssh to the machine “itss30001”
It works, but how can we be sure that it has something to do with the IDFW we set up?
The answer is: you will find the corresponding firewall rule information in vRealize LogInsight.
- In the first log entry you have the rule’s name: IDFW-allow-s3-Adm-out and the group SID of the group in which the user belong:
Example 2
Ok it worked to allow through the IDFW rule, now let’s see what happend when I want to access a VM for which I’m not supposed to connect..T
From a VDI, user INTRANET\Krejci will try to connect to ssh to a VM in the xaas service. The user INTRANET\Krejci is not allowed in the portal-xaas group for the XaaS Service. Thus he will not be granted to ssh to the machine “itsxaas0490”.
You will find the corresponding firewall rule information in vRealize LogInsight:
You will see that the rule deny-VDI-Secu-out (which is located in the general VDI section) is hit.
voilà, this concludes the NSX-T Identity Firewall, how it really works’ article
In my opinion, this is a great example of synergy between 2 products, Horizon View and NSX-T to bring a next level of security in your environments.