One of the most challenging problems in managing large networks is the complexity of security administration.
“Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. Roles are defined according to job competency, authority, and responsibility within the enterprise”
Within NSX we have four built in roles, We can map User or Group to one of the NSX Role. but i think Instead of assigning roles to individual users the preferred way is to assigning role to group.
Organizations create user groups for proper user management. After integration with SSO, NSX Manager can get the details of groups to which a user belongs to.
Within NSX Manager we have four pre built RBAC roles cover different nsx permission and area in NSX environment.
The four NSX built in roles are: Auditor, Security Administrator, NSX administrator and Enterprise Administrator:
Configure the Lookup Service in NSX Manager
Whenever we want to assign role on NSX, we can assign role to SSO User or Group. When Lookup service is not configured then the group based role assignment would not work i.e the user from that group would not be able to login to NSX.
The reason is we cannot fetch any group information from the SSO server. The group based authentication provider is only available when Lookup service is configured. User login where the user is explicitly assigned role on NSX will not be affected. This means that the customer has to individually assign roles to the users and would not be able to take advantage of SSO groups.
For NSX, vCenter SSO server is one of the identity provider for authentication. For authentication on NSX, prerequisite is that the user / group has to be assigned role on NSX.
Note: NTP/DNS must configure on the NSX Manager for lookup service to work.
Note: The domain account must have AD read permission for all objects in the domain tree.
Configure Active Directory Groups
In this blog i will use Microsoft Active directory as user Identity source. in “Active Directory Users and Computers” i created four different groups. The groups will have the same name is the NSX roles to make life easier:
Auditor, Security Administrator, NSX Administrator, Enterprise Administrator.
We create four A/D users and Add each user to different A/D group. for example nsxadmin user:
the user nsxadmin is associate with the group NSX Administrator. the association done by the Add button:
Same way i will associate a others users to A/D groups:
auditor1 -> Auditor
secadmin -> Security Administrator
nsxadmin -> NSX Administrator
entadmin -> Enterprise Administrator
Connect Directory Domain to NSX Manager.
Go to “Network & Security” tab double click on the “NSX Manager”
Double click on “192.168.110.42” icon:
Note: Configure Domain is not needed for RBAC, only if we want to use identity firewall rules base of user or group.
Go to “Manage -> “Domains” -> Click on the green Plus button:
Fill Name and NetBIOS name fields with appropriate information of your Domain Name and NetBIOS name:
In My example my domain name is corp.local:
Enter LDAP (i.e AD) IP address or hostname and domain account (username and password):
Configuring LDAP option task can be done via direct API call to bypass the Event Log Access described in the next steps).
Click on next.
Event Log Access:
In case we need to create NSX firewall rule with user identity based on AD groups. We will need to allow the NSX Manager read Active Directory “Security Event Log”. This logs contain Active Directory users logon/logoff from to domain. We use this information to bind the AD user to an IP address.
NSX need access to “Event Log” provide dFW with user identity in one of the two case:
- The user logon to VM that doesn’t running VMtools.
- The user logon to the domain from PC located on physical environment.
BTW users login to to VM with VMtools up and running , we do not need the “Security Event Log” to bind the user to IP.
Permissions for the user to read logon/logoff events:
Windows 2008 or later domain servers:
Add the account to the Event Log Readers group. If you are using the on-device
User-ID agent, the account must also be a member of the Distributed COM Users Group.
Windows 2003 domain servers:
Assign Manage Auditing and
Security Logs permissions through group policy
In both of this cases NSX will need to access the AD with read permissions for security event logs, the protocol using to read this information are CIFS or WMI.
During this process NSX collecting the following microsoft event ID:
For windows 2008/2012 – Event ID: 4624
For Windows 2003 – Event ID: 540
NSX will “Copy” this Event access log and from A/D and parse the data inside the nsx manager appliance.
Click Next and Finish:
Mapping Active Directory Groups to NSX Managers Roles
Note: This step is must for NSX RBAC to work.
Now we can map Active Directory groups to pre-built NSX Manager roles.
Go to “Manage -> “Users” -> Click on the green Plus button:
Here we can select if we want to map specific A/D user to NSX Role or A/D Group to Role.
In this blog i will use A/D group, we create A/D group called auditor. The format to input here is:
“group_name”@domain.name. let’s start with auditor group, this group is “Read Only” permission:
Select one of the NSX Role, for Auditor A/D group we chose Auditor
We can limit the scope this group can work inside nsx manager object, for this example there is no limit:
Same way Map all others A/D groups to NSX Roles:
Auditor@corp.local – > Auditor
Security Administrator@corp.local -> Security Administrator
NSX Administrator@corp.local -> NSX Administrator
Enterprise Administrator@corp.local -> Enterprise Administrator
Try our first login with user Auditor1:
The login successfull but where is the “Network & Security” tab gone ?
So far we configure all NSX Manager part but we didnt take care of the vCenter Configuration permission for that group. are you confusing ?
vCenter has is own Role for each group. we need to configure roles to etch A/D group we configured. These settings determine what the user can make the in vCenter environment.
Configure vCenter Roles:
Let’s start by configure the Auditor Role for Auditor A/D group. we know this group is for “Read Only” in the NSX Manager, so it will make sense to give this group “Read Only” to all other vCenter environment.
Go to vCenter -> Manage -> Permissions and click the green button:
We need to choose Roles from the Assigned Role, if we select No-Access we will not be able login to vCenter. So we need to choose something from “Read-Only” to “Administrator”
For Auditor Role “Read Only” is the Minimum.
Select “Read Only” from the Assigned Role drop down list and click on the “Add” button from “User and Group”:
From the Domain Select your Domain name, in our lab the domain is “CORP”, choose your Active Directory group from the list (Auditor for this example) and click the “Add” button:
Click Ok and Ok for Next Step:
Same way we need to configure all other groups roles:
Now we can try to login with auditor1 user:
As we can see auditor1 is in “Read Only” role:
We can verify that auditor1 can’t change any other vCenter configuration:
Test secadmin user map to “NSX Security” role, this user cannot Change any NSX infrastructure related task like create new add new NSX Controller Node:
But secadmin can create new firewall rule:
When logging with nsxadmin user map to NSX Administrator Role we can see that the user can add new Controller Node:
But nsxadmin user cannot change or see any firewall rules configure :
What if the user member of two A/D Group ?
The user will gain combined permission access of both of the groups.
For example: the user memberof “Auditor” group and “NSX Security”, the results will be user will have read only permission on all nsx infrastructure and also gain access to all security related area in NSX.
In this post we demonstrate the NSX manager different roles. We configure Microsoft Active Directory as External database source for user’s identity.