VMware vCenter Server and Active Directory

Integrating VMware vCenter Server with Microsoft Active Directory has always been a requirement for enterprise deployments of VMware vSphere.

Before SSO,

In VMware vCenter 5.0 and prior, the Windows Server (VM or physical) where vCenter was installed was required to be a member-server of an Active Directory domain. In those days all Administrators of the AD Domain would be automatically made Administrators of vCenter as well.

While this may not impress users of some environments as a problem; many other users will recognize the inherent conflict where AD Administrators should not be authorized for vSphere and vSphere Administrators are not authorized for AD. Moreover, in larger environments, delegation of AD was often not extended to the Organizational Units charged with deploying vSphere, and sometimes vSphere projects could be derailed for hours or days while Change Management requests were processed and implemented by external AD managers!

After SSO worked

First effectively implemented in vSphere 5.5[1], VMware made vCenter a subset of a user-directory known as Single Sign on (SSO), which is actually an independent implementation of MIT Kerberos. With SSO, it did not make a difference if the server where vCenter was installed was a member-server of an Active Directory domain or not! And even if the server where you installed vCenter was joined to an AD Domain, all that would apply to was the Operating System. With SSO, after installing vCenter, the initial user account and only viable permission was almost always: administrator@vsphere.local.

vCenter 6 and Active Directory

Fortunately, VMware didn’t forget about Active Directory, they merely changed the way vCenter interacts with it. With vCenter and SSO, one simply has to add Active Directory as an Identity Source to their vCenter SSO configuration and then create a Global Permission to allow a user or group to log-in to vCenter. It’s actually quite simple and has many advantages:

  • vCenter is no longer a subset of a single AD Domain; rather it becomes a superset that can encompass many domains
  • vCenter no longer requires AD at all
  • AD Domain Admins no longer have implicit Administrator rights on vCenter
  • Change Management exists only within the VMware team and is not dependent on external requests to managed AD

In reality, there are two ways to go about adding an AD domain as Identity source to your vCenter Server SSO configuration, regardless of your deployment model.

  1. Using Active Directory as an LDAP Server
  2. Joining the server which hosts vCenter (either a Windows Server or the VCSA) to the domain and then using the Machine Account to authenticate against the domain.

I vastly prefer using AD as a LDAP Identity source with vCenter because it is simpler! Using AD LDAP makes vCenter and SSO much less dependent on AD overall, while not compromising functionality! I can relate just one example from the recent past:

A domain-joined (Windows) vCenter that I mange presented one day with Active Directory trust issues (due to reconfiguration of the domain outside of my control), rendering all domain accounts useless on vCenter and only the user: administrator@vsphere.local viable. By the time I had taken the necessary steps to resolve the trust issues, the vCenter database was fried and I had to resort to restoring vCenter from backup.

Rather than do a full restore, which might also present with AD trust issues, I restored the vCenter Database to a new VM with a fresh installation of vCenter. This time around, instead of using the Machine Account to add the Domain as an Identity Source, I used AD LDAP!


You should have existing Users, or better yet Security Groups, created on the AD domain you want to use as an Identity Source with vCenter SSO. I have created three Security Groups and four users in AD:

Group Name Role Members
ESX Admins Users who should have root access to ESXi Hosts John, Tom
vCenter Admins Users who should have full administrative access to vCenter John, Tom, Dick
vCenter Users Users who should have limited access to vCenter Harry

Getting Started

To begin, you will need to log-on to your vCenter Server using the dreaded vSphere Web Client. At this point, it does not matter if the vCenter is a VCSA or a Windows-based vCenter. The initial username will be administrator@vsphere.local (for vCenter 5.5) or administrator@ssodomain.tld (whatever you specified) during the install for vCenter 6.

I specified jb-lab.sso as my SSO domain during install, therefore my login will be: administrator@jb-lab.sso

You will (eventually) get to the Home screen of your vSphere Web Client.

Using Active Directory as an LDAP Server

Adding an Identity source to vCenter using Active as an LDAP Server

Using AD LDAP as an Identity Source is much simpler than using Integrated Windows Authentication (the Machine Account), primarily because it does not require a reboot of the vCenter!

The procedure for using AD LDAP as an Identity Source is the same for both the VCSA and Windows vCenter!

First, go to: Administration (link on the left)

Then to: Configuration

And then choose the tab: Identity Sources

Now, click on the little plus symbol to add an Identity Source and choose: Active Directory as an LDAP Server and fill-in the information as follows, replacing my lab information with your information, of course!

Field Value (for jb-lab.local) Definition
Identity source type Active Directory as an LDAP Server What directory to use as an Identity source
Name jb-lab.local Name of Identity source
Base DN for users dc=jb-lab,dc=local Distinguished Name where we should look for Users
Domain Name jb-lab.local Domain Name
Base DN for Groups dc=jb-lab,dc=local Distinguished Name where we should look for Groups
Primary server URL Your PDC, probably
Secondary server URL Another DC
Username jb-lab\administrator A user entitled to enumerate the domain
Password Your Password Your Password


Once the form is filled out, choose: Test Connection

Click: OK in the window that says “The connection has been established….” and then OK again in the Add Identity Source window. You should see the following:

That’s it! Your domain has now been added as an identity source and you could go on and create a Global Permissions for vCenter!

Using Active Directory (Integrated Windows Authentication)

To use AD (Integrated Windows Authentication) requires we first join our vCenter OS to the domain. This can be done with either the Windows installable version of vCenter or the VCSA. We’ll show you how to join the VMware vCenter Server Appliance 6 to an AD Domain

