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


  • 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

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

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

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

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

Figure 5 – The AD computer account created for vCenter

 

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

Figure 6 - Rebooting vCenter Server for vSphere Web Client

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

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

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

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

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

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

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

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

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

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

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″]

Altaro VM Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

19 thoughts on "How to join vCenter Server to Active Directory"

  • Adnan says:

    Thank you for your good article.
    I have joined vcenter to my AD successfully. But When I go to global permission and choose domain for adding users , I get below error:
    Cannot load the users for the selected domain.

  • Klaus says:

    Is there any chance for moving the VCSA to a new AD domain if it’s installed with a FQDN, joined that domain and has this AD domain added as an SSO domain?

    Current situation:
    VCSA as vcenter.domain.tld should be moved to a new AD domain as vcenter.newdomain.newtld. So the first part, the machine name, will stay, but the domain part will change.

    • Jason Fenech says:

      Hi,

      As far as I know this is not supported and I would not recommend it either. Best if you install a new vCSA in the new domain and moved the hosts to it assuming you’re env isn’t that complex. If not, I suggest opening a support ticket with VMware.

      regards

      Jason

  • Tobias Heyl says:

    Hi Jason, regarding the point “You won’t get a notification on whether the domain join process succeeded or not” I would like to let you know that in fact I selected the wrong domain (I selected a sub-domain instead of the root domain) this morning and thus got an error message. Took 20 seconds or so and I have been notified that the domain could not be added.

  • Erick says:

    Hi, could I move the vcenter appliance to another OU once is inside the domain? Now is in computers OU but i need to move it to another OU.
    Thanks!

  • rajinikanth buyyan says:

    hi is it mandatory to install the Vcenter server in domain environment.

    I tired installing the Vcenter server in workgroup we are unable to join the Domain geeting error unable to troubleshoot.

  • Brian Town says:

    Tried installing AD domain on VSCA 6.7, joins just fine, and I can add people so it’s doing proper ldapsearches however I get invalid credentials at the login page. No idea why this is happening. DNS is set properly and the VSCA and AD are both on same network so no FW stopping anything…

  • juno says:

    You sir, just saved me from another 48 hours of hell. Our v center went bonkers a few days ago causing endless issues (sysvol full, log folder full). It also managed to ditch itself from our local domain. Your article has meant I can get everything working again! (also killed veeam as it uses an AD login)

  • Robby says:

    I’m having problems to add an identity source with a number in it. (Figure 9)
    instead of domain.local, we actually have one of the old names: domain.w2k
    If I leave the 2 our of the domain name, the next button enables, but the moment I type a number in the domain name, the next button is greyed out.
    Anything that I can do to solve this?

    • Luke Orellana says:

      Hey Robby,

      That’s definitely a limitation with VCenter’s ad domain join wizard. Try switching to the other vSphere client. So if your using html5 use the original web client or vice versa. I’ve tested and confirmed this has been fixed in version 6.7.

  • rajinikanth buyyan says:

    Thanks for the update.
    But while joining the Vcenter to AD were are getting the error

    • Luke Orellana says:

      Can you confirm networking between the VCenter server and the domain controller? Check DNS, firewall rules, ping.

Leave a comment

Your email address will not be published.