Tag Archives: SSO

DR/BC Site, SSO & AD Authentication

I’m in the midsts of testing DR/BC at the moment with SRM replicating machines down to our BC site. We’ve upgraded everything to 5.1.1a across the board and since moving to SSO we’ve had our fair share of issues. Some we’ve resolved but one particularly important one involved not being able to authenticate with our offsite domain controller at the BC site when we pull the plug on the metro line, isolating that site from the rest of the network.

I was able to login to the offsite VC via the Web Client using my domain credentials absolutely fine but when I logged in as admin@system-domain and changed Identity Source to the offsite DC via the SSO config section then I found that I couldn’t login using domain credentials. The message I received was ‘Authentication Failed’.

I also noticed I had ‘Failed to initialize start-up services’ and a message advising me on installing a vCenter Server system when I logged in. It was apparent that SSO wasn’t installed or authenticating correctly.


So I took a step back and had a think. Initially I’d been following Derek Seaman’s guide to installing SSO and the plethora of SSL certs and when it came to choosing the vCenter Single Sign On Type I had been selecting ‘create the primary node for a new vCenter Single Sign On installtion’. Derek’s advice is as follows:

Even if you don’t want multiple SSO instances now, you may want them in the future. You don’t need to configure additional ones from the outset, so there’s no harm in leaving the door open for future expansion. Thus I selected the second option, as shown below. .


However, after searching for more information and recommendations I came across a post by Duncan Epping over on Yellow Bricks about what his thoughts when it comes to SSO. The phrase ‘KISS’ has never rung truer:

Justin King already mentioned this in his blog series on SSO (part 1234) as a suggestion, but lets drive it home! Although it might seem like it defeats the purpose I would recommend the following in almost every single scenario one can imagine: Basic SSO deployment, local to vCenter Server instance. Really, the KISS principle applies here. (Keep It Simple SSO!)

Now, I am most certainly not any kind of vExpert and I am in no way proclaiming that Derek’s information is incorrect; his guides have been invaluable to me as well as thousands of other vNerds and his blog is a constant source of awesomeness. But, as with most things, YMMV and so it was time give it another go. Armed with this new found knowledge I set about reinstalling SSO one more time and on this attempt I chose the following:


Afterwards I completed the Inventory Service installation, then vCenter and finally the web client. Then the moment of truth: I logged in as admin@system-domain and saw that the offsite VC was now listed in the available systems. Eureka! The next step was to get this VC authenticating with the offsite DC.

At this stage I figured I needed a coffee so I rebooted the DC and VC and went for a refill. When the servers had finished booting I logged back in as admin@system-domain and removed the existing Identity Source and added the new details for the offsite DC. This time I paid special attention to the requirements and used the attribute editor in ADUC to retrieve the correct DN for both the users and groups. I also changed the authentication type to require a username and password and it all went in fine.

So there you have it. Keep it simple!

All that’s left to do now is to pull that plug and make sure I can login when we’ve isolated the BC site. Wish me luck!