Join VCSA to a Domain

We’ll presume a default configuration with no other Identity Sources added.

And we will go to: Administration > Deployment > System Configuration

And then choose: Nodes and highlight your vCenter Server

Now choose the tab: Manage and then the option: Active Directory and then: Join

Now enter your AD Domain and credentials.

NOTE: I have trouble here using DOMAIN\user credentials. Try using UPN formatted credentials when joining VCSA to an AD Domain.

There is no affirmative feedback upon success. All you will see is an essentially blank screen (next screenshot), however the lack of errors is actually a good sign.

NOTE: The Gotcha here is the fact that there is no affirmative feedback. I think it is very likely that many users that have attempted this to join VCSA to a domain were, in fact, successful without even realizing it.

Now restart the vCenter: Actions > Reboot

Blah, blah

And wait a maddeningly long time for the Web Client to become available again.

After the reboot, you will see this for a long time, even after the VCSA has rebooted

Now log back in to the Web Client. We may have joined the domain, but we have yet to add the Domain as Identity Source, so you must continue to use the SSO administrator account.

If you return to the: Administration > System Configuration > Nodes and then highlight your vCenter and Active Directory, you should be able to confirm you have joined the Domain successfully.

Adding an Identity source using Active Directory (Integrated Windows Authentication)

The following steps are the same for both the VCSA and Windows vCenter, so long as they are both member-servers of the AD Domain.

Go to: Administration > Configuration and select the tab: Identity Sources

Click the plus symbol and choose: Active Directory (Integrated Windows Authentication) and choose: Use machine account, then click: OK

You should see the Domain added as an Identity source!

Global Permissions for vSphere

Now that we have added an Identity Source, we need to create at least one Global Permission to log-in with an AD user account.

The following steps are the same for all forms of vCenter (VCSA and Windows) and all types of Identity Source.

Go to: Administration > Global Permissions > Manage and click on the: Plus

Now click: Add

Now select the: Domain (top-left corner) and choose the User or Group you would like to associate with the Role, and then click: Add and then: OK

Make sure the User or Group you chose is assigned the correct Role (in this case: Administrator) and click: OK

Now logout and test your work

When you try to log back in, use a user account that is a member of the AD Domain

NOTE: I find UPN formatted usernames are much more reliable in vSphere 6

Here is what you should get. Note: The user john@jb-lab.local is not an Administrator of Active Directory, but is a vCenter administrator!


  1. There was an abortive attempt to deploy SSO for vSphere 5.1 that was never fully functional or secure

About: John Borhek

John Borhek is the CEO and Lead Solutions Architect at VMsources Group Inc. John has soup-to-nuts experience in Mission Critical Infrastructure, specializing in hyper-convergence and Cloud Computing, engaging with organizations all over the United States and throughout the Americas.

15 thoughts on “VMware vCenter Server and Active Directory”

  1. I have the issue in Client Integration Plugin. Windows session authentication is grayed out in vmware web client(IE browser). Can you assist me pls ?

  2. Thanks for this post. It seemed easy enough to accomplish, but having the walkthrough as a guide helped.

    Is there any functional difference between the 2 ways to do Active Directory lookups? It seems like 2 paths to achieve the same results (I went with the LDAP route).

    In any case, thanks for the write up and the clear screenshots. A picture says a thousand words and all that. Aloha 🙂

    1. I am leaning toward AD LDAP. In one instance I had to re-build, the trust relationship for the domain on vCenter had failed, subsequently causing database corruption. When you use AD LDAP, there is no trust relationship to be broken.

  3. Couple of questions.
    1) When I do a AD-LDAP identity source and the remote AD is the root domain of a forest. Will it leverage the global catalog of the root domain and find users across the forest or do I need to add each domain of the forest via a separate LDAP-AD connection?
    2) Is it possible also to use ldaps URL instead of ldap for LDAP-AD (or is Vmware might using STARTTLS for ldap)?

    1. You can use ldaps as well. I honestly don’t know if SSO will enumerate the entire domain, or just the root. Try it and let me know!

  4. Couple of questions from my side,
    1. I have a 3rd party web-plugin and plugin is only visible to the AD group “Domain Users” and Not able to other AD group user like “DEV” and “QA”

    2. Also for AD group “Domain Users” i gave different permission and i don’t see the appropriate role are set for the group users

    Note: I am using VCSA 6.0 and added AD as LDAP and set to default identity.

  5. Thanks for the helpful post. I have a situation i want to share and see what your thought(s) are on this.
    I have a security group that had limited access (VM Power USER Role) in vCenter. But two users in this group of about 15 users are all of a suddent unable to login to vCenter. FYI we use AD integrated windows authentication for login and its vcenter 5.5


  6. This post was exactly what I was looking for, so thank you! My project wants to implement “Active Directory as an LDAP Server” and bring in AD security groups, like you did with your vCenter Admins group, rather than individual users, but I’ve run into an error.

    I think I did everything right, but the logins do not work. I login in with, say, joe.vcenteradmin@my.domain, who is a member the vCenter Admins AD group, and get “authentication failed”. However, if I add just the AD user joe.vcenteradmin to the Administrators group in VCSA it works fine. Is it possible I missed a step?

    1. You might have to provide more detail.
      1. Add Identity source to vCenter using AD-LDAP
      2. Create a “Permission” associating the AD Group “vCenter Admins” with the vCenter Role “Administrator” in vCenter
      3. add “Joe” to the AD group “vCenter Admins”
      4. Log in as: joe@my.domain

Leave a Reply

Your email address will not be published. Required fields are marked *