Well, I've almost done everything already to configure the IDFW, but it didn't work, I did the following:
1- deployed GI to the cluster, and the status of GI is healthy, and there's a framework agent VM on each host.
2- added a Windows Server 2008 R2 domain.
3- added another W2KR12-R2 domain.
4- made sure that NSX can successfully sync and pull event logs from both domains.
5- created the security group with a Directory group.
6- installed a full VMware tools package.
7- created a firewall rule, and placed it in a "ID as a source" enabled FW section.
8- when I click on the "source" in that firewall rule, it could successfully query the account that is currently logging into the VM.
9- tried the VM with both domains.
No use, the rule never applies. I use vSphere 6.7 latest, NSX 6.4.4, and a guest Win7 32-bit VM.
in VMware docs, there's a command to test, but they didn't mention where should I run it, which is very mis-leading, the command is: GET https://NSX-IP-ADDR/1.0/identity/userIpMapping
Is the Win7 guest where the source user is logging in? Checking the "ID as source" option enables the IDFW for RDSH host functionality, which only works on Windows Server 2012 and 2016 per the Identity Firewall Tested and Supported Configurations section of the admin guide. If that's the case and/or your source VM is not an RDSH host, just de-selecting the "Enable user identity as source" box for the FW rule section or moving it to a different section without that enabled should fix.
Thanks for responding. Yeah I've already gone through the supported OS, but this is very confusing, as other articles discussed how useful is iDFW with VDI, and if you go to the very bottom of that page you will find a list of the "supported Guest Introspection OS", which includes WIndows 7.
I will try a RDSH with a Windows server,just to check that, but I;m not convinced.
I will get back to you.
To clarify, RDSH is not required for IDFW, however, when you select the "Enable User Identity at Source" option, the IDFW is expecting to need to translate users on the source to an AD group SID to map to their AD group rather than just observing the log on event and translating the user to an IP like you would in a normal VDI environment where there's only a single user logged into a VM.
Even if you uncheck the "Enable User Identity at Source" option you'll still be able to create IDFW policies based on AD groups which is definitely great in a VDI environment, it'll just cause the DFW to stop trying to map AD SIDs on the source host to the data plane instead of the associated IP.
Thanks for your support, but I'm still confused, and there's no clear documentation at all.
Anyway, I will try this again later.