Introduction

Typically, firewall rules are based on security groups that contain IP addresses, a subnet, or virtual machines. These security groups can be used as a source or destination in an NSX environment, but this doesn’t cover all use cases. Let’s take an example where an NSX admin has to allow/block access to specific applications to a given set of users, independent of the source address of the end-user. How do I implement rules, as the source address can vary for each user (local machine, VDI, terminal server). That’s where NSX Identity Based Firewall (IDFW) helps you. 

NSX IDFW allows you to create distributed firewall rules based on Active Directory users and groups. You can allow or deny access to applications based on user identity. IDFW requires integration with Active Directory so that the NSX can consume AD users and groups.

Use Cases for Identity Firewall

Identity Firewall can be used for Virtual Desktops or a Remote Desktop Session Host. But it’s not limited to just VDI & RDSH; physical machines are also supported. 

• VDI controls what applications users are granted access to when using VDI virtual machines. NSX controls access to the destination servers from the source VDI machines, which have 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. E.g., Support and Engineering can connect to the same RDSH server and have access to different applications from that server.

Another use case of IDFW is to allow/block certain URLs for a group of users. 

IDFW Logon Detection Methods

To enforce firewall rules, NSX IDFW must know which virtual desktop an AD user logs onto. There are two methods IDFW uses for logon detection:

• Active Directory Event Log Scraping
• Guest Introspection (GI)

The AD event log scraping enables IDFW for physical devices. This method is useful when the machine where users login is outside the NSX environment. In this method, when a user authenticates against AD, NSX reads the security event log for the user from the AD and, based on configured firewall rules, takes the appropriate action. I will talk more about this in my next post.

The second method is Guest Introspection. This method is useful for the scenario when the machine where users login is inside the NSX environment. This method relies on the VMware tools installed with network introspection enabled. When network events are generated by a user, the guest agent on the VM forwards the information through the Guest Introspection framework to the NSX Manager.

Identity Firewall Architecture & Components

The architecture of the Identity Firewall includes the following components:

• Active Directory: Provides users and groups for building IDFW rulesets.
• NSX-proxy: Receives configuration from NSX Manager and configures the data plane.
• VSIP: Enforces Identity Firewall rules on the datapath.
• Thin Agent: Collects login events, connection, and identity information from the Guest VM.
• Context Mux: Acts as a proxy for communication between the Guest VM and the ESXi host. Receives events from the Thin Agent and forwards them to the datapath.
• Context Engine: Forwards VM events to the VSIP module for rule enforcement.

Benefits of Identity-Aware Firewall

The main benefits of an identity-aware firewall are:

• Adds an additional layer of security to your network.
• Helps identify the source (user or device) of the traffic in the network.
• Provides visibility on users and devices that generate alerts, alarms, and cause security incidents.
• Enhances user experience by providing users with streamlined and smooth access to the appropriate resources without compromising network and application security.

And that’s it for this post. In the next post, I will discuss the IDFW Event Log Scraping method. Stay tuned!!!

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.