NSX-T 3.2 Active Directory based Groups

[LukaszDziwisz]

Hello All,

I'm hoping to see if anybody might have any insight into the problem that we are seeing with Active Directory based groups and rules not applying properly. 

Here is the scenario:

I have created 2 persistent virtual machines GUAT1 and GUAT2 and created group for them called GUAT_persistent and selected the 2 virtual machines

Then, I have created one active directory based group called Test Group and added my account to it, then logged in to one of the VMs above.

Here are the rules I have configured 

So, after doing that I’m signed in to GUAT1 persistent VM and tried pinging GUAT2(member of the GUAT_Persistent) and it fails. But it does work when pinging Test Server object which is an external server that lives in another vCenter not managed by this NSX-Manager. The Test Server is a group that consists the IP of that destination server.

Then I have changed Service from ICMP to RDP and got the same result. For the GUAT_Persistent group, I have tried definining it by Ips only, OS name, virtual machine name and simply selecting VMs but the result is the same each time.

So to me it appears that the identity based rules are not getting applied properly when we deal with VMs that live within the same Compute manager managed by that NSX-Manager but it does apply properly when the destination is an object that doesn’t belong to that vCenter

Also, what I'm seeing is that if I click on members of the Test Group it always only shows one object even though there is more users logged in that belong to the same AD group and their VMs should be showing up here. At least it did back in NSX-V

I have 4 different standalone vCenters 2 in production and 2 in UAT for my Horizon Pods with instant clones and some persistent VMs and it appears to be happening on all 4 of them. The production ones were migrations from NSX-V to NSX-T using the migration coordinator where the UAT ones were brand new inmplementations on NSX-T. There are no overlays, Edges or Tiers configured as it is just for microsegmentation. 

I have updated them from 3.2.0.1 to 3.2.1.2 (newest) seeing a lot of fixes for Identity portion and hoping it will be resolved but to no avail. I do have a support ticket opened and working with an engineer on it but wanted to see if somebody here might have seen anything like it?

[Stephan_Zur]

Hi Lukasz,

Did you find out what the issue was with IDFW on NSX-T 3.2?

I am in the middle of a V2T migration with IDFW going to NSX-T 3.2.

Any hints or possible pitfalls would be interesting.

Thanks
Stephan

[ralbertodacu]

I had a similar issue when I was testing the Identity Firewall on my home lab:

- VM A, logged in with a User from my "Allowed Test Group";

- VM B, target VM that I was trying to connect via SSH;

My firewall rules looked similar to yours (AD Group allowed to speak to VM Group where VM B was), however I could not establish a connection.

The only way I could make it work at the time was by explicitly allowing the return traffic. In other words, I had to create another rule that would allow VM B to speak to VM A. You can test it with an "Allow Any Any" rule and, if it works, narrow it down just to the specific traffic you're looking for.

Hope this helps.

[LukaszDziwisz]

Hmm that is interesting. When I look at the block in LogINsight though I see traffic getting blocked from the VM that I'm logged into with the AD group to the destination VM.

let me test that and I'll get back with you. 

[Perttu]

Hi,

When the connection destination is also an NSX managed VM then the DFW applies in two places:

First it applies to the egress traffic leaving a client and here the IDFW memberships can be taken into account because VMtools Network Introspection driver feeds the DFW with a relevant information about the user identifier (SID) owning the sending network socket.  

Secondly it applies to the ingress traffic arriving the server and here the IDFW doesn't apply least with the network introspection technique. The connection itself doesn't carry any identity bits. However when using AD DS Security Log Scraping method it could apply here as well.

So the issue you're seeing here is DFW dropping traffic at the ingress to the server. Best way to avoid this kind of trouble is to scope the rules so, that you think egress rules for VDI VMs and ingress rules for servers listening connections differently.

[ggovek]

This is how it works for me:

---

@ralbertodacu wrote:

I had a similar issue when I was testing the Identity Firewall on my home lab:

- VM A, logged in with a User from my "Allowed Test Group";

- VM B, target VM that I was trying to connect via SSH;

My firewall rules looked similar to yours (AD Group allowed to speak to VM Group where VM B was), however I could not establish a connection.

The only way I could make it work at the time was by explicitly allowing the return traffic. In other words, I had to create another rule that would allow VM B to speak to VM A. You can test it with an "Allow Any Any" rule and, if it works, narrow it down just to the specific traffic you're looking for.

Hope this helps.

---

[LukaszDziwisz]

@ggovek 

I completely agree with how you have it working however I have users on Instant Clone pools and I would need to now create a group by VM name and effectively allow 100 users RDP access to the destination instead of just 5 of those users having that access. If it was on persistent VMs I agree that this would be the workaround. Also, with your rules I believe that anyone who would log in to WIN-1 and WIN2 would now have https and SSH access to WEB 80 therefore rules 2077 and 2072 wouldn't be applicable right?

[Perttu]

@ggovek and @LukaszDziwisz 

I think you both should use scopes in these rules.

First create a policy with VDI VM scope. The scope applies firewall rules under the policy to VDI VM's only. Use a segment or a vm name prefix as a filter for the group used in scoping. This policy is meant exclusively for egress traffic for the VDI VM filters.

Under this first policy just add one/two rules. Two for a blacklist or one for a whitelist. I'll use a blacklist as an example.

1.  For group X allow RDP to destination servers Y. ( This can be also applied to only direction OUT here)
2. For everyone else (source: any) deny everything to servers Y. ( same)

Then create a second policy with server VM scope. You can use group servers Y as a scope here. This policy is meant exclusively for ingress traffic for the server VM filters.

1. For VDI VMs (use the same group here as a source, that you used to scope the first policy) allow RDP to any/or destination servers Y. ( This can be applied to only direction IN)
2. For everyone else deny RDP to servers Y. If you want only RDP connections from direction of VDI VMs. Otherwise something else.

With the help of scope you can divide the DFW into different sets of rules, which is quite helpful in the IDFW case.