IT security, accountability and auditability are critical today. Securing vCenter Server using auditable identities, for instance via an Active Directory identity source, is likely common for most vCenter consumers. This ensures individual access can be used to audit actions back to an admin as well as provide higher security through strong password policies and the absence of a shared account credentials, such as the SSO administrator.
Something that can be overlooked is the security of the ESXi hosts themselves.
There are multiple options for securing your ESXi hosts, one being the use of lockdown modes and limited user access, restricted management network access, or a combination of them both.
In this blog post I want to show you a simple way to configure your hosts to use an Active Directory group to control user access to an ESXi host.
This is achieved by editing the value associated with an advanced setting – ‘Config.HostAgent.plugins.hostsvc.esxAdminsGroup’.
One prerequisite to achieving this is that the hosts must be domain joined. Information on how to do this can be found here.
Editing this on a handful of servers is easy enough if you are doing it manually, but who wants to be manually typing or copying & pasting this?
I have put together a PowerShell Function that can simplify the editing of this setting for single hosts, or on mass to all ESXi hosts that you have connected your PowerCLI session to.
Set-ESXiHostAdminGroup -Target single -Entity esxi01 -Group "infrastructure_admins"
Set-ESXiHostAdminGroup -Target all -Group "infrastructure_admins"
For the purposes of this demo, I will update all ESXi Hosts within my vCenter instance using the second example. You could edit the function to target clusters if you wish.
Setting before –
Set-ESXiHostAdminGroup -Target all -Group "infrastructure_admins"
Function Output
After –
You will need to wait the length of time defined in this setting until being able to log in –
Now all users that are in the ‘infrastructure_admins’ Active Directory group will be able to log into the ESXi host with administrator permissions using their AD credentials.
Following on from my last post on vSphere 7.0 certificate Management, I wanted to continue with another certificate related post. This one being Site Recovery Manager (SRM) 8.3. Like vSphere 7.0, this version seems simpler than previous versions I have used.
With SRM, it’s the Appliance Certificate replacement that I am going to take you through in this blog post.
Firstly log into the SRM appliance management console via https://<srm-fqdn>:5480 and select the ‘Certificates’ option on the left, followed by ‘Generate CSR’ in the top right.
Fill in the information for your certificate, then click ‘Generate and Download’. You then need to process the CSR with your certificate authority, whether thats an internal, public or lab CA.
Once you have your certificate, select the ‘Certificates’ option on the left again, this time followed by ‘Change’ in the top right.
Select the last option in the Select certificate type section; ‘CA-signed certificate generated from CSR’. Then, browse both your newly generated certificate and either you root CA certificate, or the CA chain. Click ‘Change’ once done.
This should complete the replacement of the SRM appliance certificate!
If like me you get an error complaining that the IP or Common name / SAN is missing, make sure the local host field is set to the FQDN when connecting SRM to vCenter.
vCenter 7.0 brings many new features, one of which is a much smoother certificate management experience. There are now 4 main ‘modes’ for certificate management.
These are; Fully Managed Mode, Hybrid Mode, Subordinate CA Mode and finally Full Custom Mode. There is a great article here from Bob Plankers explaining the difference between each.
As mentioned in Bob’s blog, Hybrid Mode is the recommend option, and I will show you that process here in this blog.
Firstly, in your vSphere Client, browse to Administration > Certificates. Then click Actions and select ‘Generate Certificate Signing Request (CSR)’.
Complete the required fields with your information, making sure you have at least added the common name as a Subject Alternative Name to avoid issues with modern browsers. Click Next.
Finally, copy or download your CSR to generate the certificate on the CA of your choosing. Click Finish when ready.
Once you have your certificate, return to Administration > Certificates and this time select ‘Import and Replace Certificate’.
You then need to select the second option. This may seem slightly deceiving but it effectively is the option you need when you have generated the CSR from vCenter like this.
Now browse and select both your freshly produced certificate, and the root certificate or certificate chain if you have issuing CA’s.
Hit replace, then wait for the Web Client to restart with the new certificate.
Now one final step is needed to complete Hybrid Mode. You need to download the VMCA Root certificate from https://<vCenterFQDN by clicking the ‘Download trusted root CA certificates’ option and distributing it to your vSphere admins.
Once distributed and installed on your vSphere admins client devices, they should not get certificate errors when either browsing to vCenter or the hosts it manages.
You could however, get this error due to the default certificate having a 5 year validity period and not being within the new ‘standard’ of 398 days.
NET::ERR_CERT_VALIDITY_TOO_LONG
If you receive this, you will want to adjust the vpxd.certmgmt.certs.daysValid value in the vCenter Advanced Settings. It defaults to 1825, making it 365 (one year) will stop this.
You can then renew the certificate on each host by clicking ‘Renew’ in the Configure > Certificates menu –
Before (5 years) –
After (1 Year)-
If you want to do this renewal via PowerCLI (because…well why wouldn’t you!?) there is a nice function here by Ankush Sethi which does a great job.
VM Encryption is achieved using storage policies. By Default after configuring a KMS server, the ‘VM Encryption’ is available for use. Alternatively, you can create your own custom VM Encryption storage policy to include additional host based services such as caching and Storage I/O.
For a new VM, select the ‘Encrypt this virtual machine’ option on the ‘Select Storage’ section of the New Virtual Machine wizard. Then select the default encryption policy, or a custom one if you have one.
Then when customising your hardware you will see the following notification –
Once deployed, you will see confirmation of the virtual machines encryption status on the VM’s summary tab.
For an existing VM, it’s a slightly different approach.
Firstly, power off the VM. Edit the VM’s settings and on the VM Options tab, expand the Encryption option and select your desired VM Encryption policy like so –
Below the policy you will see the option to select which disks you want to encrypt. In this test VM’s case, there is only one disk, disk 0. You can choose to only encrypt the VM and not the disks if you have a use case to do so. Disks you choose not to encrypt will have the datastore default policy applied to them.
Alternatively, you can take a different route by editing the storage policy of a powered off VM to achieve the same result. Here you can also choose to ‘Configure per disk’. This is a useful option if you only have select hard disks you need to encrypt.
The VM will then reconfigure, this may take some time depending on the size of the disks, so make sure you factor this into your downtime window!
If you check out the performance backend monitor you will notice an increase in throughput an I/O while this is happening.
One disk at a time copies data from unencrypted to new encrypted disk. Once done, it attaches the new encrypted disk and deletes the old unencrypted disk. You will need enough disk space on the datastore to allow the duplication of the largest disk attached to the VM.
Once the task is complete, you will notice you have an updated encryption status.
Now the flip side, un-encrypting a VM.
This is a reverse of the process. Power off the VM, change the storage policy to a non Encryption policy and power back on when complete.
Now on to vSAN Encryption.
To enable encryption for an entire vSAN cluster, its just a few clicks but there are a few things to be aware of.
Make sure you have adequate free space within the vSAN cluster to allow for the rolling reformatting of the disk groups.
There will be increased IO during this operation, make sure you choose an appropriate maintenance window to do this in so as to not cause unwanted impacts to your workloads.
To enable this feature, select the cluster you wish to enable encryption on and browse to the ‘Configure > vSAN > Services option.
Click to enable ‘Data-At-Rest Encryption’.
You have the option to check the ‘Wipe residual data option’ if you have a need to. Bare in mind, wiping the storage can take a significant amount of time, so only use this option if you need to wipe existing data.
The final option is ‘Allow Reduced Redundancy’. This option will allow vSAN to run your workload at a reduced redundancy level during the encryption process. Make sure you understand the risks before using this option.
Hit apply and the cluster will begin reconfiguring.
Once it has cycled through each host in the cluster you will be able to see that the encryption status is now ‘Enabled’
This has to be one of the first things you consider with any technology solution or decision today. So when I was lucky enough to receive a NFR license from HyTrust for their KeyControl Key Management System I was excited to get this into my lab so I can make use of VMware’s vSAN and VM Encryption.
In this post I will be going through the process of deploying a HyTrust Key Control appliance and creating a trust with vCenter. It was surprisingly straight forward and I was up and running in no time at all!
Firstly, deploy the OVA to an ESXi Host or Cluster that isn’t going to be managed by the Key Control appliance. You don’t want your encryption keys in the same place as the objects you are encrypting!
Follow the OVF deployment wizard, providing the details as prompted, and once the appliance is online, complete the final configuration steps to finish the installation.
You will then be met with this screen –
Now, browse to the web GUI and log in using the default credentials. You will then be prompted to set your own, followed by SMTP and online monitoring configuration options.
Once this is done and you are logged in there are a few KMIP settings you need to adjust in order for it to be ready to connect to vCenter as a Key Provider –
State = ENABLED
Protocol = Version 1.1
Below is a link to a HyTrust document with the details for vSphere 6.5. I used this for deployment in my vSphere 7 environment. You can find it here.
You will also want to apply a license file. This is done via; ‘Settings > License’, by way of uploading the license file you have been issued.
This completes a basic configuration that is now ready to connect to vCenter. If you are deploying outside of a lab environment, you are going to want to review your installation appropriately for the environment it is intended for.
So over to the Web Client. Select the vCenter Server object, select ‘Configure > Security > Key Providers’ and hit ‘Add Standard Key Provider’.
You will then want to give it a name, followed by the requested information. Once done, click ‘Add Key Provider’
You will receive the following prompt to confirm you want to from the Key Provider you have entered. Click ‘Trust’
This will have now created a Key Provider, but will show that it is not connected and has a certificate issue. So next we need to set up the trust.
This can be done by clicking ‘Establish Trust’ and selecting ‘Make KMS trust vCenter’
In my lab, I have gone with the option of creating a CSR and having the KMS issue a certificate –
Download the CSR using the option available. This will be in the .pem format which is exactly what you need.
Now over to the HyTrust appliance, load the CSR we downloaded into the wizard, as well as a name, and hit create. This is via the KMIP menu and selecting ‘Actions’ followed by ‘Create New Client Certificate’.
Once this is done, select the certificate and click ‘Actions’ and select the ‘Download Certificate’ option. This again will come in the requested .pem format.
Back to vCenter, we now need to upload the certificate using the ‘Establish Trust’ option and selecting ‘Upload Signed CSR Certificate’.
Once uploaded, you will see that the connection is now showing as connected and has a valid certificate.
This is now setup and ready to begin looking at VM and vSAN Encryption. Check out the next post which will go into both these options in more detail.
Configuring host VMKernel adapters for iSCSI can be a time consuming process. PowerCLI can take away a lot if not all of the effort.
Below is an example of using PowerCLI to create a Standard Virtual Switch (vSS), configure a VMKernel adapter, set the VLAN, enable the software iSCSI adapter (if that’s what you are using), bind it to the required network adapter and finally, add a dynamic Discovery target and rescanning the HBA’s.
This is based on targeting a single host at a time and re-running it with the paramaters for each host.
#Load PowerCLI Modules
Import-module VMware.PowerCLI
#Variables
#vCenter or Host to Connect to
$vCenter = "smt-lab-vcsa-01.smt-lab.local"
#ESX Host to target
$ESXHost = Get-VMHost "smt-lab-esx-01.smt-lab.local"
#Name of the iSCSI Switch
$iSCSISwitchName = "vSS_Storage_iSCSI"
#vmnic to be used for iSCSI Switch
$iSCSISwitchNIC = "vmnic2"
#MTU size
$MTU = "9000"
#Name of the Portgroup for the VMKernel Adapter
$iSCSIVMKPortGroupName = "vSS_VMK_iSCSI_A"
#iSCSI VMK IP
$iSCSIIP = "10.200.33.50"
#iSCSI VMK SubnetMask
$iSCSISubnetMask = "255.255.255.0"
#iSCSI VMK VLAN ID
$VLANID = "300"
#iSCSI Portal Target
$Target = "10.200.33.1:3260"
#Connect to vCenter
Connect-VIServer $vCenter -Credential (Get-Credential) -Force
#New Standard Switch for iSCSI
$NewSwitch = New-VirtualSwitch -VMHost $ESXHost -Name $iSCSISwitchName -Nic $iSCSISwitchNIC -Mtu $MTU
$NewPortGroup = New-VMHostNetworkAdapter -VMhost $ESXHost -PortGroup $iSCSIVMKPortGroupName -VirtualSwitch $NewSwitch -IP $iSCSIIP -SubnetMask $iSCSISubnetMask -Mtu $MTU
Set-VirtualPortGroup -VirtualPortGroup (Get-virtualPortGroup -VMhost $ESXHost | Where {$_.Name -eq $iSCSIVMKPortGroupName}) -VLanId $VLANID
#Enable Software iSCSI Adapter
Get-VMHostStorage -VMHost $ESXHost | Set-VMHostStorage -SoftwareIScsiEnabled $True
#Bind the iSCSI VMKernel Adapter to Software iSCSI Adapter (credit to Luc Dekens for this)
$esxcli = Get-EsxCli -V2 -VMHost $ESXHost
$bind = @{
adapter = ($iscsiHBA = $ESXHost | Get-VMHostHba -Type iScsi | Where {$_.Model -eq "iSCSI Software Adapter"}).Device
force = $true
nic = $NewPortGroup.Name
}
$esxcli.iscsi.networkportal.add.Invoke($bind)
#Add Dynamic Discovery Target
$ESXHost | Get-VMHostHba $iscsiHBA | New-IScsiHbaTarget -Address $Target
#Rescan Hba
Get-VMHostStorage -VMHost $ESXHost -RescanAllHba
The results –
Something you may also want to do is set the Path Selection Policy (PSP) to the commonly used; ‘Round Robin’. The first command will provide a list of attached storage, showing you the CanonicalName (which is what you need for the second command), the current Multipathing Policy and the size of the storage device.
Identify the device you wish to set the pathing policy on and substitute the Canonical Name (naa.xxxx) into the second command.
You could of course take this further by importing all the data required for multiple hosts using an array, whether as a a manually created array in PowerShell, or by importing a csv or txt file to enable you to configure numerous hosts at once by making use of a ForEach loop.
Now, if you are using Virtual Distributed Switches (vDS), here is an alternative (I have assumed you already have an operational vDS in place).
#Load PowerCLI Modules
Import-module VMware.PowerCLI
#Variables
#vCenter or Host to Connect to
$vCenter = "smt-lab-vcsa-01.smt-lab.local"
#ESX Host to target
$ESXHost = Get-VMHost "smt-lab-esx-02.smt-lab.local"
#Name of the vDS
$iSCSISwitchName = "smt-lab-dc01_vDS_01"
#Name of the Portgroup for the VMKernel Adapter
$iSCSIVMKPortGroupName = "smt-lab-dc01_vDS_VMK_iSCSI_B"
#MTU size
$MTU = "9000"
#iSCSI VMK IP
$iSCSIIP = "10.200.34.51"
#iSCSI VMK SubnetMask
$iSCSISubnetMask = "255.255.255.0"
#iSCSI VMK VLAN ID
$VLANID = "301"
#iSCSI Portal Target
$Target = "10.200.34.1:3260"
Connect-VIServer $vCenter -Credential (Get-Credential) -Force
#New VMKernel Adapter on vDS
$NewPortGroup = New-VMHostNetworkAdapter -VMhost $ESXHost -PortGroup $iSCSIVMKPortGroupName -VirtualSwitch $iSCSISwitchName -IP $iSCSIIP -SubnetMask $iSCSISubnetMask -Mtu $MTU
Set-VDPortGroup -VDPortgroup (Get-VDPortGroup | Where {$_.Name -eq $iSCSIVMKPortGroupName}) -VLanId $VLANID
#Bind iSCSI VMKernel Adapter to Software iSCSI Adapter (credit to Luc Dekens for this)
$esxcli = Get-EsxCli -V2 -VMHost $ESXHost
$bind = @{
adapter = ($iscsiHBA = $ESXHost | Get-VMHostHba -Type iScsi | Where {$_.Model -eq "iSCSI Software Adapter"}).Device
force = $true
nic = $NewPortGroup.Name
}
$esxcli.iscsi.networkportal.add.Invoke($bind)
#Add Dynamic Discovery Target
$ESXHost | Get-VMHostHba $iscsiHBA | New-IScsiHbaTarget -Address $Target
#Rescan Hba
Get-VMHostStorage -VMHost $ESXHost -RescanAllHba
A slight change to the cmdlts used; PortGroup > VDPortGroup.
Here are the results –
There are now two paths to my iSCSI device, one via a Standard Switch (vSS) and one via a Distributed Switch (vDS) across two subnets.
Hope this has been helpful. It has saved me plenty of time throughout the countless builds and tear downs of my VMware home lab.
A useful thing for a home lab or VMware lab, is a certificate authority. There are Windows based CA’s as well as Linux based and many others. I wanted to take the Linux based route for my home lab to give me some administration time in Linux, being that Windows is my safe place! After a bit of googling, I settled on Easy-RSA as it looked like it would do what I needed in the lab. There are already a few guides out there for this, but this is my take on it for use in my VMware home lab.
I settled on CentOS 8 as a base OS. Why? Why not, I don’t have any Centos VM’s and I decided it would be good to use something other than Ubuntu or Photon.
Firstly, I stood up a low resource VM (1 vCPU, 1GB RAM) giving it a static IP and creating an admin account.
I then kicked off the update of all the install packages on the OS by first elevating to the root account using ‘SU’ and then running the upgrade command for the DNF package manager.
dnf upgrade
This prompts a ~600MB download after confirming you want to continue. Once the download completes it gets on with upgrading.
Once done, its time to install some additional packages starting with epel-release, easy-rsa and openssl. Lets quickly give some background to each.
epel-release (Extra Packages for Enterprise Linux) is a repository of popular packages which aren’t available by default. easy-rsa is one of the packages in this repository.
easy-rsa This is a utility for managing Public Key Infrastructure(PKI) aka Certificate Authority. Check out some info here.
openssl A widely used tool, in this case to create Certificate Signing Requests (CSR). I’ll let you read about this here.
Lets get to the install. You can run them as separate installs like this –
Now for ease of administration, create a directory in the admin users home directory and create a symbolic link so it remains updated. You also want to limit access to your admin user in my case ‘ca_admin’.
If you’re not familiar with chmod commands, ‘chomd 700’ = Protects a file against any access from other users, while the issuing user still has full access.
Now to initialise your new PKI. Change Directory (cd) to the easy-rsa directory you created in your admin users home directory and run the initialisation command.
cd ~/easy-rsa
./easyrsa init-pki
You will get a message showing it is complete and it will state the new pki directory that has been created inside the easy-rsa directory (/home/ca_admin/easy-rsa/pki)
You now need to create and populate a file called ‘vars’ in /home/ca_admin/easy-rsa and populate it with your organisation/lab information. You can achieve this with the vi editor.
Once created, you are now ready to create the root certificate and private key by running the following command –
./easyrsa build-ca
You will be prompted to specify a passphrase which you need to keep safe as you will need it when issuing certificates. There will then be a second prompt to provide a common name; Enter you CA’s name. eg. CA01.
This process will have now created your root certificate and the private key (keep this safe). You will find them in the following locations /home/ca_admin.easy-rsa/pki/ca.crt (root certificate) and /home/ca_admin.easy-rsa/pki/private/ca.key (private key).
If you are using a Windows device to access your HomeLab, you are going to want to add the ca.crl file to the ‘Trusted Root Certification Authorities’ store on your Windows device so that any certificates issued are trusted. You can copy the ca.crt file using a tool such as WINSCP to transfer the file to a local directory to then install. You can do the equivalent on Mac and Linux OS’s too.
You will also need this handy for any certificates that require the full chain to be included.
I won’t go into every Certificate Signing Request (CSR) scenario as there are many. I will however, show you the commands needed to produce a certificate from a CSR.
To issue a certificate from a CSR, you will need to copy the .req or .csr file to a directory such as /tmp on your CA server, again using a tool like WINSCP.
You can then run the following commands to import the certificate signing request. The Common name is often the device name or FQDN.
cd ~/easy-rsa
./easyrsa import-req /tmp/<csr_file_name>.req <CommonName or FQDN>
./easyrsa sign-req server <CommonName or FQDN>
The import command will import the .req or .csr file into /home/ca_admin.easy-rsa/pki/reqs (you can’t place the .req directly in here!) which is then processed by the sign-req command, again asking for the passphrase, leaving you with your new certificate in the /home/ca_admin.easy-rsa/pki/issued directory.
You can then use WINSCP again to transfer the file off the CA, and install it on the device or service in which you requested it from.
As always with any root CA, you don’t want it to become compromised. To help with this, keep it turned off when you’re not issuing, or administering your certificates.
I have also not included any Certificate Revocation List details as this isn’t something I need in my lab environment.
Now the VMware bit… below is the process for acquiring the CSR and installing the generated certificate on an ESXi host and a vCenter server using the methods above.
Standalone ESXi Host 6.7
First for a standalone ESXi Host, browse to – Host > Manage > Security & Users > Certificates
Select Import new certificate then select either ‘Generate FQDN signing request’ or ‘Generate IP signing request’.
You will be presented with a screen like this.
Copy this into a file with the extension .req. This can then be imported and issued using the method above.
Then, go back the the ‘Import new certificate’ wizard and import the certificate in the same format at the CSR into the box. (Open the .crt file using notepad)
Once complete close and open your browser and head back to your hosts web client and you will see you no longer have a certificate error.
vCenter Server 6.7
Log into your vCenter appliance using via SSH. Then run the following command –
/usr/lib/vmware-vmca/bin/certificate-manager
Select option 1, (you will be prompted to provide your SSO credentials), followed by option 1 again.
You will then need to provide the following information for the CSR.
As you complete the wizard you will have a .csr and a .key file in /tmp which again can be issued using the process above.
If using WinSCP you may hit the following error.
You will need to change over to the bash shell.
chsh -s /bin/bash root
You could then face another error…
root@vcsa02 [ ~ ]# chsh -s /bin/bash root
You are required to change your password immediately (password aged)
chsh: PAM: Authentication token is no longer valid; new one required
This is due to the password expiring. To change the password on the account run the passwd command
Further info on both of these errors can be found at these two VMware Articles. Here and here.
Once you have issued the certificate, you need to then copy the .crt file back to the /tmp directory along with the root certificate (or chain).
Now back to the Certificate Manager. Selecting option 1 to now import the certifictes. You will be prompted to provide the path and file name of each component. The certificate you created, the .key file that was created during the CSR generation and the root or CA chain certificate. Finally you will be asked to confirm you want to replace the Machine SSL certificate, type y.
It will take a few minutes, but eventually you will get confirmation that the task is complete and you can then reload your browser to see the Web Client is now showing a valid certificate.
Hope this has been useful. I will cover vCenter 7.0 Machine SSL certificate replacement in a future post.
Encrypted vMotion is a feature available in vSphere 6.5 onwards. It is something that is always used to secure vMotions of encrypted virtual machines, its a required option, but is optional for non encrypted virtual machines.
By default, non encrypted virtual machines will be set to ‘opportunistic’. If both the source and destination hosts support it (so ESXi 6.5 onwards), vMotions will be encrypted. If the source or destination does not support it, then the vMotion traffic will not be encrypted.
The ‘required’ option is exactly what it says, encrypted vMotion is required. If either the source or destination host does not support it, the vMotion will fail. As I’ve said, encrypted virtual machines have no choice, they have to use encrypted vMotion.
The final option is to set it to ‘disabled’, for when you don’t want it to even attempt encrypting vMotion traffic for a virtual machine.
To set this option on either a singular virtual machine or all virtual machines, you can use the options below. Firstly to view the current settings you can run this. If you want to target a single VM enter the VM name after Get-VM.
I recently needed to create a new Distributed Port Group and set a specific load balancing policy on an existing Distributed Switch. Nothing to exciting, but a task many have to complete. As this is a common repeatable task, i put together this short .ps1 to allow a repeatable way of completing this.
Just populate the Variables section with required information like so…
Save the file, then run the the .ps1 file from PowerShell prompt. (Ensure you have the PowerCLI Module installed; see my previous post)
Note you must add .\ to the beginning of the file name if you are executing the file from the directory you’re already in
Enter credentials with sufficient privilege in vCenter.
You will then see an output similar to this:
If you now take a look in the Web Client you will see the freshly created Distributed Port Group.
Creating just a single portgroup could potentially be quicker in the Web Client. What isn’t quicker, is multiple.
If you have a requirement to create multiple Distributed Port Groups on a vDS, you can use this script to do so in one go.
Just populate the Variables section with required information like above, then run the the .ps1 file from a PowerShell prompt. (Ensure you have the PowerCLI Module installed; see this post.
This uses and Array Table to build your source data, in this example, the PortGroup Name and VLAN ID for each. You can add further rows (more Port Groups) to the array by repeating the line in the red box, or add additional attributes by repeating the text from the green box on each line.
There are many ways you could modify this script to change the source of data, including ‘Get-Content’ from a .txt file for instance.
The use of VMware tags recently became a requirement for some of my colleagues in an environment that was inherited. They were faced with being unable to create Tags & Tag Categories or Assign and Delete them, despite ‘having admin rights’.
Upon investigation it became apparent that while the admins had been granted the Administrators Role at the vCenter Object Level, they had had not been granted sufficient rights at the Global Permissions Level, or any rights for that matter.
The following graphic shows the vSphere Inventory hierarchy.
As you can see from the graphic, assigning privileges at the Global Level is required to manage Tags and additionally, Content Libraries.
You can see below a vSphere Admin, who has the Administrator Role assigned at the vCenter Level, is not able to select the New, Edit, Delete or Add Permission options for Tags or Tag Categories.
In this scenario there were two different permission requirements, one for a vSphere Admin team, the other for a Storage team both of which could be addressed by two existing roles; Administrators and Tagging Admin. You could of course create a custom role should you have a requirement to do so. Here are the privileges assigned to the tagging admin role for reference.
The vSphere Admin Team required the Administrator Role at the Global Level (root object) so they could manage Content Libraries and Tags, while the Storage Team required the ability to Create and Assign Tags only.
You can assign permissions to a user or a group from multiple Identity Sources, in this scenario, an Active Directory source. You will need to do this from an account that already has the Administrator Role at the Global Level. By default, the administrator@vsphere.local account has this privilege. (replace the domain as needed if you have used a different SSO domain name)
From the Menu, select ‘Administration’ and select the ‘Global Permissions’ option in on the left-hand side.
From here, select the Add Permission icon.
You can now select the domain of the user or group you wish to add from the drop-down list and begin to type the name of that user or group. It will begin to narrow your selection as you type.
Select the user.
Now select the appropriate role and select the ‘Propagate to child object’ option.
If you have multiple users, groups or roles you need to assign, repeat the process.
You will now see both permissions in the Global Permissions menu. If logged in, you will need to log out and back in for this to take effect. Both scenarios are shown.
If you now return to the Tags & Custom Attributes menu, logged in as a user from either of these groups, you will see that the New, Edit, Delete or Add Permission options for Tags or Tag Categories are now available.
Note: Providing a user or group privileges at the Global Permissions Level and selecting, ‘Propagate to child objects’ will give that user or group the privilege’s on the child objects such as vCenter, Cluster, VM and Datastore.
This can be useful if you have multiple vCenters in Enhanced Linked Mode (ELM) as you only need to apply it once.
vCenter –
Host –
Datastore –
Further information can be found in the following VMware article which explains how you can grant permissions on a Tag object, rather than at the Global or vCenter Levels to give you further granualar control.
![TRUST
H
SECURITY
Actions •
Host Name:
port:
State
Basic
Client Certificates
Objects
10.200.15.15
5696
ENABLED
OFF
Yes
Version 1.1
Detault
OFF
O Infinite
CREATE-MODIFY
DISABLED
Connections Will use TLS 1.2 if set to Enabled
AUDIT LOG
v
Auto-Reconnect
Verity
Protocol:
Certificate Type:
Nöio:
Timeout:
Log Level:
Restnct TLS]
Custom nex value](https://stephanmctighe.files.wordpress.com/2020/08/image-1.png?w=1024)
