Best practices for a Windows administrator dictate that once a server is installed, you should configure it such that you do not log in as a Windows administrator. The same is true when it comes to VMware vSphere administration: You shouldn't log in to a vSphere client with the Windows administrator login once vCenter Server is up and running and properly configured. But to get around that, you need to connect vSphere with Windows Active...
In this tip, I'll explain how to create a Windows AD group and have vSphere use the group to control who can administer the virtual infrastructure.
Why shouldn't I use the administrator account to administer vSphere?
Just as you don't want everyone logging in to your Windows PCs as "Domain Administrator" or even as a "Local Administrator," you don't want all your VMware administrators logging in to vSphere as the domain admin (or whatever administrator account you created that has full access). This is true for a few reasons:
- Accountability – If everyone has the same username, how do you know who to blame when something happens with your virtual infrastructure? Everyone should log in as themselves so that all changes are logged under their name instead of a universal account.
- Authentication - If everyone logs in as administrator, how do you know if you have a malicious attacker on your network? Everyone looks the same.
- Authorization – You need to limit access to the virtual infrastructure. Have you heard of the principle of least privilege? You should only grant access to the company's resources that are required for that individual to perform his/her job. Thus, everyone should log in as themselves and be limited to the area and tasks of the virtual infrastructure that they need to perform.
Creating a Windows AD group to be used for vSphere administration
Windows Active Directory is likely your single repository for credentials (usernames and passwords) on your network. You want VMware to use Windows AD, not to create another credential repository. Luckily, VMware has this functionality built in and it is very easy for AD and VMware to work together.
Even if you are the only VMware administrator on your network, you should start off by creating a Windows group called "vSphere Admins." You might be the only person in that group initially, but you can add other people later. You could also create other groups and name them "vSphere Desktop VM admins" or "vSphere Web Server admins," for example. These people wouldn't have full access, but could administer specific VMware virtual machines that fall into their area. You could even get more specific and create a group named "vSphere Support Techs," giving those users power-on and power-off rights to specific virtual machines.
Let's create a "vSphere Admins" group. To do this, just go to your Windows DC and run Active Directory Users and Computers (or run it remotely).
Once running, simply create a new global security group inside your Windows AD called vSphere Admins, as seen in the image below.
Next, add yourself and any other vSphere admins to that group, as seen here:
That's it for the Windows AD side. Now let's cover what you need to do in vSphere.
Configuring vSphere to use your Windows group to control administration
Once you have your Windows AD group and your users inside, you need to tell vSphere to use that Windows group. Assuming that you are going to give full vSphere administrator rights to the users in these groups, click on the highest level in the Inventory tree in the Hosts and Clusters Inventory. This should be the vCenter server for your virtual infrastructure.
Click on that vCenter server, then click on the Permissions tab. Here you should see that the Administrators group has full access.
What we are going to do next is to create a new vSphere administrative group and remove the current group. Obviously you wouldn't want to remove the current group before you add the new group or you wouldn't have any access.
To add the new group, right-click in the whitespace of the permissions tab and click Add Permissions.
This will result in the Assign Permissions window appearing. On this window, you will click Add to add new users and groups.
The Select users and groups window will appear. Select the domain that you will be using to pull the users and groups from. In our case, we selected the WIREDBRAINCOFFEE domain. There were many users and groups in the list so I used the Search option and I searched for vSphere. This showed me only the newl-created vSphere Admins group. I selected the group and clicked Add.
From here, I clicked OK.
Back in the Assign Permissions window, the vSphere Admins were added but they only had Read-Only permissions by default.
On the right-hand side, I used the drop-down menu under Assigned Role and scrolled down to Administrator.
Next, I clicked OK to make this administrator role assignment to the vSphere Admins group take effect.
At this point, we had two different groups able to make administrative changes to vSphere.
Now, we need to remove the default administrator's group. To do this, right-click on it and click Delete. You will get a Confirm Removal message. Click Yes to continue.
At that point I was immediately kicked off my vSphere client -- you will be as well, because you signed in as the administrator, right?
Testing the new Windows AD / vSphere security configuration
To test it out, all you need to do is to connect to the vSphere client. You will log in as yourself and use whatever username and password you defined for yourself in the Windows AD. If you are already signed into your PC using a Windows AD login, and that login is the same as a Windows AD login defined in new vSphere Admin group, then you can click Use Windows Session Credentials -- you don't have to enter a username or password to connect.
As I hadn't logged in to the domain on my PC, I manually entered my Windows domain username and password.
The vSphere client successfully logged in as "ddavis" (that's me). I no longer had to log in as the Windows Domain Administrator.
Finally, I went to the permissions tab of the vSphere vCenter server and verified that only the WiredBrainCoffee.com domain group called vSphere Admins was able to log in and control the virtual infrastructure.
That's it. Simple!
David Davis is the director of infrastructure at TrainSignal.com. He has a number of certifications including vExpert, VCP, CCIE #9369, MCSE and CISSP. Additionally, Davis has authored hundreds of articles and six different video training courses at Train Signal with his most popular course being VMware ESX Server. His personal website is VMwareVideos.com. You can follow Davis on Twitter or connect with Davis on LinkedIn.