Knowledge Base

Introduction to Multisite Single Sign On Deployments

The vCenter Single Sign On multisite configuration is designed for deployments with multiple physical locations. Installing a Single Sign On instance at each site allows fast access to local authentication-related services. Each Single Sign On instance is connected to the local instances of the AD (LDAP) servers and has its own database with local users and groups.

Multisite deployment is useful when a single administrator needs to administer vCenter Server instances that are deployed on geographically dispersed sites. To view all vCenter Server instances from a single vSphere Client, you must configure the vCenter Server instances in Linked Mode.

Note: Multisite Single Sign On deployment is designed only for faster local access to authentication-related services. It does not provide failover between Single Sign On servers on different sites. When the Single Sign On instance on one site fails, its role is not taken over by a peer Single Sign On instance on another site. All authentication requests on the failed site will fail, even if peer sites are fully functional.

In multisite Single sign On deployments, each site is represented by one Single Sign On instance: one Single Sign On server, or a high-availability cluster. The Single Sign On site entry point is the machine that other sites communicate with. This is the only machine that needs to be visible from the other sites. In a clustered deployment, the entry point of the site is the machine where the load balancer is installed.

Planning a Single Sign On Deployment

Before you install Single Sign On, consider carefully the future requirements for the deployment to determine whether a multisite or high-availability deployment is appropriate. If you install a Single Sign On instances in basic mode, you cannot later promote the instance to a multisite node.

Order of Installation for Single Sign On Instances

You can install the Single Sign On nodes in a multisite deployment in any order. The Single Sign On installer uses the terms primary and secondary only to distinguish between the node that is installed first and any node that is installed later and points to a previously installed node. Any node that is installed after the primary node can point to any node that is already installed. For example, the third node can point to either the first or second node.

For example, let's consider a corporation MyCompany, with offices in San Francisco, New York, and London. The New York site is the headquarters and connects with both the London and San Francisco sites. The London and San Francisco sites do not connect with each other. The MyCompany multisite Single Sign On deployment would proceed in the following steps.

1. The administrators in London set up the first Single Sign On instance.
2. The New York IT team sets up the second Single Sign On instance, pointing it to the London instance.
3. The San Francisco IT team sets up the third Single Sign On instance, pointing it to the New York instance.

Connectivity Between Single Sign On Instances and Between Single Sign On Instances and Other vSphere Components

After you install Single Sign On, no connectivity between the Single Sign On servers is necessary, because there is no automatic replication of data between Single Sign On instances.

There are no components in the vSphere suite that communicate with multiple Single Sign On servers. Each vSphere component should be configured to communicate with its local Single Sign On instance for faster access.

Single Sign On and Active Directory

If you use Active Directory in your infrastructure and you want the Single Sign On server to add Active Directory automatically as a Single Sign On identity source, you must install Single Sign On on a machine joined to the Active Directory domain. In this case, all machines on which Single Sign On servers will be installed must be joined to the same domain. The domain controllers might be different, but the Single Sign On server will discover and add the local one.

Single Sign On and vCenter Server Linked Mode

You can join vCenter Server instances in Linked Mode only when all of the instances are registered in the same Single Sign On deployment. This includes Single Sign On instances installed on different sites. When vCenter Server B on site B is joined to vCenter Server A on site A, the join tool establishes connection both to Single Sign On A and Single Sign On B.

Replicating Data Between Single Sign On Sites

Automatic replication of data between Single Sign On Sites is not supported. Whenever you make a change to one of the Single Sign On instances, you must perform a manual data export and import operation with a command-line tool. The data to replicate includes local users and groups and the configuration of the STS server. Because this data rarely changes, you can schedule replications once a day or week, as appropriate. For information about manually replicating data between servers in a multisite Single Sign On deployment, see Manually Replicate Data in a Multisite vCenter Single Sign-On Deployment section in the vSphere Security Guide.

The sites work in a disconnected state, unaware of each others' execution and progress. When you import data on a Single Sign On server, its entire current state is overridden, so you lose all changes that were made since the last propagation.

CAUTION: To ensure that data remains in sync during the manual replication process, do not make any changes to the data to be replicated, for example adding or deleting identity sources or local users.

For example, let's look again at MyCompany. After Single Sign On is set up, the MYCompany IT team starts configuring their vCenter Server instances: first in San Francisco, then in London, and last in New York. During each vCenter Server installation, an application user is created for the vCenter Server instance. The correct deployment sequence takes the following steps:

1. Install vCenter Server in San Francisco.
2. Export the San Francisco data and import it to the London site.
3. Install vCenter Server in London.
4. Export the London data and import it to the New York site.
5. Install vCenter Server in New York.
6. Export the New York data and import it both in London and San Francisco

Note that these steps represent an accumulative change replication. Changes to one node are transported only to the node where the next changes will occur. After the last planned change is done, changes have been propagated to all nodes.

Alternatively, you can execute the replication sequentially. After a change in one node occurs, replicate it to all other nodes before making a change on any other node. During setup of the virtual infrastructure on each site, the better practice is to use the accumulative approach, which needs fewer steps, as the changes are planned and executed in a relatively short time span. For regular, ongoing operations, use the sequential approach.