One of the neat little features that is included with the 5.5 version of the vSphere is a new identity source option for Single Sign-On (SSO) 5.5. If you think back to the SSO 5.1 options for identity sources, you had three options: Open LDAP, Active Directory (requiring anonymous or user authentication), and Local OS. The new kid on the block with SSO 5.5 is Active Directory Integrated Windows Authentication.
[symple_box color=”green” text_align=”left” width=”100%” float=”none”]
Want to know more about SSO 5.5? Check out my vSphere 5.5 Improvements deep dive series.
[/symple_box]
Authentication to the domain is handled by two options: either using the machine account of the server itself or providing a Service Principal Name (SPN). In this post, I’ll go over both methods in detail.
Machine Account
If you opt for the machine account option, the assumption is made that your SSO server is already joined to the domain. Failure to do so will simply result in an error message stating that “the host is required to join to domain [name] but joined to [something else].”
If you’re doing an all-in-one install of vCenter roles onto a Windows box, you should be in the clear – vCenter has traditionally required that the Windows box be joined to the domain anyway. If you’re using the vCenter Server Appliance (vCSA), which is a SUSE Linux box, you’ll need to make sure you’ve joined the appliance to the domain.
It’s relatively straight forward to join your vCSA to a domain – just navigate to the vCenter Server Appliance admin interface > vCenter Server > Authentication. Enter your details in the boxes below. Reboot if you want to, mine worked without a reboot.
Afterwords, you can just hop on over to the SSO 5.5 Identity Sources and select Active Directory Integrated Windows Authentication, choose Machine Account, make sure your domain name is entered in the “Domain name” box, and click OK. Super simple. 🙂
And here’s the end results:
One of my favorite things about this method? No service account password to worry over. Some shops require password resets even on their service accounts, which is a pain. It also eliminates yet another service account from your change control nightmares. 🙂
Service Principal Name
Alternatively, you can provide the SPN, UPN, and a password. Probably one of the best posts out there that explains the process of creating, viewing, and editing SPNs can be found here: Service Principal Names (SPNs) SetSPN Syntax (Setspn.exe). SPNs are generally accepted as a more secure method of access, as the intended host name that runs the service is included in the SPN.
If you do need to go down this route, make sure to create an SPN on your service account. Here’s the command I ran on my Domain Controller.
setspn -S STS/vcsa55.glacier.local glacier\svc_sso
The format is basically:
setspn -S STS/hostname.domain.local domain\serviceaccount
The results look like this:
Once completed, you can even look up your SPN values for the host and service account using Active Directory Users and Computers (aka A-Duck). You’ll need to turn on Advanced Features in order to see the Attribute Editor in the object properties.
Here’s the SPN for my machine account (which happens to be the vCenter Server Appliance 5.5):
And here’s the SPN for my service account:
And here’s what the Identity Source screen looks like when you configure it for using an SPN:
Thoughts
This is a great new feature, and I’m surprised that I missed it the first few times I deployed 5.5. It’s a very simple way to hook into any trusted domains (one way or two way transitive trusts) that doesn’t require service accounts unless an SPN is required. For those without domain / forest trusts, I’m sure you’re used to the service account song and dance anyway since you’ll need to hook into multiple identity sources anyway. 🙂
