Browse Author

Erik Hinderer

With a new year comes new goals and a new role

I’ve got big news and it’s just too much for a 280 character Tweet.

With a new year, comes new goals and a new role as I start into the next decade.

I spent the fair majority of 2019 collaborating in presales support for account teams, given the amount of new technologies in the SDN space at VMware and how they aligned with my technical pursuits. I took a real liking to assisting in client solutions design and helping to unify an overall technical vision for enterprises with multiple organizations. Working hand in hand with those account teams provided me with some of the best experiences that I’ve had in my career and from that, I guess you could say, that I developed a desire to be an actual part of it.

So, over the next days and weeks, I’ll be transitioning into my new role as a VMware NSX Network and Security, Solutions Engineer for the US Globals team. The opportunity to work with VMware’s largest clients towards their current and future SDN visions is an amazing chance to participate in some of the most complex and challenging designs being built today, so I dove at it.

I’m very excited to join such an amazing group of individuals and a team with a reputation as some of the best. It’s been extremely difficult to be quiet about this, with how excited I am to take on this challenge and now that I get to write about it, there’s an overwhelming sense of gratitude to those who believe in me and to the many people whom I’ve worked with in and via the VMware TAM and NSX TAM teams over the years.

Since I have the character space to do so, I want to thank some people directly who have been instrumental in helping me get to where I am.

First and foremost, I want to thank my wife for being the independent, brilliant and dynamic woman that she is. Without her, I would be nowhere.

My son Jonas and daughter Sofia who many of you have heard, seen or met via my various social posts are the driving force behind it all and truly make me be the best that I can be. They’ll never know how thankful I am.

To my VMware TAM coworkers, previous and current, thank you all for being amazing human beings. This culture of talented and compassionate people was created and is kept alive by all of your efforts, which I’m very proud to have been a part of.

To the the #vCommunity at large, thank you all. There are way too many to thank and I’m not bragging about my follower stats. Know that I love you all and that our community is a very special place, full of very special people. Yes… All kinds of special. /me grins

Lastly, thank you to VMware for being the kind of company that promotes an environment of career growth, in which I can find and use new passions to grow.

After a few days of thinking about how I reached out and how naturally they reached back, it’s given me a nonstop smile. And as the sun sets slowly in the west, I sit here thinking about how lucky I am to be in a place like this, at a time like this.

#runNSX

VMware NSX-T 2.4.1 Upgrade Live Demo

VMware NSX-T was recently announced just a bit ago, so I thought it would be helpful to do a live demo of an upgrade to 2.4.1. In short, there’s good news that all but a few of the upgrades I’ve seen have been successful on the initial attempt thanks to the Pre-Upgrade / Post-Upgrade Checks that are built into each section, but any that weren’t successful on the initial upgrade were due to hitting timeouts waiting for a manager node to respond post upgrade (due to really old, under-performing hardware), which were easily remedied with a check of the error and then retry the Manager Node upgrade.

The 2.4.1 update is a core maintenance release, with a new enhancement for VMware HCX, adding functionality for virtual machine migration to on-premises NSX-T based deployments. I have a client doing this at the moment and can attest that it’s greatly welcome functionality for companies acquiring other companies with overlapping networks. VMware HCX provides capabilities to migrate from disparate versions as well, so migrating workloads from an acquired company with many different ESXi versions, is a real plus.

To begin the upgrade of NSX-T 2.4.1, we download the .mub upgrade file from my.vmware.com and log into NSX manager. Once we’re logged into NSX manager, we navigate to System on the top toolbar and then Upgrades on the left navigation pane. In the Upgrade window, choose the location of the NSX .mub upgrade bundle from local disk or URL. After we’ve chosen our upgrade bundle, we click upgrade and the upgrade bundle is validated by NSX Manager and then staged for upgrades. Once the upload status changes to Upgrade Bundle retrieved successfully, we click Begin Upgrade and the VMware NSX Upgrade Coordinator starts.

There are five steps in the upgrade, separated by a clickable top toolbar. Bundle and Status – Hosts – Edges – Controller Nodes – Management Nodes. After accepting the End User Agreement, we run the Host Upgrade on our compute workload clusters that have NSX installed and then we click on Run Post Checks to ensure they’re operable. Edge upgrades are next with the same process as well as Controller Nodes.

The final step in the NSX-T 2.4.1 upgrade process is Management Nodes, which have an option to return the NSX management cluster into service after a single or a 3-node cluster is formed. As a bit of guidance, it’s always a good idea to wait for the 3-node cluster to be operational before a return to service. However, if you’ve got a short outage window or allowance, you can return to service with a single NSX manager node, but be advised, performance usage will increase greatly as other NSX manager nodes rejoin the cluster and sync.

Check out my YouTube video of the VMware NSX-T 2.4.1 Upgrade for a preview of what to expect:

VMware NSX-v Identity Firewall Configuration Overview and How-To Create Active Directory User Access Rules for Applications (with or without NSX networking deployed)

