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!

Prerequisites

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:

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!

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 ↑