How to join vCenter Server to Active Directory

In the How to join ESXi to Active Directory post, I discussed the benefits of adding ESXi to an Active Directory (AD) domain. Similarly, the same benefits and rationale apply when integrating vCenter with Active Directory, a process I’ll be going over in today’s post.

This integration works with both the Windows and appliance version of vCenter Server. In the case of vCenter Server 6.x, what we’re actually adding to AD is the Platform Services Controller component. This holds true irrespective of the PSC being deployed as embedded or stand-alone. The reason for this is that PSC is the component that handles authentication and SSO duties.

Requirements

• A writable domain controller. An AD deployment may include what’s known as a read-only domain controller (RODC). While it is possible to join a PSC or vCenter to a domain with a read-only domain controller (RODC), the scenario is nonetheless unsupported by VMware.
• A fully qualified domain name must be used for vCenter when adding it to AD such as vCenterProd.acme.local. You will not be able to join it if you use an IP address instead.
• Make sure no firewall is restricting vCenter from reaching the domain’s controllers.
• The clocks on all resources must be in sync.
• vCenter must be able to resolve DNS names for the AD domain – and controllers – it is being joined to.
• On vCenter, create a local user account as a member of the SystemConfiguration.Administrators group. Alternatively, use the local [email protected] as per Fig. 1.

Figure 1 – The SystemConfiguration.Administrators local group – Membership is required to join vCenter to AD

Joining vCenter Server to AD

Using the vSphere Web Client, log in as [email protected] or a similarly privileged account.  As per Fig.2, click on the Home menu icon and then click on the System Configuration icon.

Figure 2 – Accessing System Configuration in vSphere Web Client

As per Fig.3, click on Nodes (1) and select the PSC or vCenter Server instance (2) you wish to add to AD. Select the Manage tab (3) and click on Active Directory (5) under Settings (4). Click on the Join (6) button.

Figure 3 – Joining vCenter to Active Directory using the vSphere Web Client

Next, type in the name of the AD domain name using the format shown in Fig.4. Supply a set of credentials with the necessary rights to add a computer to a domain ex. domain administrator. Optionally, you can specify under which OU the computer account for vCenter Server is created. If the Organizational Unit field is left blank, the computer account is created under the default AD container i.e. Computers. You can always move the computer account to another OU of your liking if need be. Press OK to join vCenter to AD.

Figure 4 – Supplying the details required to join an AD domain

You won’t get a notification on whether the domain join process succeeded or not. Instead, you’ll need to reboot vCenter for the change to take root. However, you can have a look at the Computers built-in container using the Active Directory Users and Computers snap-in. You should find a computer account created for the vCenter Server just joined. In this example, I’ve added my test vCSA called vcsa65-a to my test AD domain gojira.local as per Fig.5.

Figure 5 – The AD computer account created for vCenter

Just right-click on the node name and select Reboot.

Figure 6 – Rebooting vCenter Server from vSphere Web Client

When vCenter is back online, the AD domain to which it’s been added should be listed in the Domain field. To remove vCenter from the AD domain, click on the Leave button. You’ll need to reenter the credentials – or similar – used to join it in the first place and reboot it for the change to take effect.

Figure 7 – Verifying that vCenter has successfully joined AD

If all went according to plan, vCenter is now a member of the AD domain. This means that AD security principals – translated AD users and groups – can be used for authentication purposes and to assign permissions on vSphere objects. However, we still need to execute a couple more tasks before we can do this.

Adding an SSO Identity Source

SSO identity sources are the means through which additional authentication domains are added to vCenter. This makes it possible to leverage user accounts and groups from a number of disparate security domains. A domain local to vCenter is always created by default. This domain is called vsphere.local unless you changed it to something else while installing vCenter. The [email protected] account you’re familiar with, is a member of this domain hence the suffix. If you’re using vCenter for Windows, you should also be able to authenticate and set permissions using users and groups local to the Windows server where vCenter is installed.

Likewise, we need to create an SSO identity source for Active Directory before we can use security principles from the AD domain.We can do this as follows.

From vSphere Web Client, click on Home, followed by Administration. As per Fig. 8, select Configuration (1) and click on the Identity Sources tab (2). Click on the Add Identity Source (3) green plus sign. On the Add Identity Source dialog box, select the first option as shown and press Next.

Figure 8 – Adding an AD identity source from vSphere Web Client

The domain name is automatically picked up. Leave the Use Machine account option selected. Alternatively, select the SPN option if you’re planning on renaming vCenter which is something you should avoid doing as it is not supported by VMware. Press Next to continue.

Figure 9 – Configuring an AD identity source

Press Finish to create the SSO identity source.

Figure 10 – Final step in creating an AD identity source

You should now see the new identity source listed as per Fig. 11. You can also set any of the identity sources as the default domain. So for instance, if you prefer to log in with your AD credentials, set the AD identity source as the default domain. Doing this, voids the need to append the domain bit to the username. So, if I wanted to log in with my test AD account, I’d only need to type jasonf instead of [email protected].

 To set an identity source as the default domain, highlight it and hit the Set as Default Domain button.

Figure 11 – Setting an AD identity source as the default domain

With the AD identity source in place, we can now authenticate and set permissions using users and groups from AD. We’re almost there with only one last item we need to take care of.

Global permissions

Global permissions are set on root objects and span across the vSphere hierarchy including integrated products. A user account or group granted this much, will have access to the root object and children falling under it – provided propagation has been enabled – depending on the role assigned.

Consider for instance the vCenter Server object at the top of the inventory hierarchy. By default, the inbuilt local Administrators group has full access to it and, by propagation, to the remaining objects in the inventory as the group is automatically added to the Global Permissions list where it is assigned the Administrator role. You may wish to assign the same to an AD user account or group.

To do so, select Global Permissions (1) from Administration. Select the Manage tab (2) and click on the Add Permission icon (3) as shown in Fig. 12.

Figure 12 – Adding AD resources to the Global Permissions list

On the Add Permission dialog box, click on the Add button. A second dialog box pop-ups. Select the AD domain from the Domain drop-down box followed by the user or group you want added to the Global Permissions list. In this example, I added my AD testing user account. Next, click Add followed by OK to complete the process.

The Check Names button is optionally used to verify any entries typed in as opposed to selecting them from the list. Clicking OK takes you back to the previous dialog box.

Figure 13 – Select the AD resource to add to the Global Permission list

Next, select the role you want assigned to the AD user, or group, just added. The Administrator role is selected by default but you can change this according to the privilege level you want assigned. To have the permissions assigned percolate down to child objects, leave the Propagate to children option ticked on. Disable it otherwise. Press OK to finish.

Figure 14 – Assigning a role to an AD user or group

To verify if the AD user or group has indeed been added to the object’s access list, select the Permissions tab for the vCenter Server object in Navigator. You should see the AD account or group just added, listed. The same applies to viewing the permissions applied on child objects.

Figure 15 – Verifying correct assignment of permissions

I should now be able to log in as [email protected] on vCenter via the vSphere Web Client. This is indeed the case as can be seen in Fig. 16. As previously mentioned, setting the AD identity source as the default domain, voids the need to add the domain bit to the username when typing in the credentials.

Figure 16 – Logging in vCenter using an AD credentials

Conclusion

This concludes this 2 part series on Active Directory integration. The benefits, as discussed, include better user management as well as security hardening both of which are common to ESXi and vCenter Server. All said and done, you can still have vCenter Server participate in AD domain without actually joining it. This older post of mine explores this option. Read the the Single Sign-On (SSO) section to learn more.

[the_ad id=”4738″][the_ad id=”4796″]