Last week a colleague of mines was setting up a new vSphere 6.0 environment which contained a vCenter Server with an external Platform Services Controller (PSC) for our Management vSphere Cluster and another vCenter Server also with an external PSC for our Compute vSphere Cluster. The PSC's were configured to replicate with each other which meant they were part of the same SSO Domain providing us with the new Enhanced Linked Mode (ELM) feature that was introduced in vSphere 6.0.
With ELM, you can now easily view all of your vCenter Servers by logging into either of the vSphere Web Client Servers provided by any of the vCenter Servers that are connected to the replicated PSCs. In addition to providing a single view into your vSphere environment, data such as Licensing, Tags, VM Storage Policies, Roles/Permissions & Affinity/Anti-Affinity Rules to name a few are also replicated and made available to all the other vCenter Servers.
As part of the initial setup, my colleague had joined the first PSC (psc-01) to our Active Directory domain after completing the deployment of the VCSA, as the vSphere Web Client was required to make further changes to the PSC. The question that my colleague had was whether or not additional PSC nodes were required to be joined to the same Active Directory domain or would it automatically be handled by the PSC replication?
This was actually a great question and in fact something that could easily be overlooked or at least until you try to login using an Active Directory account and can not. What you will notice when going to the SSO Admin Configuration screen is that the Active Directory Identity Source has been added, so I can see why one would assume this would automatically be handled. If we take a closer look at my home lab environment and the Active Directory configuration within each of the PSC, we will see why this not the case.
If we take a look at the Active Directory configuration for psc-01, we can see that it is part of our AD Domain and the "Join" option is grayed out.
If we now take a look at psc-02, you will see that the Active Directory configuration is empty and the option to "Join" is still available.
To resolve this problem, you just need to add the additional PSC nodes to Active Directory and then reboot for the changes to go into affect. The PSC's also support different Active Directory domains as long as a trust relationship exists between the two, for more details take a look at this VMware KB 2064250. It should also be noted that this should not be an issue for those deploying a Windows based vCenter Server since it is usually a best practice to joined the Windows system to an AD Domain prior to installing additional software on top.
What is the primary advantage to joining PSC's to AD vs. using the LDAP option into AD in this type of setup. The "Use Windows authentication" option is the only real benefit I can think of, but the Google Chrome browser will not support it anyways due to recent policy changes. Thoughts?
"Use Windows Auth" is one of the benefits but the other is that the Machine Account will be used to perform all the "magic" as my buddy in GSS mentioned and details can be found here http://kb.vmware.com/kb/2064250 else a simple bind is used, which has problems with recursions.
BTW - Windows Auth works fine on Chrome, not sure which policy change but haven't had issues with latest version
Curious on external PSC deployment. If I have a PSC in US and one in SEA, should each have their own PSC independent join them together? Is there a recommended latency threshold that should be observed?
We are having a lot of problems with our 3 external PSC's in Germany, Singapour and the US and enhanced linked mode. Latency is 100ms to th US and 200ms to Singapour. The Web Client is sluggish (even sluggisher as it is usually) and the client crashes regularly. Not sure about the max. supported latency, but I think I heard something like 100ms. I need to find out how I can migrate this single SSO domain with sites to 3 separate SSO domains now.