NSX Identity Firewall – A Case Study With the Flavour VDI

Intro

A customer of mine has the use case that his entire environment must be micro-segmented. Of course, this does not stop at the VDI environment. Since my customer uses non-persistent VDIs (the VMs are deleted after each logoff), no tags can be used for the security groups. After deleting the VM, the tag would also be removed and a new VDI would have no tags and would thus be isolated. This can be solved with automation or with the Identity Firewall (a combination of both solutions is also conceivable and makes sense). In the first step, my customer opted for the Identity Firewall because it allows generic VDIs to be used and authorisations to resources can be conveniently controlled via the customer AD. In addition, each user/user group receives individual firewall rules, which corresponds to the need-to-know principle.

You can use the Identity Firewall in 2 ways:

• Variant 1 would be with VMware Tools and Guest Introspection.
• Variant 2 would be with log scraping and, for example, Aria Operations for Logs as a log server.

I use variant 1 because the implementation means less effort in my customer setup and we only want to protect the VDIs with Idendity Firewall.

Limitations

• No User /Group ID Support for Federation.
• No direct integration with VDI and RDSH.
• User-ID based rules are supported for only firewall rules.
• No User-ID based policy for IDS/IPS and TLS Inspection.
• Multi-User (RDSH) does not support Server Message Block (SMP) protocol.

Supported protocols

• Single user (VDI, or Non-RDSH Server) use case support – TCP, UDP
• Multi-User (RDSH) use case support – TCP, UDP

Supported clients

• Windows 8,10,11
• Windows Server 2012 – 2022

What is needed?

• NSX in the VDI cluster
• AD infrastructure
• VMware tools
• VMware Aria Operations for Logs (optional)

First things first

Identity based groups can only be used as a source for a firewall rule. In addition, the rules only come into effect after a successful logon to the client. Thus, normal dFW rules must be written for all communication that happens before the user logs on. This applies, for example, to Windows AD communication. The NSX Manager synchronises cyclically with the domain controllers. The default interval is 180 minutes. If changes are made to the group membership at short notice, a manual sync can be performed. Alternatively, the sync interval can also be shortened or extended. Using network introspection, the NSX Manager recognises when a user logs on to a client and can perform matching with the AD groups and thus add the client dynamically to the security group of the IDFW firewall rule.

Getting started

Firstly, I start by customising the golden images of the VDI and installing NSX Guest Introspection. These are not installed by default and have to be installed explicitly. You can find them under VMware Device Driver – NSX Network Introspection. File Introspection is installed automatically.

Once Guestintrospection has been successfully installed, we no longer need to do anything on our Windows clients. Next, the domain must be integrated.

This is done in the NSX Manager under System -> Identity Firewall AD. Several domains can be entered so that multi-tenant setups can also be realised. The NSX Manager requires firewall activations and must be able to reach the domain controllers via LDAP or LDAPS. I strongly recommend the use of LDAPS. These settings can also be used to perform a manual sync or check the synchronisation status.

Under LDAP Server you can set several domain controllers for the previously set up domain. The protocol used is also selected here. I use the Domain Administrator in my lab. In a productive environment, an LDAP bind user should always be used.

Attention: If LDAPS is used, NSX imports the SHA thumbprint of the domain controller certificate. As the certificate is usually renewed automatically after 2 years at the latest, NSX loses the trust with the domain controller. In this case, the trust must be established manually. To do this, delete the thumbprint and reconnect to the bind user.  It has proven to be practical to monitor certificate expiry times and to enter at least 2 domain controllers that exchange their certificates with a 4-week time lag. If the trust fails completely, no more identity rules are applied and the default firewall rule comes into effect. In practice, this should be an any/any default drop and log rule.

After we have successfully setup and synchronised our domain, we only need to activate the Identity Firewall. By default, this feature is disabled (it is a free feature that is available with the NSX Firewall VCF add-on). To activate the Identity Firewall, go to Security -> Distributed Firewall -> Settings -> Identity Firewall Settings and activate the identity firewall service button. Then we select the cluster on which we want to activate the service.

Now we can get started.

Identity Firewall Rules

A general recommendation that applies to all firewalls is to think about a naming concept. At my customer, we have different name prefixes for the various security groups in NSX or in the other firewalls. For my part, I prefer the following naming convention, for example:

Distributed firewall groups start with dFW_XXX, an LDAP backed security group with dFWU_XXX (the U stands for user). For a group that contains an NSX segment it would be dFWS_XXX and for the gateway firewall a gWF_XXX and so on.

So we create our first LDAP user group. As with any group, we can do this either when creating the rules or in the inventory under Groups. The process is the same as for a normal Distributed Firewall Group, except that we don’t use tags but Distinguished Names, which can be conveniently selected or filtered from the synchronised AD elements.

