In this post, we’ll dive into the world of users and groups as they pertain to NSX Manager permissions. Anyone who will need to view or configure items within NSX Manager will need to have permissions granted by way of various NSX roles. We’ll also reconfigure the lab to use a proper service account. 🙂

vCenter Server with Service Account

In my previous post, I deployed and configured the NSX Manager using my own account ([email protected]) to connect to the vCenter Server. In reality, this is highly unlikely to occur and is not a great choice anyway. It’s typically a better idea to use a service account that has a complex password that is either vaulted or changes as part of some known cycle. End user accounts have a way of accidentally locking themselves or changing randomly. 🙂

Let’s configure NSX Manager to use a new service account. I use a specific svc_<role> format in the lab, so this will be [email protected]. Below is the NSX Manager admin page where the vCenter Server credentials can be changed.

There, that’s much better. The [email protected] service account will now be used by NSX Manager to talk to vCenter.

Make sure to include the account’s domain name in the @domain.name format, such as [email protected] for my lab. Otherwise, the integration between vCenter and NSX will likely fail.

Verifying NSX Users and Groups

Much like with Single Sign-On (SSO) for vCenter, the default installation of NSX will have granted access to very few users. To remedy this, log in to the vSphere Web Client as the service account used for the NSX-to-vCenter integration and navigate to the NSX Manager configuration within the Networking & Security section as shown below:

Access the NSX Manager properties to modify users and groups

Once you have clicked on the NSX Manager, which is simply “10.0.0.41” in my environment, find the Manage tab and the Users sub-tab. In my lab, I noticed that only a few users had access: the root and admin users, my [email protected] SSO 5.5 account, and my [email protected] domain account.

Note: I assume this might vary depending on your vCenter version, if you upgraded to 5.5 from 5.1 or not, and if you are using the Lookup Service from vCenter Server.

See the configuration for my lab below:

Unfortunately, this means that my admin account – [email protected] – won’t be able to do anything with NSX when logged on. That user account has no authority within NSX, even though it is a full Administrator in vCenter. The two authority domains do not overlap. See below:

This is easily fixed.

Granting User Permissions to NSX

From the Users sub-tab within your NSX Manager, click the green plus sign to add a new user. I’ll go ahead and add myself to the list of users authorized to work with NSX as shown below:

Next, I’ll need to pick a role. There are four roles available:

Auditor – Users in this role can only view system settings and auditing, events and reporting information and will not be able to make any configuration change.
Security Administrator – Users in this role can configure security compliance policies in addition to viewing the reporting and auditing information in the system.
NSX Administrator – Users in this role can perform all tasks related to deployment and administration of this NSX Manager instance.
Enterprise Administrator – Users in this role can perform all tasks related to deployment and configuration of NSX products and administration of this NSX Manager instance.

If that’s clear as mud, here’s the official documentation. Essentially, Enterprise Admin = NSX Admin + Security Admin.

Because I trust myself, I’ll choose to give myself Enterprise Administrator. Eerie, eh? 🙂

Note: I could have also granted access to a group instead of a user, but I rarely like to do that. It’s easier to audit specific users, and it also means that no one can accidentally give someone authority by way of an AD group slip up. The choice is yours.

To verify that the new role is working, I just have to refresh the browser where the Chris user is logged on. Viola, the NSX Manager shows up!

I can now add any other users or groups that might need access, especially if I need folks within my organization to audit the environment. The next section focuses on Deploying NSX Controllers via GUI and API.