The SSO, introduced in vSphere 5.1, is the authentication broker of a vSphere environment.

Using a secure token mechanism, different vSphere components can communicate with each other. Both the internal components and the vSphere users are authenticated with SSO, with its different identify sources (different authentication domains, as described in Objective 1.1).

For more information about authentication, see the PSC 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-B98DF9C2-FE7D-483F-9521-C17C138B59D8.html).

From vSphere 6.0, the vCenter components are grouped into two separated roles, as follows:

• The vCenter Server: Also called the management node, used to provide specific vCenter-related services.
• The Platform Services Controller: Also called the infrastructure controller, used to provide common infrastructure services for different VMware products:

Each role groups different types of services and functions, according to the following table:

Both components can be based on a Windows Server OS (installable version), or in a virtual appliance form (VCSA). For version 6.5, mixed environments are supported (in the future, it is likely that only the VCSA will be supported).

The PSC is an important component in the design, providing services not only for vCenter Server and vSphere, but for the VMware products in general. SSO, for example, can be shared with other VMware products (for example, vRealize Orchestrator and vRealize Automation), to provide a centralized user authentication.

The main core services provided by the PSC discussed in this objective are:

• SSO: Solves the problem of mutual authentication between different components, and also the authentication in an environment with different identity sources (this will be described later). The SSO provides an internal authentication domain; in vSphere 5.5, the default name was vsphere.local. With vSphere 6.0 and later, you can choose the name of the SSO domain.
• Certificate management: Also called VMware Certificate Authority (VMCA), it manages digital certificates, and can act as a Certification Authority (CA).

Depending on your environment and infrastructure design, the vCenter Server and PSC roles can be deployed in two different ways:

• Embedded: The same machine has both vCenter Server and PSC. This deployment model supports a good scaling in terms of hosts or VMs, like an external deployment (with a single vCenter), but does not provide enhanced linked mode (unless using vSphere 6.5, Update 2). Note that vCenter High Availability is supported for embedded deployments in vSphere 6.5.
• External: The vCenter Server and PSC roles are on different machines. This is the only configuration that supports complex topology.

The following table summarizes the pros and cons of each deployment model:

VMware recommends six high-level PSC topologies, as follows:

• vCenter Server with embedded PSC
• vCenter Server with external PSC
• PSC in replicated configuration
• PSC in HA configuration
• vCenter Server deployment across sites
• vCenter Server deployment across sites, with load balancer

For more information, see KB 2147672 (https://kb.vmware.com/s/article/2147672)—Supported and deprecated topologies for VMware vSphere 6.5.

Also, note that vCenter Server can have an embedded or external database server. And, if VCSA supports external databases, it is highly recommended to use the embedded one:

As previously stated, SSO is an authentication broker and security token exchange infrastructure.

As described in Objective 1.2, SSO supports multiple identity sources, including external directory services, such as AD.

Using AD for user authentication simplifies permission management, ensures password complexity, and allows for using the same security policies for AD, to minimize the risk of unauthorized access.

To improve authentication security, multi-factor authentication (MFA) is preferable to simple username/password methods. Two-factor authentication (2FA) is a type of multi-factor authentication that uses two components.

Starting with vSphere 6.0 Update 2, it is possible to use two-factor authentication, as follows:

• Smart card (UPN-based Common Access Card (CAC))
• RSA SecurID token

Multi-site PSC is only possible with an external PSC deployment. In this configuration, an SSO domain will span multiple sites. You will have one single SSO domain, but with multiple sites, as illustrated in the following diagram:

Site membership can be specified during the installation of the PSC (Stage 2), as follows:

Consider the topic described in Objective 1.1; in this section, we will consider the AD case.

To assign vCenter permissions to AD users or groups, you must first join the PSC to the AD domain. This allows the AD users to log in to the vCenter Server using the Windows session authentication (SSPI).

The procedure to join the vCenter Server to an AD domain depends on how the vCenter and the PSC have been deployed:

• Embedded PSC: Join the vCenter to the AD domain
• External PSC: Join the PSC to the AD domain

For Windows-based vCenter or PSC, just join the Windows machine to the AD domain.

For VCSA, to join the PSC or the vCenter to the AD, follow this procedure:

1. From the vSphere Web Client, log in with the right SSO admin account.
2. Select Home | Administrator | Deployment | System Configuration and choose the proper node (the PSC or the vCenter, depending on the deployment).
3. In the Manage tab, select the Advanced | Active Directory menu, then click on the Join button to enter the details to join the AD.
4. Enter the Domain to join, and optionally the Organizational unit. Specify the AD username in UPN format ([email protected]), with the privileges to join the PSC to the domain.
5. After the process has completed, the joined domain will be listed in the Domain field, and a new Leave... button will be displayed:

6. You need to reboot the node to enable the changes.
7. When the node has been rebooted, navigate to Configuration | Identity Sources to add the AD domain. Click Add to open the Add Identity Source wizard.

8. Select the Active Directory (Integrated Windows Authentication) option, and enter the joined FQDN domain name, if it's not displayed automatically.
9. Select the Use machine account option to use the local machine account as the SPN. If you expect to rename the machine, don't use this option, because it will break the authentication process. Click on OK to confirm the specified AD domain as the new identity source.
10. On the Identity Sources tab, the joined AD domain is now displayed. Now, you can assign permissions to users/groups to be members of the AD domain.

The PSC appliance (like the VCSA appliance) can be managed by using the vCenter Server Appliance Management Interface (VAMI).

However, to manage specific PSC services, you can use the Platform Services Controller UI; or, for some tasks (such as certificates management), you can also use the vSphere Web Client. Some services, such as smart card authentication, are only configurable from the Platform Services Controller UI.

The following table summarizes the different user interfaces (UIs) available for the PSC:

In this table, "PSC" is the IP address or the FQDN of the PSC (if external) or the vCenter Server (if embedded).

Starting with vSphere 6.0, the new PSC component includes not only the SSO part, but also the VMCA. The VMCA is used for the certification management of all vSphere infrastructural elements.

This not only simplifies the certification management (with auto-enrollment for expired certificates), but also improves the security of the different network connections (as described before).

Using VMCA mode (see Objective 1.2 for different modes for managing certificates), the PSC will generate and issue all certificates needed by the different vSphere components. Certificates are stored by the vSphere Endpoint Certificate Store (VECS).

To avoid browser warnings, you need to trust VMware's CA, but first, you have to gain that certificate. You can simply download it from the vCenter home page, under Download trusted root CA certificates:

You will download a simple download.zip file that contains both the CA certificate and the revocations list.

To import the certificate in a Windows system, you can use different approaches, as follows:

• Import manually: For Internet Explorer, Edge, or Chrome, you can simply double-click on the certificate and import it into the trusted CA. Note that Firefox has a different certificates repository.
• Import by using GPO: Under Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Trusted Publishers, you can import existing certificates. Be sure to import them into the Trusted Root Certification Authorities store.
• Trust from another CA: Add it as an intermediate CA in your existing CA authority.

Otherwise, you can replace the CA certificate of VMCA; or, just don't use it at all, and manage all of the certificates as you did in the past.

For more information, see KB 2097936 (https://kb.vmware.com/s/article/2097936)—How to use vSphere 6.x Certificate Manager.

For more information about authentication, see the PSC 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-779A011D-B2DD-49BE-B0B9-6D73ECF99864.html).

You can enable and disable accounts from the vSphere Web Client or the PSC UI; in both cases, you need SSO admin privileges.

With the vSphere Web Client, from Home | Administration, just select the Users and Groups menu under the Single Sign-On section. Select a user account and click on the Disable icon, as shown in the following screenshot:

To enable the user again, right-click on the username and select Enable.

For more information about authentication, see the PSC 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-AC8A1B39-8E0D-4604-82DF-C5FC92ECA50D.html).

