One of the main new features in VMware NSX 6.4 is the Multi-User (or RDSH) Identity Firewall. With this feature, it is possible to microsegment traffic, based on User-ID. I have been looking forward to this feature, since a couple of my customers have been waiting for it and it is a very powerful addition to the already pretty packed microsegmentation functionality.

I already wrote about this on my company-blog (in Dutch: http://www.pqr.com/blogs/nieuwe-versie-nsx-met-grote-stappen-voorwaarts) and in this article I will dive a little deeper into the underlying technology.

In order to use IDFW (with or without RDSH), it is necessary to connect NSX to an AD-domain. There are two methods of retrieving the user-information:

• Log-scraping
• Guest Introspection

With log-scraping the logs of the Domain Controllers are “scraped” and logons are thus detected. With Guest Introspection, the information is retrieved by a VM that needs to run on each host.

Since I wanted to use the Guest Introspection method, I created a new domain, with a new Domain Controller, running on Windows 2016. This is a prerequisite when using the Guest Introspection method. Another prerequisite is the use of the Guest Introspection feature, within NSX. It means deploying the GI-VM’s. More information about this can be found here: Install Guest Introspection on Host Clusters

So, I created a couple of users and a couple of groups:

User Piet is a member of the HR group, user Janine is a member of the Financiën group and user Ben is a member of the Administratie group.

After creating the users and groups, I connected the domain to NSX:When the connection between the domain and NSX is successfully synchronized, it becomes possible to create a new Security Group within NSX with the AD-groups in it. I created 4 security groups:

• Administratie
• HR
• Financiën
• HR+Financiën

The “HR+Financiën” group contains both the HR and the Financiën group and used nesting.

Important is that the Section where the rules are placed in, needs to be enabled for “User Identity at source”:

Within the DFW I created a couple of rules, based on the security groups that were created. I used a couple of client-vm’s to test the connectivity to:I created rules for “Administratie” to connect to Client03 and Client04 on HTTP and RDP and for “HR + Financiën” to connect to Client01 and Client02.

Then I created rules to block traffic from the other users to the clients.

So when logging in to my RDSH-host, I should be able to RDP into Client03 only if I am Ben, and to Client01 and Client02 only if I am Piet or Janine. When accessing Client01 on HTTP, I should have a connection when I am Piet of Janine, but not if I am Ben.

When I click on the security group in the DFW, I get the information about the user-sessions that corresponds to the security group:

So, when Piet tries RDP-ing to Client01 or accessing its website (default IIS ;)), it looks like this:When I am Ben, RDP-ing into Client01 or accessing it’s website, I get denied, but RDP-ing into Client03 is allowed:

And when I look at Ben’s activity in vRealize Log Insight (don’t microsegment without it), I see the rules being applied as expected:

Reading from the bottom, the first line indicates the allowed RDP traffic to the “.3” (which is Client03). The 3 lines above that, show that RDP traffic to the “.1” (Client01) is nót allowed. And the 4 lines above that, show that HTTP traffic to Client01 is also not allowed.

When looking at Piet’s log:

We can see that RDP ánd HTTP to Client01 is allowed.

So, all in all a very nice addition to NSX.