Fighting with Windows 2012 R2 Directory Services, NETBIOS naming, vCenter 6.0 SSO on VCSA

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…?)

Screen Shot 2015-03-30 at 5.11.09 PM



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.

Here’s what happened when I tried to add vCenter to AD:

Screen Shot 2015-03-30 at 5.12.16 PMScreen Shot 2015-03-30 at 5.12.29 PM



ldm client exception: Error trying to join AD, error code [42500], user [administrator], domain [], orgUnit [cn=Computers,dc=ad, dc=fenway, dc=matthewjwhite, dc=local]


I suspected that like most Linux/AD integrations, VMware was using likewise-open for this function.

No problem.  When in doubt, drop to the CLI:

Screen Shot 2015-03-31 at 8.55.58 AM

The response is a big, fat, resounding “Error: Lsass Error

The OU format is invalid.”


I suspect that maybe DNS is wrong, as you need both A and PTR records to resolve your vCenter from AD.
Let’s take a look:

Screen Shot 2015-03-31 at 9.02.16 AMHOSTS file looks fine.

Screen Shot 2015-03-31 at 9.02.32 AM

There’s the pointer.

Screen Shot 2015-03-31 at 9.02.59 AM …and the domain controller resolving the DNS records.

Screen Shot 2015-03-31 at 9.03.47 AMLo and behold, it even created the CN object for VCENTER!

(Several reboots later, no changes.)

Well, who needs enemies when google is your friend, so I eventually come across this:

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:

Screen Shot 2015-03-31 at 9.05.10 AMSure enough, the NETBIOS naming convention is in fact, all lowercase.  That REALLY can’t be it, can it?

Screen Shot 2015-03-31 at 9.06.19 AM

We make it UPPERCASE

Screen Shot 2015-03-31 at 9.08.14 AM Verifying that the file is updated, we run “rendom /upload” and “rendom /prepare”
It seems to like that.

Screen Shot 2015-03-31 at 9.08.35 AM Finally, “rendom /execute” is run to commit the changes to the DS.

Screen Shot 2015-03-31 at 9.08.49 AMAs an added bonus, the domain controller restarts without warning.  (Told you not to do this in production.)

Screen Shot 2015-03-31 at 9.18.01 AMAfter 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.

Screen Shot 2015-03-31 at 9.20.00 AM

(It works!)

Screen Shot 2015-03-31 at 9.22.18 AM REBOOT!

Screen Shot 2015-03-31 at 9.32.54 AM Screen Shot 2015-03-31 at 9.39.30 AM Screen Shot 2015-03-31 at 10.02.58 AM

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 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.

Hope this helps someone, it was a frustrating hour or two.

6 thoughts on “Fighting with Windows 2012 R2 Directory Services, NETBIOS naming, vCenter 6.0 SSO on VCSA

  1. 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!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s