Objective 1.3 – Configure and Enable SSO and Identity Sources

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).

Objective 1.3 for VCP65-DCV and VCP6-DCV is similar, because there weren't major changes in SSO authentication from vSphere 6.0 to vSphere 6.5.

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).

Describe PSC architecture and components

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:

Figure 1.21: PSC and vCenter

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

Platform Service Controller	vCenter Server
Single Sign-On Custom roles Global permissions Certificate Authority VMware Certificate Service VMware Identity Management Service VMware Directory Service VMware License Service Tags VMware Appliance Management Service (VAMI), on VCSA only	vCenter Server Inventory Service Profile-Driven Storage HTML5 / vSphere Web Clients Server Auto Deploy Content Library Syslog Collector ESXi Dump Collector Optional: VMware Update Manager Optional: Embedded DB (PostgreSQL)

Table 1.4: PSC and vCenter node services and functions

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).

Note that the PSC uses limited resources, as compared to the management nodes (just 2 vCPU and 4 GB of RAM).

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:

	Embedded PSC	External PSC
Scalability	2,000 hosts per vCenter 25,000 VMs per vCenter (powered-on)	2,000 hosts per vCenter 25,000 VMs per vCenter (powered-on) More with linked mode
Manageability	Best	More servers to be managed
Upgrade/Patching	Simple	First update all PSCs, and then vCenter
Resiliency	No outages caused by connectivity and name resolution issues between vCenter and PSC	Possible outages caused by connectivity and name resolution issues between vCenter and PSC
Availability	VCSA: vCenter HA Windows: Failover Cluster	For vCenter, same solutions For PSC, load balancer
Multi-vCenter	VMware Cloud for AWS Enhanced linked mode (for VCSA 6.5U2 or later)	Enhanced linked mode
Multi-Site	No	Enhanced linked mode

Table 1.5: Embedded and external PSC

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:

	Embedded DB	External DB
Scalability	For VCSA: 2,000 hosts or 25,000 VMs (powered-on) For Windows: 20 hosts or 200 VMs	2,000 hosts or 25,000 VMs (powered-on) More with linked mode
Manageability	Best	More servers to be managed
Upgrade/Patching	Simple	More dependencies
Resiliency	No outages caused by connectivity issues between vCenter and DB	Possible outages caused by connectivity issues between vCenter and DB
Availability	VCSA: vCenter HA Windows: Failover Cluster	DB requires a specific solution, such as clustering

Table 1.6: Embedded and external databases

Differentiate available authentication methods with VMware vCenter

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

In vSphere 5.1 and 5.5, SSO was a specific role, but starting with vSphere 6.0, SSO is a part of the PSC role.

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

Note that vCenter SSO only supports native SecurID, and does not support RADIUS authentication. 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-ACFFCBEC-6C1C-4BF9-9971-04AEE9362AFE.html).

Perform a multi-site PSC installation

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:

Figure 1.22: Multi-site PSC deployment

To provide high availability for the PSC, it's recommended to have at least two PSCs on each site, with a third-party load balancer.

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

Figure 1.23: PSC deployment

Configure/manage identity sources

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

Only a writable Domain Controller can be used to join the AD domain. A Read-Only Domain Controller (RODC) is not supported.

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:

Figure 1.24: AD membership

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.

To prevent authentication conflicts, don't use a username that is used by other identity sources, such as OpenLDAP or Microsoft AD.

Configure/manage platform services controller (PSC)

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:

Web interface	URL
VAMI (only for VCSA appliances)	https://PSC:5480
Platform Services Controller UI	https://PSC/psc
vSphere Web Client	https://vCenter/vsphere-client

Table 1.7: UI interfaces for PSC

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

Configure/manage VMware Certificate Authority (VMCA)

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:

Figure 1.25: vCenter Server home page

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).

Enable/disable SSO users

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:

Figure 1.26: Disable SSO users

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

If you disable (or delete) the administrative user in the SSO domain, you cannot manage the SSO domain (unless you previously created another user with SSO admin privileges).

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).

Upgrade a single/complex PSC installation

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.

In environments with more VMware products, the upgrade/update sequence is much more complex. See VMware KB 2147289 (https://kb.vmware.com/s/article/2147289)—Update sequence for vSphere 6.5 and its compatible VMware products.

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.

Configure SSO policies

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:

Figure 1.27: SSO policies

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).

Add an ESXi host to an AD domain

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.

Remember to synchronize the proper time between ESXi and the directory service system.

Configure and manage KMS for VM encryption

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:

Figure 1.28: Adding a new KMS

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.

KMS are mandatory for VM encryption, but are not required for vMotion encryption.

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.