introduction
In previous articles : we have seen how to join vCenter as server VCSA and vCenter application to Active Directory ,
This article we will discuss how to configure vCenter with domain users
vSphere RBAC Concepts
The most crucial part of securing a VMware vSphere environment is ensuring that only the proper users have access to VMware vSphere, and they are only able to complete the tasks they are allowed to do after they have logged into VMware vCenter.
This is where Role-Based Access Control comes into play.
vCenter authentication Default Settings
just to clarify the default settings of vCenter
as you know : we have VCSA as operating system which managed by local account called root
also we have vcenter as application which used to manage vShpere environment
during vCenter installation : setup create new domain for vcenter authentication called vSphere.local and the built-in account to manage these environment is administrator@vSphere.local
you are free to these account above administrator@vSphere.local to manage vSphere Environment ,
BUT ,,,
VMware give you ability to use Microsoft Active Directory authentication as second sources of identity
in previous article we have learned how to join VCSA to AD , and also learned how to use Microsoft Active Directory as second source of identity
grant domain users to access vcenter
open vcenter web client
https://VCSA161:443
windows session authentication
some users may asks : i am using my own computer ,
do I have to insert my AD credential every time when login to vcenter
the answer is : on login screen : there is feature called [ use windows session authentication ] which allow you to use your windows login credential to access vcenter
as seen below
RBAC recommendation
As Network Pioneers we recommend you consider The following when configuring RBAC vSphere Environment
- it highly recommended to assign permissions to AD groups, not user accounts.
- Do not use local accounts or groups.
- Grant permissions only where needed. Using the minimum number of permissions makes it easier to understand and manage the permissions structure
- Create new groups for vCenter Server and service provider users. Avoid using Windows built-in groups or other existing groups.
- Deny override allow : If you assign a restrictive role to a group, check that the group does not contain the Administrator user or other users with administrative privileges. Otherwise, you could unintentionally restrict administrators’ privileges in parts of the inventory hierarchy where you have assigned that group the restrictive role.
- Use caution when granting a permission at the root vCenter Server level. Users with permissions at the root level have access to global data on vCenter Server, such as roles, custom attributes, vCenter Server settings, and licenses. Changes to licenses and roles propagate to all vCenter Server systems in an Enhanced Linked Mode group, even if the user does not have permissions on all of the vCenter Server systems in the group.
- In most cases, enable propagation [inheritance ] on permissions.>> This guarantee that when new objects are inserted into the inventory hierarchy, they inherit permissions and are accessible to vsphere environment admins and users.
- Use the No Access role to mask specific areas of the hierarchy that you do not want particular vsphere environment administrators and users to have access to.
- Certain privileges can be harmful to hosts and should be assigned to vsphere environment s only when required. This includes any privilege that allows a user to delete, rename, remove, or create items that can cause data loss or datastores to be filled up. This can cause a denial of service attack on your VMs (for instance, prevent snapshot creation).
- Create roles that are customized to vsphere environment For example, to create a role for an operations team that is responsible for monitoring VMs, create one that allows VM interactions only (for instance, power on, power off, reset, and console interaction). This allows team members to look at the console of a VM to see what is happening and power-cycle a VM.
- Assign the datastore low-level file operations privilege sparingly. This privilege allows users to upload and download files to a host datastore and can create a security risk.
- Other potentially dangerous privileges are in the network and distributed virtual switch categories, which can allow a user to move a VM to any available virtual LAN that is configured on your virtual switches. This can be particularly risky if you have public and private network virtual switches on a host where you definitely do not want a VM moved between them or connected to both at the same time. Assigning the network privileges to your vsphere environment administrators and denying them to everyone else is a good practice.
