NSX-T 3.2 IDFW With Event Log Scraping

If you are looking to set this up you’ll hear VMware say how NTP is important, though true, I’m also going to add CASE-SENSITIVITY to the list. After three days of banging my head as to why my IDFW Event Log Scraping setup wasn’t working helpful hint by a colleague at VMware led me to the answer. When configuring the NETBIOS definition in the Activity Direction definition, use capital letters !!

From a machine connected to the domain we can identify the netbios details by using the nbtstat -n command:

This translates to the following on the NSX Manager:

My mistake was typing the netbios name, CORP, in lowercase. Now everything came up green, NSX was learning my AD groups and my event log server definition was all green. So in principle we should be good, right? NO !!! Though all green, I was not learning details about the users logged in to my windows VMs. So back to the checklist:

  1. It’s a simulated environment, so make sure file and network introspection within VMware Tools is disabled
  2. Confirm NTP
  3. Confirm my event log reader account has access to the security event logs on my DC
  4. Check basic network connectivity
  5. Check my IDFW rule definition

All the above were good, but the last point is a bit confusing compared to guest introspection based IDFW, i.e. the traditional way of doing IDFW with VMTools. So let’s revisit that.

If you are doing log scraping you need to make sure you apply your firewall rules to the destination, and not the source (as is the case with GI IDFW). So in the above I have a rule that says “anyone who is part of the old_execs AD group is not allowed to access my website hosted on servers part of the WEB group”.

Source: AD group = old_execs Destination: WEB servers Service: HTTP/HTTPS Action: Drop AppliedTo: WEB SERVERS

In a GI IDFW rule the applied to would be associated with the VMs on which people logged in, i.e. the source, as GI IDFW rules are applied to the source. However with log scraping we don’t the source servers, so we apply the rule to the destination. So how is this realised on the dataplane? My website is running from a server called lb-01a, so after identifying the UUID for that endpoint, and the vsphere host it’s running on we can then look at the dataplane setup:

Firstly I’m logged in as an IT Admin:

The above screen shot can be found in the NSX Manager by going to Security > Overview > Configuration and right at the bottom you’ll find a section called IDFW User Sessions

I’ll be honest, this was new to me, I didn’t even know this existed in the UI, and is a brilliant for helping troubleshoot. Ok so now onto the dataplane.

If you look at ruleID 4074, I’m actually logged into my VM as an IT admin that HAS access to the server, but the concept is true for the drop rule, you can see an extended source and extended source_ip addresset. What this means is that source is a user part of an AD Group with a specific IP address, as we are using log scraping. So let’s look at that.

Based on the above we can now see the link between the workload, physical or VM (without VM tools). If you want to find out the AD group info you’d run the same command again, but replace addrsets with profile. Ultimately, what I’m trying to show is that once you get the NETBIOS piece defined correctly, how IDFW Event Log Scraping is realised. Hopefully it helps all the NSX Admins out there.

Keep an eye out for the new Livefire Virtual Cloud Networking offering, we’ll dig further into some of the cool new features of NSX-T, and I hope to see some of you in person again soon.

Bal Birdy

2 thoughts on “NSX-T 3.2 IDFW With Event Log Scraping”

  1. Dear Sir
    thank you share

    have you tried AD for win2012R2? is it work?
    I use AD win2016 is ok, but win2012R2 not work

Leave a Reply

%d bloggers like this: