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 on LinkedinBal Birdy on Twitter
Bal Birdy
Bal is an Open Group Certified IT Architect, and VCDX #269, specializing in the network and security arena, with over 15 years experience in enterprise level network/system technologies. His goal has always been to maintain a holistic view of the architecture allowing him to understand how various technology streams may impact the networking/infrastructure space.
Bal has a proven record of delivering on enterprise network designs, leading data center and site migrations as a result of business mergers and acquisitions, and vendor migrations e.g. Cisco to Checkpoint/Juniper. As part of this he worked across several business sectors: Utilities, Banking, Retail and Government, and can base designs around sector specific standards e.g. PCI-DSS, DSD and ISM. He is proficient in several technology areas including Cisco, Juniper, F5, VMware, Citrix and Microsoft. These skills are supported by non-technical certifications: Prince2 Project Management Practitioner, ITILv3, TOGAF 9.1 Certified and Open Group Certified IT Architect – Open CA.
In addition to supporting the Livefire Team, Bal leads several innovation efforts within the VMware WRACE organization, including projects investigating the use of Virtual Reality/Augmented Reality, AI/ML and Interactive 360, to support customer and partner enablement.

Certifications:
BSc (Hons) Computer Science
CCNP/CCDP
VCDX-NV #269
Open Group Certificated Architect
Member of the Associated of Enterprise Architects

3 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

      1. Hello Bal
        So documentation states “Event log scraping enables IDFW for Physical devices”. So I wanted to clarify a windows workload (including physical) or virtual can be running not under NSX enabled host/cluster for IDFW and still have Identity enforced ??? Is that what this is implying? There is no documentation clarifying that aspect. Thank you.

Leave a Reply