If you have a complex vSphere environment with more external PSCs, and perhaps with multi-site deployment, the upgrade process can be a little more critical.

To upgrade a vSphere environment, there is a general order that must be followed. For the basic vSphere components, perform the following:

1. External PSC: Upgrade each SSO or PSC, one by one. Applicable only in external PSC deployments.
2. vCenter Server: Upgrade each vCenter Server, one by one.
3. ESXi hosts: Upgrade each ESXi host, one by one.

For the PSC components, it's usually preferable to upgrade them during the maintenance windows, to avoid authentication issues. But, if all external PSCs are configured in a high availability configuration, with external load balancers, you can perform upgrades on PSCs one by one, without interruptions.

For more information about each transitional step, including diagrams, see the Upgrade or Migration Order and Mixed-Version Transitional Behavior for Multiple vCenter Server Instance Deployments section in the vSphere Upgrade Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.upgrade.doc/GUID-FDF1D082-36EB-41EB-9D97-A48D33A1D843.html).

For the vCenter Server appliance (for both vCenter and PSC), the update and upgrade process can be managed from the VAMI UI. The update is quite simple (for example, using an external URL), and the upgrade requires the VCSA 6.5 ISO.

The VCSA GUI upgrade is a two-stage process (like the installation). The first stage is a deployment wizard that deploys the OVA file of the new appliance on the target ESXi host or vCenter Server instance. After the virtual appliance deployment finishes, you are redirected to the second stage of the process, which sets up and transfers the services and configuration data from the old appliance to the newly deployed appliance.

For more information, see KB 2147686 (https://kb.vmware.com/s/article/2147686)—Best practices for upgrading to vCenter Server 6.5.

The vCenter SSO policies enforce security rules related to the SSO users defined in your environment. There are three main types of SSO policies: password policies, lockout policies, and token policies.

You can manage SSO policies from the vSphere Web Client (with SSO admin privileges) or the PSC UI.

With the vSphere Web Client, in Home | Administration, just select the Configuration menu in the Single Sign-On section. Then, select the Policies tab and choose the right category of policies, as follows:

Note that there are password expiration rules for the virtual appliance local users, if you are using VCSA for vCenter and/or the PSC components. Be sure to check those settings. By default, vCenter Single Sign-On passwords expire after 90 days. Starting with version 6.0, the password policy only applies to SSO user accounts, not to SSO system accounts (usually [email protected]).

If you are using AD users, both for hosts and vCenter, then the password policies are enforced by AD GPO.

For more information about authentication, see the PSC 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-43527B09-63BB-44A6-91D3-E3A470904698.html).

This task was described in Objective 1.2, in the host hardening options.

For more details, see KB 2075361 (https://kb.vmware.com/s/article/2075361)—Configuring ESXi host with AD authentication.

In vSphere 6.5, to encrypt VM disks, you will need to configure a Key Management Server (KMS), or, better yet, a cluster of KMS.

You can use the vSphere Web Client, as follows:

1. Select the vCenter Server in the inventory, then select the Configure tab. Expand More, and select Key Management Server to access the KMS management section.

2. Click on the Add KMS... icon to add the KMS server (you must have one in your network). Specify the required parameters, and click on OK to save the configuration:

3. Once the KMS server is successfully added to the vCenter Server, the Connection Status will be displayed as Normal. Having configured the KMS server, you can start encrypting VMs.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-78DD547A-6FFC-49F1-A5F2-ECD7507EE835.html) or the StarWind blog post at https://www.starwindsoftware.com/blog/encryption-of-vmware-vsphere-6-5-virtual-machines-and-vmotion-migrations-and-their-performance.