As one of the network and security leads for the VMware TAM program in North America, I was contacted by a colleague whose customer wanted to discuss NSX permissions and rights in detail. The questions from this customer inspired this post.
In this post, we’ll cover some of the major considerations for those who are configuring Role-Based Access Control (RBAC) in a VMware NSX for vSphere environment.
We’ll start with some basics that are covered in the NSX Administration Guide 6.2, which can be found here. (But, blogs are always better than dry documentation, aren’t they?)
Additionally, I’ll cover a couple of points not addressed in the documentation. Hopefully, this will save a couple of hours for someone who is assigning permissions to NSX for vSphere components and struggling to make the solution work as expected.
NSX for vSphere offers four roles:
- Enterprise administrator – This user can do everything related to NSX for vSphere.
- Security administrator – Firewall and data security rules can be defined and checked by this user.
- NSX administrator – This person can do different network-related operations, but not security-based actions.
- Auditor – This user can see what other users have done, but can’t make any configuration changes.
If your organization requires more granular access than these four roles offer, consider using third-party tools provided by VMware partners (currently HyTrust and CA) and certified by VMware.
The most important requirement for getting groups and AD accounts recognized correctly by VMware NSX Manager is to configure Lookup Service. Here is an example of parameters that are entered during Lookup Service integration with VMware vCenter Service.
After successful configuration, you will see the following “green” screen inside of the NSX Manager interface. Please use the firstname.lastname@example.org account and specify the complete name, not just “administrator.”
Additionally, you can use AD Groups and/or vsphere.local groups. Please note that a vSphere.local group can include multiple accounts from different sources (the group shown below contains local and AD domain accounts).
Next, you need to add the groups you just created to the users list, so NSX Manager knows which users are authorized to perform operations in NSX Manager. When you add a group, there are no validations done, so (a) be careful when spelling the group name, and (b) include the domain name in front of the group, as shown below. You can find more details about this in the NSX documentation.
Additionally, make sure that the group has appropriate permissions on vCenter and data center levels so that the users have the ability to browse through vCenter objects. It seems that it’s possible to use vCenter permissions to restrict the network department of your organization from accessing any vSphere objects. Unfortunately, I haven’t heard back from Engineering about whether this is a supported configuration or not, and therefore will not provide it here.
Here are two more precautions:
- When logged into the VMware vSphere Web Client interface, you should always use “user@domain”
format. It’s the proper way to login, instead of “domain\user” format. Even if you’re able to log in
with the latter, NSX Manager may not be able to validate the “domain\user” format properly.
- There is a known issue with the local OS user account; its resolution is explained in the
Knowledge Base article “When logged in to vSphere Web Client with a local OS user account, no
NSX Managers are available (2134416).”
As always, we recommend you get more experience with NSX for vSphere by using FREE VMware Hands-on Labs. Start with “HOL-SDC-1603 VMware NSX Introduction” and continue with “HOL-SDC-1625 VMware NSX Advanced” and then search for more using “NSX” as a search parameter.
Petr joined VMware in 2012 as a Senior Technical Account Manager based in Vancouver, British Columbia, Canada. Since then, he has worked with many customers and diverse industries in three cities on two continents. Petr is recognized as a vExpert 2016, holds multiple industry certifications including VMware VCAP/VCIX, Cisco CCNP, ISC2 CISSP and ITIL. He is a very enthusiastic supporter of Network Virtualization, and uses every chance he gets to discuss with customers a specialized offering called NSX TAM. Petr’s 20+ year technical background helps him to understand customer’s business needs and to find the right technical solution to address those requirements. Connect with him on LinkedIn and follow him on Twitter.