If you are new to NSX or looking to evaluate it in the lab, there is one very common issue that you may run into. After going through the initial steps of deploying and registering NSX Manager with vCenter, you may be surprised to find that there are no manageable NSX managers listed under ‘Networking and Security’ in the Web Client. Although the registration and Web Client plugin installation appears successful, there is often an extra step needed before you can manage things.
One of the first tasks involved in deploying NSX is to register NSX Manager with a vCenter Server. This is done for inventory management and synchronization purposes. The NSX Manager can be optionally registered with SSO as well.
The vCenter user that is used for registration needs to have the highest level of privileges for NSX to work correctly. The NSX install guide clearly states that this must be the vCenter ‘Administrator’ role.
From the NSX Install Guide:
“You must have a vCenter Server user account with the Administrator role to synchronize NSX Manager with the vCenter Server. If your vCenter password has non-ASCII characters, you must change it before synchronizing the NSX Manager with the vCenter Server.”
Because of these requirements, it’s quite common to use the SSO administrator account – usually administrator@vsphere.local. A service account is also often created for this purpose to more easily identify and distinguish NSX tasks. Either way, these are not normally accounts that you’d use for day-to-day administration in vSphere.
By default, NSX will only assign its ‘Enterprise Administrator’ role to the user account that was used to register it with vCenter Server. This means that by default, only that specific vCenter user will have access to the NSX manager from within the Web Client.
That said, if you are experiencing this problem, you are probably not logged in with the vCenter user that was used for registration purposes. To grant access to other users, you’ll need to log into the vSphere Web Client using the registration user account, and then add additional users and groups.
In my lab, I’ve just logged in with an active directory user called ‘test@lab.local’. This user has full administrator privileges in vCenter, but has no access to any NSX Managers:
If I log out, and log back in with the administrator@vsphere.local account that was used for vCenter registration, I can see the NSX managers that were registered.
In my lab, I’ve got a secondary deployed as well, but we’ll focus only on 172.16.10.40. If I click on that manager in the list, I’m able to go to the ‘Users’ tab to see what the default permissions look like:
As you can see, only one user – the SSO administrator account used for registration – has the requisite role for administrator via the Web Client. In my lab, I want to provide full access to an AD group called ‘VMware Admins’ and an individual user called ‘Test’.
Both vCenter users and groups can be specified here. As long as vCenter can authenticate them – either via SSO, local authentication or even AD – they are fair game.
Another common mistake made is selecting the NSX Administrator role rather than Enterprise Administrator. NSX Administrator sounds like the highest privilege level, but it’s actually Enterprise Administrator that gives you all the keys to the kingdom. You won’t be able to administer certain things – including user permissions – unless Enterprise Administrator is chosen.
Once this is done, you’ll see the users and groups listed and should now have the correct permissions to administer the NSX deployment!
Keep in mind that if you’ve got more than one NSX manager deployed, you’ll need to set this on each independently.
Have any questions or want more information? Please feel free to leave a comment below or reach out to me on Twitter (@vswitchzero)
vswitchzero 
Hey Mike, as a newbie to NSX, your blog has and will continue to be invaluable, so thank you!
I recently dropped 6.3.5 into the lab, but I had issues registering NSX Manager with vCenter using an AD service account. Is this supported?
I created the account in AD and have it full administrator role on the vCenter and propegated the permission. I then used administrator@vsphere.local for the PSC (SSO) registration component, but then used the AD account to register NSX Manager with VC. The registration was successful and the plugin appeared in the VC web client, but when logging in to VC with either the AD service account or administrator@vsphere.local, I was unable to see NSX Manager.
I redid the VC registration with administrator@vsphere.local and then things worked as expected.
Cheers, Matt.
Hi Matt,
Thanks for your comment! Using an AD based service account is definitely supported. We see this quite commonly in production deployments. The process you describe sounds right. Because the registration was successful and the plugin was installed the issue shouldn’t be a VC permissions problem. If the service account user didn’t have the correct VC permissions, registration would have failed.
I gave this a try in my 6.3.2 lab. I did the following:
– Created a new AD user called nsxservice@lab.local
– Added nsxservice@lab.local to the VC object as ‘Administrator’ role and propagated to all child objects.
– I then went the the NSX web UI and changed the VC registration to use nsxservice@lab.local. This was successful.
– I then logged into the vSphere Web Client using nsxservice@lab.local
– I could see the 172.16.10.40 NSX manager in the managers list.
– Looking at the users associated with this manager, I can see that the registration added nsxservice@lab.local as an ‘Enterprise Administrator’.
Based on the events you describe, I’d suspect that the service account may not have been added as an Enterprise Administrator user in NSX for some reason. After you re-registered with administrator@vsphere.local, did you happen to notice if the service account was listed under Users?
Hey Mike,
The process you outlined is exactly what I followed. I’ve just checked and the only users listed for the NSX Manager are administrator@vsphere.local and admin (NSX CLI User).
I’ll see if I can reproduce this sometime this week with the builds of NSX and vCenter I was using. I didn’t log it with GSS as it is just a home lab, but if I happen to be able to reproduce it I’ll let you know the details if you’re interested!
Cheers, Matt.
Hi Mike,
Just coming back to this one, I was setting up a new NSX deployment this week and I hit this issue again. What it was, was that I was only using the short account name in the vCenter Registration “vCenter User Name” field, rather than a username with username@UPN.
As soon as I changed the username to be the “full” username and re-registered, I logged in to the web client and could see NSX manager.
Interestingly the registration still succeeded when using the shorter account name.
Cheers, Matt.
Hi, thanx for this post.
One of the things we have found is that NSX Manager doesnt like nested AD groups.
Nested groups are also quite common in enterprise AD enviroments, using the AGDLP standard.
So our standard way of assigning rights would be:
the user –> member of a global group representing a user role –> member of a domain local group representing the resource –> the resource itself.
In this case the resource was the ‘auditor’ right in NSX manager.
We find that if we assign a user directly, it works
If we assign the user via an AD global group, it works
But when we nest it via a Domain Local Group, and then the Global group, then it doesnt work!
This is unfortunately common among a lot of applications and devices.
Oddly enough, PSC SSO understands this kind of nesting fine, so we have no problem at all with vCenter rights… only NSX Manager rights.