Integrating NSX with Active Directory and creating Identify-Based Firewall Rules

NSX has the ability to integrate with Active Directory and allow you to create security groups based on user identity, create identity-based firewall rules, and run Activity Monitoring reports.  In this post I'm going to show you how you can integrate NSX with Active Directory and then create a security group within NSX that only allows users to SSH into all Linux VM's that are in the Allow SSH Active Directory Security group.  First step is to configure NSX to query Active Directory for user / group information as well as query the security logs to map usernames to IP addresses.  Browse to the NSX Manager plugin, select your NSX Manager and click on the Domains tab:

Click on the green plus icon to add a new domain.  Specify the name of the domain and the NetBios name and click Next:

Specify your domain controller name and a username and password that can query LDAP information and click Next:

Specify the username and password for an account that has access to view the event logs and click Next (for testing purposes I'm using a domain admin account):

Finally verify your settings are correct and click Finish:

NSX should now start pulling in user and group information from Active Directory and also monitoring the security logs for logon / logoff events.  It may take a few minutes for the refresh to take place, take this time to grab a coffee and a few biscuits:

Now I'm going to create a few user account and security groups within AD for testing purposes.  The security groups and user accounts are called:

Allow SSH - SG - D (Domain Local Security Group)

Allow SSH - SG - G (Global Security Group)

Allow_SSH_User

No_SSH_User

The Allow SSH - SG - G is going to be a member of the Allow SSH - SG - D as I like to follow best practises for multi-domain environments.  The Allow_SSH_User is going to be a member of Allow SSH - SG - G which means he is also going to be a member of Allow SSH - SG - D.  I will then add the Allow SSH - SG - D to a security group object within NSX which I can then add to a firewall rule but we will cover that off later.  The No_SSH_User will not be a member of any groups.  Once everything is in place the idea is that when I log into a domain member workstation as Allow_SSH_User I should be able to SSH into my linux VM's, when I log in as No_SSH_User I should NOT be able to SSH into my linux VM's.

Here are my security groups and user accounts:

It's best to quickly update the Active Directory objects within NSX by going back to the Domains tab and clicking on the double cog icon and verifying the update has occurred by checking the last sync status:

Now we need to create the security group within NSX that will point to the Active Directory group called Allow SSH - SG - D (Which contains Allow SSH - SG - G and thus the Allow_SSH_User).  Within the NSX Manager configuration screen select the Grouping Objects tab.  I already have some groups that dynamically adds VM's to specific groups.  Click on the green plus arrow to create a new group:

Give the new group a name and click Next:

Remove the dynamic membership criteria as we will be statically assigning the resource and click Next:

Change the object type to Directory Group and select the group you require and click Next.  In my case its Allow SSH - SG - D:

We don't want to exclude any resources so just click Next

Finally verify everything is correct and click Finish:

We can now see the newly created NSX group:

Finally we need to edit the ruleset to only allow the Allow SSH NSX security group permission to SSH to the Linux VM's.  My current ruleset allows anything to SSH into the Linux VM's:

If you hover over the source field a plus icon will appear.  Click it and then change the Object Type to Security Group (Remember these are NSX Security groups) and click the arrow to move it across to the Selected Objects box and click OK:

Publish the changes and the ruleset is now active:

Time for testing.  I logged into my jumpbox workstation as Allow_SSH_User and successfully opened a putty session to WEB01:

I then logged in as No_SSH_User and was unable to connect to WEB01:

How impressive is that.  Stay tuned for the next thrilling installment

Configuring Spoofguard in NSX

NSX includes Spoofguard which allows you to authorise IP addresses reported by VMware tools running inside a virtual machine.  You can configure multiple policies for a different networks (Logical Switches and Distributed Port Groups) depending on your requirements.  If Spoofguard is enabled you will not be able to communicate with a VM until the IP address has been approved (Either automatically or manually)

Spoofguard is configured via the NSX plugin in the vSphere Web Client and by default it's disabled so traffic to all VM's is allowed.  You can see a list of active vNIC's and which IP addresses (IPv4 and IPv6) are associated with those VM's:

In order to enable Spoofguard across all networks simply edit the Default Policy and check the Enabled option.  You then have two options to either automatically trust IP assignments on their first use which basically will automatically approve the first IP address of the VM.  You also have the option to manually inspect and approve all IP assignments before use which basically means that you have to approve all IP addresses before you can establish connectivity with them.  In this example I'm going to manually approve all IP address assignments.  Once finished click Finish:

Don't forget to Publish Changes:

Once configured you should loose connectivity to all VM's.  I've sent a continuous ping to my test WEB01 VM (192.168.0.11) and as you can see, once spoofguard was enabled it stopped responding to pings:

We can also see that Active Virtual NICs view is empty:

If we change the view to Virtual NICs IP Required Approval we can see a list of all NICs that we need to approve.  If we configured the default policy with the automatically trust IP assignments on their first use then these would have been pre-approved but subsequent IP changes would require manual intervention:

Once I approve the WEB01 IP address and Publish the changes connectivity is restored:

If the IP address were to change then VMware tool would detect this and you would have to approve the new IP address.  In this example I changed the IP address of the VM from 192.168.0.11 to 192.168.0.19:

If you only wanted Spoofguard enabled on a particular Logical Switch or Distributed Port Group such as a DMZ then you can set the default policy to disabled which will trust all IP addresses.  You can then enable Spoofguard for a particular network which requires approval of all IP address changes.  To create a new policy simply click the green plus icon and give the new policy a name and set the required policy.  In this example I want Spoofguard on the DB network to be enabled and all IP address changes manually approved.  Click Next when ready:

Finally click the green plus icon and add the required Distributed Port Group or Logical Switch that you want to enable Spoofguard for.  You can add multiple networks to same policy if you wish.  Once finished click Finish and don't forget to Publish the changes:

We can now see the new policy and all the VM's that require their IP address approved before you can communicate with them:

Hope this helps with understanding Spoofguard a little more and how to configure it within NSX

Configuring DHCP Relay in NSX

One of the new features with NSX 6.1 is the ability to configure DHCP Relay on a Distributed Logical Router.  Before NSX 6.1 in order to use DHCP you had to have a DHCP server directly attached to each subnet.  Chris Wahl (Blog | Twitter) has a great article about all the new NSX 6.1 features.  To configure DHCP relay you must be running NSX 6.1 and ensure that all your Distributed Logical Routers are running at least version 6.1.  The first thing you need to do is ensure that you have the required scope with options configured on your DHCP server.  In my example I have an APP01 VM on the 192.168.1.0/24 network that is currently assigned a static IP address of 192.168.1.11 which I'm going to configure to use DHCP.  I've already configured the required DHCP scope as per below:

In order to configure DHCP Relay simply browse to the Distributed Logical Router that is connected to the network that you want to enable DHCP Relay for and browse to the DHCP Relay tab:

Click the Edit option and enter the IP address of the DHCP server that you want to forward DHCP request packets to and click OK:

In the DHCP Relay Agents section click the green plus icon and select the network that you want to relay DHCP request packets for and click OK.  In my example I'm using the Tenant-01-App-Tier:

Verify all details are correct and click Publish Changes:

Ensure the VM on the network is configured for DHCP, renew the lease and then check the DHCP server to ensure that a lease has been give out:

DHCP Relay has now been configured on the 192.168.1.0/24 network.