Identity Firewall (IDFW) - DFW rules are not matched for AD Users

VMware vDefend Firewall VMware vDefend Firewall with Advanced Threat Prevention

The Identity Firewall (IDFW) feature relies on successful user logins to populate AD-based NSX groups that pertain to the source field in a DFW rule.
Although your user logins are successful and appear as Active on the UI, you notice that the desired DFW rule is not getting hit.
In addition, the NSX group shows no effective members, as shown below:
In the ESXi host, the DFW rule is missing a key component that defines it as IDFW-based: with ext_src_ip addrset rextip
- Refer to KB 312444 to learn how locate the rule via the CLI using vsip commands
- Example of rule with IDFW components:
```
rule 47 at 8 inout protocol tcp strict from any to any port 3389 with extended src <UUID> with ext_src_ip addrset rextip<num> accept
```
- Example of rule without IDFW components:
```
rule 47 at 8 inout protocol tcp strict from
```
  any to any port 3389 accept

VMware NSX - All Versions

NSX Groups

There are several reasons why an NSX group will not show any effective members or is missing an expected member:

The LDAP Directory User database is not up-to-date so even if a user successfully logs in, NSX will not be able to map the user to its AD group.
The NSX Group is not pointing to the correct AD group.
The user is not truly member of the AD group, thus AD mapping is failing. This explains why the NSX UI shows the session as "Active" but the IDFW-based rule is not getting hit.
If ELS (Event Log Scraper) is being used to identify physical machine logins
1. The user might be authenticated by an AD instance whereby there is no local ELS server.
2. NSX is not configured with the ELS server that the user is reporting the event to, therefore, NSX has no visibility to those login events.

DFW rules

The ESXi host will automatically add with ext_src_ip addrset rextip fields to the DFW rule so long as:

There is at least one Active IDFW User Session, as shown under Security>Configuration
The user has been successfully mapped to an AD Group learned via LDAP.

As soon as the last active session matching the DFW rule is removed, the ESXi host will remove those fields from the DFW rule

Any or all of the below items can be considered as a potential resolution:

Ensure your LDAP sync is successful. If you have several configured, one successful sync should be enough, assuming the others are replicated in your AD domain. Any recent changes to AD Groups and/or Users will require a delta sync to bring the NSX tables up-to-date with those changes. By default, NSX performs an LDAP sync every 180 minutes.
Ensure you are syncing the correct OUs, especially if "All" is not selected. It is possible that the target AD Group is not inside your selected OU.
If you have recently made changes with the selection of OUs, the NSX Group that defines your AD Group will no longer apply due to internal changes in the UUID for user mapping. To remediate this, simply unselect, save, and re-select the AD Group again.

4. If none of the above help:
1. Run the following commands from the root shell and from any directory. The output will be saved in the directory you are currently in.
```
corfu_tool_runner.py -o showTable -n nsx -t DirectoryUser > DirectoryUser.txt
corfu_tool_runner.py -o showTable -n nsx -t DirectoryGroup > DirectoryGroup.txt
```
2. SCP the files to your desktop
3. Open a Support case and attach those two files