When VMware released vSphere 5.1 they also rolled out Single Sign-On (SSO) which is a mandatory installation along with vCenter 5.1. The idea of SSO was to allow users login with the same credentials to other VMware products and vSphere sites. It sounded like a great idea theoretically, but unfortunately the execution left a lot to be desired. The original 5.1 SSO product was basically an RSA product that used a SQL database. If you did the “Simple” install it installed everything for you. If you wanted to put it on a separate database (as described here) things got a bit more difficult. If you actually wanted to use SSO as intended that was even more difficult.
VMware listened to all of the complaints about SSO, and there were many, and did something about it with their most recent release of vCenter. They completely rewrote the product in-house, as described on the VMware Communities Roundtable Podcast (http://www.talkshoe.com/talkshoe/web/audioPop.jsp?episodeId=790682&cmd=apop) recently. According to the podcast, they were working on a future product and decided to apply it to SSO and fast track it to be released with 5.5.
I’ve gotten to install vSphere 5.5 a few times now and I have to say from an install point of view that it’s just way better than the previous version. I believe one of the reasons it’s easier and more intuitive to install is that it actually uses Active Directory. In the 5.1 version you had to use LDAP to connect. It was supposed to populate this information if you were logged on as a Domain Admin, but that rarely worked for me. Then you had to figure out all of the LDAP information and populate it manually. Now, with the new version, even if you don’t populate this information automatically you can just choose to connect to AD and put in a username and password.
The installation process
Let’s go through the install of SSO so you can get a better idea of how that’s changed. The install of SSO is still a part of the vCenter 5.5 installation. You can choose to either do the Simple Install which installs SSO, vCenter Inventory Service, and vCenter itself or you can do them separately. For this example I’ll only be doing the separate SSO install. Note that you can upgrade from 5.1 (and 4.0, 4.1 as well) even though SSO has been completely rewritten.
The SSO Install:
- Download the vCenter ISO from VMware.com and attach it to your vCenter. Start the install.
- On the vCenter installer screen highlight vCenter Single Sign On and click the Install button.
- Click Next through the first screen and the EULA.
- The next screen will show that it does a quick check to see if you’re installing on a server that’s joined to the domain and that DNS resolution was successful. If you get green checkmarks on both those, you’re good to press Next.
- The next screen gives you three options as shown below:
If this is your only vCenter or your first vCenter for the environment you’ll want to choose the first option, even if you’re upgrading your server and SSO is already present. Choose the second option if you are installing this in the same site, but this is not the first vCenter you’re installing it on. Choose the third option if you’re creating a new site, but it’s in an existing domain. For the purposes of this example we’ll choose the first option and click Next.
- The next screen in the wizard asks for our SSO credentials. In 5.1 this was a little different. The admin@System-Domain username no longer exists. It’s now [email protected] as you can see in the screen shot below. Enter a password here and make sure you record it somewhere you can find it in case you ever need to restore vCenter as well as for the rest of the vCenter install. Then click Next.
- On the next screen enter a name for your site. You can leave the default site name or pick a new one. This is somewhat arbitrary, you need only pick a name that makes sense for your environment.
- On the next screen you can pick a port, most likely you’ll want to leave it as the default. Click Next.
- Then pick an install path, which I generally leave as default unless someone would like to specify an application drive or something instead. Click Next.
- Review your settings and then click Install.
Again, notice there’s no external database to install or credentials to specify other than the SSO Administrator password. Instead the storage to maintain credentials is built-in to the SSO architecture itself. In version 5.1 VMware suggested installing the SSO, Inventory Service, and vCenter on different servers to alleviate overloading the server. However, VMware is no longer suggesting that. They’re now saying it should all be installed on the same server unless it’s absolutely necessary (i.e. your environment is really large). This is really nice because in order for everything to work properly (and be a supported configuration from VMware all of the components needed to be on the same version so you had to remember to upgrade all three. Now we can easily upgrade all of the components on a single server.
The web client
Let’s take a look at what you see in the vSphere Web Client in the new version now. If we log into the web client then click on Administration there is a Single Sign-On category on the left. Under it we have Users and Groups as well as Configuration. If we click on Configuration there are three tabs to click on: Policies, Identity Sources, and Certificates. Under the Policies tab we have Password Policies, Lockout Policies, and Token Policies which are editable.
If we click on Identity Sources we can see the sources, such as our Domain, where we can add Identity Sources. As mentioned above, this is much easier now that we aren’t limited to LDAP for Active Directory integration. When you click the + sign you’ll see the following pop-up appear.
Here we can specify a domain name and then either use a machine account or specify a service account, for example, to sync Active Directory.
Specifying Users and Groups to give access to is pretty similar to the previous version. We just need to click on Users and Groups, select the Identity Source (i.e. our domain) and then add users or groups that should have access and what kind of access they should get.
Something else of note is that SSO 5.5 can support vCenter 5.1. While SSO 5.1 was limited to only SSO configurations they have made it possible to use SSO 5.5 to be backwards compatible. So, while you can use SSO 5.5, if you’re running a stable version of 5.1 this probably doesn’t help you. However, if you have a multi-site environment and you can’t upgrade everything at once, 5.5 will work for everything. For more information on architecture for multiple versions please see Chris Wahl’s blog here.
The new version of SSO is very impressive, though may be still lacking certain things like 3rd party integration that some security administrators would like to see. It’s definitely a step in the right direction though and hopefully it’s only a matter of time before even more improvements like this are made.