VMware Networking Community
govplacelara
Contributor
Contributor
‎02-03-2016 05:42 AM

NSX Active directory sync not working as expected (ver 6.1 and 6.2.1) - VDI microsegmentation

Interesting issue that I noticed today with AD sync (full and partial) in relationship to User based security policy:  When an AD group is created I would expect to have to do a full AD sync (if I wanted to force the update instead of waiting) in order for the group to  "populate" into NSX manager.  One would also assume that if a user is consequently removed from the group that I would need to do a partial sync to remove the user from the group thereby removing the security policy from that user but "leaving" the group and (at the time) current members in NSX manager.

However what seems to be occurring is:

  1. a user group is created in AD
  2. NSX FW policy is applied to group (in this case SSH access in and out)
  3. user tests and FW policy works as expected, logs off
  4. AD admin removes user from group (and verify across AD that user is not member of group)
  5. user logs back in, tests and FW policy is still applied, logs out (to be expected as no sync action has occur nor has 3 hours past)
  6. NSX Admin does a partial sync
  7. user logs back in, tests and FW policy is still applied, logs out
  8. NSX admin does a full sync
  9. user logs back in, tests and FW policy is now not applied, logs out

Has anyone else seen this behavior, and if so what was the remediation?  Or am I understanding the AD sync process wrong?

Reply
5 Replies
bsalek
VMware Employee
VMware Employee
‎02-03-2016 07:13 AM

Hey Rob! How are you?

Let me see if I can track this down for you. I've never actually paid attention to the sync response. In my little lab environments, I always just click full Smiley Happy

Reply
govplacelara
Contributor
Contributor
‎02-03-2016 08:58 AM

Hey Bryan!!!

To add further "color": we had to manually force the domain into NSX (using API to enter the domain in to NSX, then populating the user account, Base DN, etc.) because the user account was only allowed to query AD, not perform security log pulls.  Since the user account was not able to do the log scrapes we could not use the GUI to create the domain, it would error out on the Security Event setup....

FYI to the coders out there: unless it is really needed (and would be nice to have a document on why) we should be able to create the domain with accounts that do not have Security log access...

Thanks for looking!!!

Reply
0 Kudos
larsonm
VMware Employee
VMware Employee
‎02-03-2016 09:28 AM

Just a couple quick notes on Event Log access: 

"Adding more than one Windows server (Domain Controllers, Exchange servers, or File Servers) as an event log server improves the user identity association."

p256 of the NSX 6.2 admin guide.

This configuration allow the NSX Manager read Active Directory “Security Event Log” this logs contain Active Directory users logon/logoff from to domain.  NSX used this information to improve user identity firewall rules.

http://www.routetocloud.com/2014/10/nsx-role-based-access-control/

Reply
0 Kudos
govplacelara
Contributor
Contributor
‎02-03-2016 09:47 AM

Larsonm,

Thanks for the links!!!  Have been reading those....

To refresh my memory: I was informed the the only reason for the security event logging was to catch devices and VM's that either do not have VMware tools installed (tools is used to capture log in and log out on VM's that its installed on).  Good example would be rulesets that are applied to devices not in the virtualized world.  Since they do not have tools installed some other method was needed to capture log in and log out, and security event logging provides that method.  Really doesn't apply to my use case as this is micro-segmentation of a VDI environment so all VM's in scope will have tools installed....

However whats at issue is that in this particular environment the security folks have "locked down" security event logging as they see it as a "risk" to let mere virtualization mortals parse their logs <comments meant to lighten the thread-they actually are pretty cool guys>.  So their push back was to require a lot of documentation about how their logs are parsed, where the data is stored etc etc (and I cant blame them for that). 

I'm actually surprised that the issue doesn't come up more often

Reply
0 Kudos
admin
Immortal
Immortal
‎03-18-2016 03:27 AM

I see something similar in 6.1.4 - but, I can never get it to Step(9) (removal of FW rules) despite full AD sync. In fact, I see the VM present in two sec-groups i.e sec-group of the deleted user & sec-group of the newly logged-in user. I believe this is fixed in 6.1.5/6.2.3 so, I'm confused when you report this behavior in 6.2.1.

I had a question:

When a user is removed from the AD server followed by a full AD sync we should see NSX-Manager flush the security-group translations (for the VM that has the deleted user logged-on) & ip-addrset on the host - this will ensure the VM vnic is now subject to the default FW rule-set. Is that a fair expectation? Why should the current design rely on an alternate user logging in on the same VM?

BTW, I'm presuming you use a different user from the deleted one in Steps (5),(7) & (9).

Reply
0 Kudos