We're currently busy implementing the Identity Firewall feature, so that we can allow access to certain subnets (like management subnets) based on your Active Directory group membership. Now, in theory this works fine. If you're part of "AD Group A", your desktop will become a member of NSX Security Group "AD - Group A", where only AD Group A is included. This Security Group is then used as the source for the distributed firewall rule that allows access to something. So far, so good. However, an administrator may occasionaly need to run an application within their desktop using "Run as administrator". Since NSX is constantly monitoring the Security Event Logs of all the configured domains, NSX will update your current IP address with a different user (expected behaviour perhaps, but not really what we want). All other defined rules now don't apply to the currently logged in user anymore, because NSX saw a different user and has overwritten the user-to-ip mapping.
Again, this is expected behaviour, however...
The user that's being used to login when using Run as administrator is part of a different AD group, which we then added to the same NSX Security Group. However, NSX doesn't "see" this relationship. This might be due to the fact that NSX simply doesn't support multiple logins on one IP address, and therefore it doesn't check if this new user is also part of an AD group that's specified in the same NSX Security Group. So this workaround doesn't work.
Naturally, I opened a Service Request with VMware and they pretty much told me that NSX doesn't support more than one user per IP. However, I refuse to believe that we are the only NSX customer that has run into this issue. I thought that perhaps the good people here at VMTN might have experienced the same issue and found a resolution (either through VMware Support or by using a different method).
If there is a way to trigger an IP change(Releasing and Renewing) when user permission change inside the guest that might do the trick .
That's pretty genius Sreec 😉 I like it!
However, should the IP address change, then this will also force all other opened applications to disconnect, so it won't be a workable solution I'm afraid. Also, I have no idea how we could implement such a workaround. When you renew your DHCP lease, naturally the DHCP server will let you keep your current IP address.
If I get the chance to test this (with some help from someone else, since I won't be able to do anything with the DHCP server), I will let you know the results.