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

 

 

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:

 

 

ldm client exception: Error trying to join AD, error code [42500], user [administrator], domain [ad.fenway.matthewjwhite.com], 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:

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:

HOSTS file looks fine.

There’s the pointer.

…and the domain controller resolving the DNS records.

Lo 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:

http://www.vdsyn.com/unable-add-virtual-center-server-appliance-5-5-windows-2012-r2-ad/

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.

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