I also need at least one segment group and at least one group containing my target servers. The target servers are assigned to their groups via tags. The same applies to the segment group. To do this, I set one or more tags on the overlay segment and use this tag as a condition for group membership.

Our goal will be that we authorise our users assigned to dFWU_UserGroup1 to access our fileserver with SMB and the users of the group dFWU_UserGroup2 must not receive any authorisation. I have two domain users in my lab, User1 is in the AD group assigned to dFWU_UserGroup1 and User2 is only assigned to dFWU_UserGroup2.

Creating the firewall rules

For each identity firewall rule that allows traffic from a group of users to a destination, there must be a corresponding distributed firewall rule that allows traffic from a group of computers to the same destination specified in the identity firewall rule. We therefore need two firewall rules.

The first rule is pretty straight forward, as source we have our dFWU_UserGroup1, the target is our dFG_Fileserver and the service is SMB. The Applied To Field is even more important than usual for the Identity Firewall. We may only apply this rule to our VDIs. Since my customer has different pools that are named according to a specific naming scheme, I can further restrict the scope based on the computer name. Each pool has different rules and we only want the rules to be realised on VMs where they are needed. The second rule is a bit more interesting. As a source, we have our VDI segment or segments. As in the first rule, the target is our file server. Logically, the service is also the same.

Attention: It is important that the Apply To field can only be on the file servers or on the target that we want to enable. If we were to use the dFG_VDI_GroupA or the dFGS_VDI group here, for example, then the entire Identity Firewall Rule is cancelled out!

Testing and verifying

The test is considered successful if User1 on the TestVDI can establish a successful SMB connection to the file server. If User2 is used instead of User1, the traffic to the file server must be blocked by the firewall.

For testing, I log in to my VDI with the credentials of User1 and perform a TestNetConnection with Powershell. This is a simple and quick way to test TCP connections. I also open a share on the file server.

The test was successful, both the TNC command and the actual opening of the file share worked. Now I’m running the same test on the same VDI (after it was recreated, because non-persistent VDI), only this time I’m using User2, which has no explicit firewall rules and is therefore blocked by my default cleanup rule. As expected, the traffic was successfully blocked.

Lessons learned

This is where I would like to add a few more thoughts on the subject. Troubleshooting is more difficult in practice than I thought. Tools such as NSX Traceflow cannot be used because you cannot add an AD user to the request. This means that the traffic in the traceflow is always dropped or the identity rule is maybe configured incorrectly.

But there is light at the end of the tunnel. In NSX 4.X there is a session view of the active IDFW user session under Security -> Security Overview -> Configuration. All active sessions, UserIDs and VMs are displayed here, as well as the source of the information.

Next tip would be to always check the sync status with the AD. Ask your AD admin when the user was added to the group. If the user has several accounts, ask for the user name used. Experience has shown that this is where most problems occur.

Use a syslog server and check exactly with which rule ID the traffic was discarded. Have all deny rules logged. 

Not all rules can be implemented as Identity Firewall Rules. The Windows domain basic communication can only be enabled via a classic set of rules, as no Identity Firewall rules are active for the VM without an active user session.

Important things to know

Never install Guest Introspection on a target. If a user has remote desktop permissions on the target and guest introspection is active there, then the target receives all of the user’s firewall rules. This can lead to unwanted firewall permissions.

If targets outside of NSX are addressed, such as a NAS or legacy infrastructure, a second rule is not required (unless the gateway firewall is also used). In this case, the distributed firewall will only check the traffic at the source VM.

Any change on a domain, including a domain name change, will trigger a full sync with Active Directory. Because a full sync can take a long time, i recommend syncing during off-peak or non-business hours.

MutiUser setups only work with RDSH (Remote Desktop Session Hosts) which requires a special configuration. Otherwise, if several users are logged on to a client at the same time, this leads to unwanted behavior and, in the worst case, to unwanted firewall permissions.

Conclusion

The Identity Firewall is a wonderful extension of the Distributed firewall and should be treated as such. Used correctly, it provides a very nice way to manage and delegate firewall permissions dynamically and centrally for individual users or user groups. It enables generic VDIs that can be used for different purposes depending on the user. This can reduce the number of VDI pools required, which in turn makes it easier to manage the customers VDI environment. The RBAC concept is even more tightly bound to the firewall policies and AD tiering can also be enforced via the firewall. And best of all, this great feature is included in the NSX Firewall license. I would recommend every NSX firewall administrator to take a closer look at the Identity Firewall.

Additional resources

https://docs.vmware.com/en/VMware-NSX/4.1/administration/GUID-9CD3FC21-9ED4-4FB3-9E19-67A7C4D1F53E.html