Introduction
With vSphere 5, vCenter is now available in a Linux-based virtual appliance format. This eliminates the need for a Windows license, Windows install, and vCenter installation. The vCenter Server Appliance (vCSA) can simply be downloaded and deployed into your virtual infrastructure, allowing you to get vCenter up faster than ever before. In my previous two articles on vCSA, I walked you through Getting Started with the vCenter Server Appliance (vCSA) and How to Configure the vSphere 5 vCenter Server Appliance (vCSA).
Once deployed and configured most vSphere admins who have been used vCenter in the past are going to expect this new virtual appliance version of vCenter to work similarly when you login and assign vCenter security roles. What I mean is that with vCenter for Windows you expect to be able to login as the Windows domain administrator and be able have full administrative rights to the vSphere infrastructure. vCSA doesn’t work like that, by default. In fact, with vCSA, by default, you can’t even login using a Windows active directory account.
In an enterprise vSphere infrastructure where active directory is used you should create role-based access using AD groups and users. For example, the most simplistic example would be to create an AD group called “vSphere Admins” (or similar), put all the vSphere admins in that group, and assign them the administrative role in vCenter. In the more typical scenarios you would have many more vSphere security roles in place, mapped to multiple AD groups and users. Best practices for vSphere security would also dictate that once you created this vSphere group and assigned them the administrator role, you would then prevent the Windows administrator account from logging into vCenter. This way, you know that only named users would be logging in and making changes to the vSphere infrastructure.
So how do we configure the vCSA to use Windows AD authentication, create an AD group, and assign a vSphere role to use that AD group? Let’s find out.
Configuring vCSA for Active Directory Authentication
By default, you will only be able to login to vCSA using the default username and password- root / vmware. This goes for the web interface and connecting to vCSA using the Windows or web-based vSphere Client. Our goal is to instead use our existing Windows AD.
The first requirement of this process is that networking is properly configured on the vCSA VM. It is required that the vCSA VM has it’s DNS server entry configured such that the vCSA VM can locate the active directory domain controller (DC). This works the same way as any Windows client that must be able to find the domain controller, using DNS, before it can join the active directory domain.
To configure DNS in vCSA, go to the Network tab and click on the Address section. If you haven’t already configured a static IPv4 IP address then configure one now. Make sure that, included in that configuration you enter the fully-qualified DNS name for the vCSA VM (like vcenter5.wiredbraincoffee.com) and the preferred DNS server. That DNS server should be able to tell vCSA who the active directory domain controller is such that when vCSA attempts to join the domain, it can.
As you see in Figure 1, the strange thing about configuring a vCSA DNS server and hostname is that, to do it, you must change the IPv6 address type to SLAAC. The boxes for the static DNS information do not appear until you make the IPv6 change (this has got to be a bug unless I am misunderstanding something here). You don’t have to use IPv6, just make this change.
Figure 1
With the required networking configured, you should also have already done the following:
- Created a DNS entry for the vCSA static IP address you configured that matches the hostname you also configured
- Brought up a Windows AD domain controller
- Have the username and password
Now, it’s time to configure active directory authentication in vCSA. To do that, go to the Authentication tab and then to the Active Directory section. It’s here that you will Check to enable Active Directory. Then, fill out your domain name, administrator username, and administrator password. Finally, click Save Settings.
Figure 2
Once you save, you’ll be told that you need to restart the vCenter management services on the vCSA virtual appliance to make this change take effect. To do this, go to the vCenter Server tab and to the Status section. Click on Stop vCenter, wait until you see they have stopped, and then click Start vCenter.
At this point you could make all sorts of assumptions about who can login to the vCenter server. Perhaps anyone with an AD account? Perhaps just the administrator group or user? However, the answer is that, at this point, NO ONE from AD can login (again, unlike vCenter for Windows) because you have yet to authorize anyone. At this point, only the root user can login using the vSphere Client, pointed to vCenter (and that will likely always be the case unless you disabled it).
Authorizing Windows AD Users to Administer vCenter
To authorize Windows AD users to login to vCenter, you need to login using the vSphere Client, still using the root username and password (default is root/vmware).
Figure 3
From here, navigate to the vCenter level (the highest level) of the hosts and clusters inventory tree and go to the Permissions tab. It is here that you want to authorize an AD user or group (more likely) to administer the vSphere infrastructure.
Of course, with the vCenter hierarchical management system, any permission you put at one level of the inventory tree applies to all objects below that and you are free to create whatever permissions, mapped to AD users and groups, that you choose to. For example, you might create a web development resource pool, create a Windows AD group for web developers, and allow all web developers authenticated with AD to administer the VMs in that pool.
Back to our configuration, at this point, if you don’t have any Windows AD groups that you want to use, you need to go and configure them. A common example would be for you to create a Windows AD group called “vSphere Admins” and then allow them to administer the virtual infrastructure.
So let’s assume that I already created that group in AD and added a user called “sally” to that group. In the vSphere Client, at the vCenter level, on the permissions tab, I would right-click and select Add Permission.
Figure 4
Select the Windows AD domain and the new AD group you created (in this example, it was called “vSphere Admins) and click OK.
Figure 5
Change the Assigned Role to be Administrator, verify that the Windows AD group is in the list, on the left, under Users and Groups and click OK.
Figure 6
You should now see your new permission in the list.
Now the time has come to test your configuration. Close the vSphere Client and reopen it. Login as a Windows user who is a part of the assigned group (or who you assigned directly, without a group). You can specify their Windows username as either:
- [email protected]
- wiredbraincoffe\sally
Enter the Windows password and you should be able to login to, and administer, the entire virtual infrastructure (based on your assignment of administrator privileges at the highest level of the inventory tree).
Figure 7
If you did want to allow the Windows administrator user to administer the virtual infrastructure, you could add them to this group or even assign the Windows AD domain administrators group administrative privileges (however the security best practices are to use named users instead).
Congratulations, your configuration is done!
