Identity Firewall

With Identity Firewall (IDFW) features an NSX administrator can create Active Directory user-based distributed firewall (DFW) rules.

IDFW can be used for Virtual Desktops (VDI), Remote desktop sessions (RDSH support), and physical machines, enabling simultaneous log ins by multiple users, user application access based on requirements, and the ability to maintain independent user environments. VDI management systems control what users are granted access to the VDI virtual machines. NSX controls access to the destination servers from the source virtual machine (VM), which has IDFW enabled. With RDSH, administrators create security groups with different users in Active Directory (AD), and allow or deny those users access to an application server based on their role. For example, Human Resources and Engineering can connect to the same RDSH server, and have access to different applications from that server.

IDFW must know which desktop an Active Directory (AD) user logs onto in order to apply firewall rules. There are two methods IDFW uses for logon detection: Guest Introspection (GI) and/or event log scraping. Guest Introspection is deployed on ESXi clusters where IDFW virtual machines are running. When network events are generated by a user, a guest agent installed on the VM forwards the information through the Guest Introspection framework to the NSX Manager. The second option is the Active Directory event log scraper. Event log scraping enables IDFW for physical devices. Configure the Active Directory event log scraper in the NSX Manager to point at an instance of your Active Directory domain controller. NSX Manager will then pull events from the AD security event log.

Event log scraping can be used for virtual machines, however when both the AD log scraper and Guest Introspection are used, Guest Introspection will take precedence over event log scraping. Guest introspection is enabled through VMware Tools, and if you are using the complete VMware Tools installation and IDFW, guest introspection will take precedence over event log scraping.

IDFW can also be used on VMs that have supported operating systems. See Identity Firewall Supported Configurations.

IDFW processes the user identity at the source only in firewall rules. Only traffic originating at the source where the user identity is processed will be subject to IDFW rules. Identity-based groups cannot be used as the destination in firewall rules.

Note: IDFW relies on the security and integrity of the guest operating system. There are multiple methods for a malicious local administrator to spoof their identity to bypass firewall rules. User identity information is provided by the NSX Guest Introspection Thin Agent inside guest VMs. Security administrators must ensure that thin agent is installed and running in each guest VM. Logged-in users should not have the privilege to remove or stop the agent.

Identity based firewall rules are determined by membership in an Active Directory (AD) group membership. The OU with an AD user and the OU with the AD group that the user is in, must both be added into Organization Units To Sync for IDFW rules to work. For supported IDFW configurations and protocols see Identity Firewall Supported Configurations.

IDFW rules are not supported on Global Managers in a Federation environment. IDFW can still be used locally in Federated sites by creating IDFW rules on Local Managers.

IDFW Policy Groups and DFW Rule Match Logic

There can be two kinds of IDFW policy groups:

• Homogeneous groups with only AD groups as members of the policy group.
• Heterogeneous groups where there can be other members in addition to AD groups, such as virtual machines and IP addresses.

Security rules based on homogeneous identity groups apply the rule to all the NSX backed virtual machines where the AD user belonging to one of the AD group members logs in. With heterogeneous identity groups, the rationale is the ability to create more specific and precise sources for IDFW security policies rather than broadly applicable sources. A security rule where a heterogeneous identity group is used in the source will only be applied to the VMs which are part of the policy group (either statically or via a dynamic criteria or via IP address/range assignment) when an AD user belonging to the member AD group(s) logs in. The rule it is an intersection (AND operation) of VMs which are members of the group with the VMs where the target AD users log in.

A heterogeneous identity policy group's effective members can be found using the following logic:[Union set of all non-AD members] AND i.e. intersection with [Set of VMs where AD users belonging to the member AD group(s) log in].

Example 1 - Static VM members along with AD groups as members.

• Intent: When pairing a few VMs statically along with AD groups, the intent would be to apply the policy to the static VM members when an AD user belonging to the AD groups logs into them.
• Not applicable source examples: VMs where an AD user belonging to one of the member AD groups logs in but which are NOT static members of the policy group. VMs which are static members of the policy group but the logged user belongs to AD groups NOT members of the policy group.

Example 2 - Dynamic name based criteria for VMs along with AD groups as members.

• Intent: Apply a security policy ONLY to VMs whose name matches with the criteria when a specific AD user logs into them.
• Not applicable source examples: VMs where the AD user logs in but which are not matching the name criteria. VMs where name criteria matches, but the logged in user does not belong to one of the member AD groups.