One of the quickest and easiest returns on investment in the VMware product stack is VMware NSX Identity Firewall. What other product, with an hour of configuration and initial policy creation, returns such business outcomes? I’d hesitate to say there’s any such solution out there that can provide such an immediate return on investment. VMware NSX IDFW provides an incredibly valuable and easy to use solution for VDI and data center “jumpboxes” alike. With that said, I’m going to demonstrate how you can deploy and configure VMware NSX Identity Firewall in under an hour and have an identity-based security solution that can be easily inserted into any existing vSphere environment. …with or without deploying VMware NSX networking.

There are two methods IDFW uses for logon detection: Guest Introspection and/or the Active Directory Event Log Scraper. 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. 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. You can use both in your environment, or one or the other. Note that if both the AD event log scraper and Guest Introspection are used, the two are mutually exclusive: if one of these stops working, the other does not begin to work as a back up.

Before we get started, let’s talk reality. While security postures such as Micro-segmentation and Zero-Trust may indeed be your desired end-state, they’re a much longer journey than Macro-segmentation or Application Fencing. With that said, you can imagine how quickly you could create Application Fencing security policies for application servers or groups in your environment and start by simply controlling user access to them. Now, with the understanding that you can accelerate your NSX Identity Firewall implementation by leveraging macro-segmentation strategies in the initial phase, you’ll quickly realize that it will allow you to create more granular micro-segmentation policies in a secondary phase.

My lab scenario will demonstrate how NSX-v Identity Firewall can quickly secure an HR, Finance and CRM application, based on the users Active Directory group. The data center consists of three clusters, one for management and two for compute resources. RegionA01-COMP02 serves the hr-web-01a, fin-web-01a and web-04a VMs that serve each HR, Finance and CRM application respectively. The web VMs are running on a stereotypical “server VLAN”, on one subnet, as commonly seen in many enterprise environments. The jumpbox or VDI desktop, win-12-jump VM, is on a “user VLAN”, in another subnet.

NSX Identity Firewall configuration requires that NSX Manager be deployed and registered with vCenter. The NSX Manager appliance is deployed from OVA via vCenter and takes about 30 minutes to complete deployment and registration to vCenter. For details on installing NSX Manager, read Install the NSX Manager Virtual Appliance.

Requirements for VMware NSX Identity Firewall are:

  • NSX Manager 6.2 or greater (the latest release is recommended)
  • VMware Virtual Distributed Switch or NSX N-VDS
  • FQDN for NSX Manager
  • NTP configured in NSX Manager to the same source as vCenter, vSphere hosts and Active Directory domain controllers
  • AD account to query the domain (this user must be able to access the entire directory tree structure)
  • AD read-only account with permissions to read Windows Event Log locally or via Group Policy (see MS KB)

**In NSX-v, controllers and networking components are not required

After NSX Manager has been deployed and registered to vCenter, we begin configuring IDFW Event Log Scraping by setting the LDAP and CIFs properties for directory queries and event log reading. After setting the LDAP and CIFS properties, we validate that the directory has performed a sync and that the AD event servers have populated in the Event Server fields. Guest Introspection is also deployed, to explain that configuration.

This demonstration video that I created, will guide you step-by-step through the process of configuring VMware NSX Manager to enable Identity Firewall:

Some simple best-practices for leveraging Microsoft Active Directory user groups are:

  • Create new user-groups in a top level OU when possible and then nest existing groups which may be deeper in the forest.
  • Limit the nesting of Active Directory user groups to three(3) deep for best performance.
  • When leveraging a large enterprise forest, configure the LDAP and CIFs properties for directory queries to a smaller child domain that the user groups are in, instead of the top level forest domain.

Once you’ve finished with the installation and configuration of VMware NSX-v Identity Firewall, it’s time to map Active Directory user groups to NSX security groups and create security objects for enforcement. There are static and dynamic objects that can be leveraged. Dynamic objects yield a more simplified security policy, reducing the number of overall rules and security objects needed. Thus, dynamic object types should be used whenever possible. Static NSX object types are IP Sets, vNICs and Virtual Machine names, where as dynamic security object types contain a set of resources grouped by another construct, such as a vCenter Cluster or Datacenter, Distributed Port Group, Legacy Port Group, Logical Switch, Resource Pool or vApp.

The Object Types for an NSX-v firewall rule are: Security Group, IP Sets, Cluster, Datacenter, Distributed Port Group, Legacy Port Group, Logical Switch, Resource Pool, Virtual Machine, vApp and vNIC. With such a wide array of selection criteria, there are many object types that can be leveraged to create a strategic advantage in your security policy.

 

Now that we’ve configured NSX Identity Firewall, mapped Active Directory user groups to NSX security groups, we’ll create some Active Directory based rules to test access to our applications.

If you want to test blocking without changing the default Layer 3 rule, simply create a rule blocking what you need in a user defined firewall rule section above the rule you want to test. We’ll use this in in the live demo with a firewall rule called VDI to APP that blocks the VDI desktop network, leveraging an IP SET from the Internal Services security group that contains our protected web app servers. See the image below.

Now, let’s login as both users and test the access of the NetAdmin and HRAdmin users to see if they have the appropriate access.

Hope you enjoyed this post and feel free to hit me up on Twitter, LinkedIn and subscribe to my YouTube Channel with any requests for content that you’d like to see. Until next time, as the sun sets slowly in the west, I bid you a fond farewell. Adios amigos!