I recently blogged about how in vSphere 5.1 you can now assign full admin privileges to named users, and in that post I commented that while it is possible to create local user accounts on each vSphere host that a better approach is to add your host to a Microsoft Active Directory (AD) domain and use your existing AD credentials instead. In this post I will provide an example showing how to do this.
Note that although the ability to assign full admin privileges to local users is new in vSphere 5.1, the ability to join vSphere hosts to active directory is not new. In this example I’m using vSphere 5.0.
Prerequisites
Of course before you can add your vSphere hosts to AD you need to have an AD domain. In addition you need to have a domain admin account with the rights to add computers to the domain.
Adding vSphere Hosts to Active Directory
To add a vSphere hosts to AD log on to the vSphere Client and from the “Host and Clusters” view:
- Select the host.
- Select the “Configuration” tab.
- Select “Authentication Services”.
- From the “Authentication Services Settings”, select “Properties…”.
This will launch the “Directory Services Configuration” wizard where you will:
- Set “Select Directory Service Type” to “Active Directory”.
- Enter the name of the AD domain.
- Click “Join Domain”.
When you click “OK” you will be prompted to enter the username and password of the AD domain admin account that will be used to add the host.
Monitor the progress in the “Recent Tasks” section and make sure it completes successfully.
That’s it, the host has been added to Active Directory and a corresponding computer account for the host created.
The next step is to setup user privileges. There are a couple ways to do this, you can assign privileges to individual users or to AD groups.
Assign Privileges to a User
To assign privileges to individual users you need to use the vSphere client and connect directly to the vSphere host.
Once you have logged in select the “Permissions” tab, right-click on the white background and select “Add Permission…”.
From the “Assign Permissions” pop-up you first need to select the user by clicking the “Add” button.
This will bring up the “Select Users and Groups” pop-up. Use the pull-down menu to change the “Domain:” to the name of the AD domain, find the user in the list, click “Add”, and then click “OK”.
Next, choose the role to assign to the user. Use the drop-down menu on the right to select the desired role and then select OK.
The user is now shown with the assigned role:
Note you will need to repeat these steps for each user on each vSphere hosts.
Assign Privileges to a Group
To help simplify the configuration you can assign permissions to an AD group opposed to individual users. With groups you only need go through the steps to assign privileges to the group once on each host opposed to once for each user. Once you assign the privileges to the group you manage user access by simply adding and removing users to/from the group in AD.
The steps to assign privileges to an AD group are the same as shown above, the only difference is instead of choosing a user you would chose a group.
The “ESX Admins” Group
Using AD groups helps simplify user configurations but there is still a requirement to repeat the configuration on each host, and if you have a lot of hosts this can still be a bit tedious. To avoid having to connect to each host to manually setup a group account VMware provides a default AD group named “ESX Admins” that automatically gets added to each host by default.
The key to remember here is that not only is this group added to each host, but by default it is also granted full administrative rights. As such it is important to limit the AD users who get assigned to the “ESX Admins” group. Arbitrarily assigning all vSphere admins to the “ESX Admins” group could compromise security. A few important things to note about the “ESX Admins” group:
- The group is not created in active directory by default. An administrator must manually create the group, but once created by default all users that are members of this group get full admin access to all vSphere hosts added to the domain.
- You can disable admin access to the “ESX Admins” group using the “Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd” setting.
- You can change the name of the “ESX Admins” group using the “Config.HostAgent.plugins.hostsvc.esxAdminsGroup” setting.
Summary
Adding your vSphere hosts to Active Directory can simplify user management and help improve security. It’s relatively easy to add local users to a hosts and to assign them administrative privileges, but if you have a lot of administrators the steps to configure each account will need to be repeated multiple times on each host.
You can simplify the local user configuration by using AD groups. With groups, rather than repeating the setup for multiple user accounts you only need to configure the group account once on each host. Once privileges have been assigned to the group you control who has access to the host by adding and removing users to/from the AD group.
VMware provides a default AD group called “ESX Admins” that, if created in AD, will automatically get added to each host when it is added to active directory. By default the “ESXi Admins” group is assigned full administrative rights to the vSphere host so it’s important to limit the users that are members of this group. You can change this behavior, as well as change the name of the group using the “Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd” and “Config.HostAgent.plugins.hostsvc.esxAdminsGroup” settings.












Pingback: Welcome to vSphere-land! » vSphere 5.1 Link-O-Rama
Great article Kyle – Thanks.
Running into a side-effect that you may be able to help me with. By adding permissions to AD Accounts we felt comfortable disabling SSH for root.
We are very dependant on SCP and find that we cannot copy files owned by root. If we Putty in with AD we can elevate to root on one side of the copy, but SCP will still fail on the other side?
This is fixed in 5.1. Prior to 5.1 you could not assign full admin rights to local/AD users and had to “su” anytime you needed to access a file that was owned by root. However, with 5.1 you can now assign full admin rights to these users and no longer need to “su”. This applies to ability to SCP root owned files as well. I just tested this out by using my AD account (kgleed) to SCP the public and private SSH keys from /etc/ssh over to my desktop.
Very welcome news Kyle!!
Appreciate your checking into this for us, and for taking the time to respond……
Thank you!!!
“… you need to have a domain admin account with the rights to add computers to the domain… ”
Does it have to be a domain admin user, or can it be a user with delegated permissions to add machines to the domain?
As soon as the domain user has enough rights to create computer objects to AD container, it doesn’t necessarily need to be a domain account.
This is great but how can you do it using cli so it joins ad on build?
Yes, you can use vicfg-authconfig. You can also use PowerCLI (see Set-VMHostAuthentication).
Does it matter if the AD is housed on a VM on the host that you are trying to set this up on?
Hi Kyle,
I have a small doubt, can you confirm, when we join the host to the domain, does it also creates a dynamic DNS Host (A) record in the DNS for name resolution.
You’re a legend Kyle! The info about the ESX Admins group got me out of a real bind. Someone had change the root password on one of our hosts. This host has Enterprise only license, so we couldn’t use host profiles to reset it. Was looking like a trip out to the DC and a boot into single user mode. But with the default group given local admin rights, I was then able to log in directly to the ESXi host with my AD account and use the Set-VMHostAccount to reset the root password.
Cheers!
Dylan
Something does not add up… to authenticate to a domain, you don’t have to join the domain. Since all you are doing is authenticating to a domain, an little more query for group membership… there is no need to create a domain object in AD, I can point to many solutions that integrate to AD, that do not require a computer object to be created. And with VMware SSO, why is ESXi ever talking to AD directly anyway? I don’t see the logic of the design as presented.
Hi.
for sure are there more ways to do the authentication… From my point of view the VMware solution has several advantages:
1. Security – as the ESXi server is a computer object in the ADS the communication between the ESXi and the DC’s is encrypted.
2. Domain Trusts – you can assign local permission to users located in domains the initial domain is trusting.
Best Regards
Thomas
Has anyone been able to setup an additional group, say linked to the read-only profile on ESXi and have it work as expected? I have tried this and I get an error that states that the given id in the non-ESXi Admins group does not have DCUI right so after id/password entered, the login fails with error stating given id does not have DCUI permission. But I find no reference to the DCUI permission in any of the defined ESXi profiles. But obviously the members of the ESXi Admins group get the DCUI permission or login would fail, which it does not.