Before I get into this, I need to set it up.
NOTE: Be prepared to reboot the VCSA a couple times… it takes forever for the web-client to initialize and seriously, that needs to stop VMware. Sub 20 second Web-Client Initialization… NEEDS to be in the next release. I think I speak for everyone when I say that the Web-Client is initializing page is old and needs to die. Anywho. back to the fixing.
We have our active directory domains and our DNS domains. They aren’t the same. We are using alias’s, as support loved to keep saying (I didn’t set it up but sure!)
Our active directory domains are as follows (assuming I work for Acme):
- Root Domain: ad.acme.com
- Child Domain 1: site1.ad.acme.com
- Child Domain 1: site2.ad.acme.com
- Child Domain 1: site3.ad.acme.com
- etc….
Our root domain structure is setup something like this:
Now this is just the domain structure. The DNS structure is slightly different. Below is the DNS structure:
- Root domain: acme.com
- Subdomain 1: site1.acme.com
- Subdomain 2: site2.acme.com
- Subdomain 3: site3.acme.com
- etc…
All of the vCenter servers deployed (still on 5.5 VCSA) use the hostname structure of vcenter.site{x}.acme.com. Because we use aliases for our hostnames and AD structure, we are having a little bit of trouble getting them to authenticate. Part of the problem is that when adding the VCSA 6 to the AD Domain, it changes the hostname of the VCSA in the /etc/hosts file and in the computer account that is registered in AD.
Lets review. I have vcenter.site1.acme.com in DNS and in the VCSA. I attempt to register it with the local child domain controller: site1.ad.acme.net. When I register the VCSA, it changes the hostname to vcenter.site1.ad.acme.com. So now the hostname in DNS and in the /etc/hosts file doesn’t match the certificates and what the embedded services are looking for when connecting between each other.
The result is that when you login with an AD account, you get what is described in my other post here: Client is not authenticated to Inventory Service.
So as I sat on a support call with VMware, and we worked out issues with vSphere 6 and working with AD in the environment, we were told that it wouldn’t work. The literal words were, “it will never be supported”. Beyond the method of delivery and the tone of the engineer on the phone (which as a previous customer service technician I did not agree with). His statement was pretty straight to the point. No, not going to work. Change all of the vCenters from using their previous and correct DNS entries, to the site{x}.ad.acme.com domains.
The other issue we ran into was instead of registering the vCenter servers to the local child domains, how about to the root domain? Well, because the hostname in the VAMI shows up as just “vcenter”, when we added the second VCSA to the domain, it would attempt to use the same computer account.
I made a post here: Active Directory VCSA and Hostnames being Changed Automatically. So here is how the troubleshooting went.
When we added multiple VCSA’s to the same root domain controller, it would cause the second one to overwrite the same computer account and break the first VCSA’s ability to authenticate. Not cool VMware. OK, so we joined the VCSA’s to the child domains, which means the computer accounts look the same, but they are tied to separate lower level domains on the same tree. So each would join their local domains to prevent the “AD Conflict”. But this caused Inventory service not to work and show “Client no authenticating to Inventory Service” which I wrote up.
So taking both experiences into consideration. I needed to add the server to the role domain to get it to work, BUT I also needed to prevent them from using the same computer account. Well, by preventing the domain controller from changing the hostname of the VCSA, it created unique identifiers!
Now I just had to add the identity source to each VCSA, and that was done by adding the integrated Windows Authentication for Active Directory.
All good! Now to just do it 3 more times… oh boy.