I’ve been playing with my new toy that is vCenter 6 for a while now, and decided it was time to actually implement single sign-on, linked to my Windows 2012 R2 Active Directory testbed. Given my propensity to come across “weird things,” what followed certainly didn’t surprise me.

(So… this is all easy, right…?)

This should all be fairly commonplace although it’s a little different with vCenter 6; you are able to change and register services from within the web UI, rather than the old-style [https://vcenter:5480] appliance configuration.

So let’s ask our good friend RENDOM to take a look, and just maybe we may be on our way to solving this. You can read more about RENDOM here.

[DISCLAIMER: Performing this in production, especially with ancillary Microsoft services running (Exchange, SQL, etc..) apparently has the potential to break things, cause issues, take away your birthday, and so on, so don’t blame me for those 800 missing Facebook posts.]

On the Windows 2012 R2 domain controller, we’re going to list the DS object naming conventions with “rendom /list” and opening the Domainlist.xml file that it creates:

Sure enough, the NETBIOS naming convention is in fact, all lowercase. That REALLY can’t be it, can it?

We make it UPPERCASE

Verifying that the file is updated, we run “rendom /upload” and “rendom /prepare”
It seems to like that.

Finally, “rendom /execute” is run to commit the changes to the DS.

As an added bonus, the domain controller restarts without warning. (Told you not to do this in production.)

After logging in after the restart, we run “rendom /clean” to keep things tidy, and create the xml files again to verify. Like my grandmother’s emails, FENWAY is in ALL CAPS.

We are successfully able join the domain from the vCenter CLI, and Skynet is one step closer to ruling the world.

(It works!)

REBOOT!

Reboot the vCenter appliance to see the AD context in the WebGui and/or run domainjoin-cli query to prove that we’ve gotten this to work. You can now happily add AD as an identity and the promise of SSO is alive and well.

So why didn’t this work to begin with? After a few convenient snapshot restores to pre-dcpromo status, I remember that I did change the NETBIOS name for ad.fenway.matthewjwhite.com from “AD” to “fenway” when I should have made it “FENWAY”. However, Windows should have automatically changed it to uppercase, as lowercase naming for NETBIOS has been disallowed since Server 2008.

We’ll claim comparative negligence for both likewise-open and Windows 2012 R2 AD services on this one, as I really should have just kept my CAPS LOCK ON.

Wanted to let you know that this post solved the same issue I had with VCSA. What a pain in the ass! Had I not run across this blog I would have given up attempting to integrate AD with VCSA. Thanks man!