VCP6.5-DCV Objective 1.3 - Configure and Enable SSO and Identity Sources

And again another chapter from the upcoming VCP6.5-DCV Study guide today. The chapters are released in no particular order. The one released today is VCP6.5-DCV Objective 1.3 – Configure and Enable SSO and Identity Sources. We're heavily using VMware vSphere 6.5 documentation and also our lab, to get all topics covered.

As you know, the latest vSphere 6.5 has now its certification exam. (since April). Not many guides are online so far, so we thought that it might be (finally) perhaps, a good idea to get things up.

I think the majority of new VCP candidates right now will go for the VCP6.5-DCV even if the VCP6-DCV seems less demanding. There are fewer topics to know.

Exam Price: $250 USD, there are 70 Questions (single and multiple answers), passing score 300, and you have 105 min to complete the test.

Tip: Check our How-to, tutorials, videos on a dedicated vSphere 6.5 Page. (work in progress).

Check our VCP6.5-DCV Study Guide Page.

You can download your free copy via this link – Download Free VCP6.5-DCV Study Guide at Nakivo.

VCP6.5-DCV Objective 1.3 – Configure and Enable SSO and Identity Sources

Describe PSC architecture and components
Differentiate available authentication methods with VMware vCenter
Perform a multi-site PSC installation
Configure/Manage Identity Sources
Configure/Manage Platform Services Controller (PSC)
Configure/Manage VMware Certificate Authority (VMCA)
Enable/Disable Single Sign-On (SSO), Users
Upgrade a single/complex PSC installation
Configure SSO policies
Add an ESXi host to an AD domain
Configure and Manage KMS for VM Encryption

Describe PSC architecture and components

Platform Service Controler (PSC) can be installed along with vCenter (VC)or apart. ou can also deploy a Platform Services Controller as an appliance or install it on Windows. If necessary, you can use a mixed operating systems environment.

There are three deployment types:

VC with External PSC
VC with Embedded PSC
PSC only

If you have an only single site, VMware recommends using a single VM (VC+PSC). This is a standalone deployment type that has its own vCenter Single Sign-On domain with a single site. vCenter Server with an embedded Platform Services Controller is suitable for small environments. You cannot join other vCenter Server or Platform Services Controller instances to this vCenter Single Sign-On domain.

Example of PSC login page. Use https://IP_or-FQDN/psc

PSC Domain – when installing PSC, there is a prompt to create vCenter SingleSign-On Domain (SSO) or join an existing domain. The domain name is used by VMware directory service for their internal LDAP structuring. You should always use another name then you’re using for your Microsoft AD, Open LDAP or other directory services within your organization.

PSC Site – You can organize PSC domains into logical sites. A site in the VMware Directory Service is a logical container for grouping PSC instances within a vCenter Single Sign-On domain.

PSC Services:

VMware Appliance Management Service
VMware License Service
VMware Component Manager
VMware Identity Management Service
VMware HTTP Reverse Proxy
VMware Service Control Agent
VMware Security Token Service
VMware Common Logging Service
VMware Syslog Health Service
VMware Authentication Framework
VMware Certificate Service
VMware Directory Service.

PSC Allows you to:

Authentication via vCenter Single Sign-On (SSO)
Provision ESXi hosts with VMware Certificate manager (VMCA) certificates by default
Use custom certificates stored in VMware Endpoint Certificate store (VECS).

Using single PSC in Single domain

The most simple is to deploy VMware PSC and vCenter server on a single VM, together. As such, the PSC component does not need a network connection to the vCenter server (as it communicates already, it is within the same VM).

TIP: How to deploy VMware VCSA 6.5 (VMware vCenter Server Appliance)

Further, it has some following advantages:

Fewer Windows Licenses
Fewer Virtual machines to manage
Using fewer resources

Disadvantages:

Suitable for smaller-scale environments only
Single sign-on domain only

Using multiple PSCs in single domain

Single PSC has several vCenter servers “hooked” into it.

Advantages:

can assure HA with an external load balancer

Disadvantages

consumes more resources

Differentiate available authentication methods with VMware vCenter

vCenter SSO is an authentication broker and security token exchange infrastructure which uses SAML tokens. When a user or a solution user can authenticate to vCenter Single Sign-On, that user receives a SAML token. Going forward, the user can use the SAML token to authenticate to vCenter services. The user can then perform the actions that user has privileges for. All traffic is encrypted for all communications.

Starting with vSphere 6.0, vCenter SSO is part of the PSC. The PSC contains the shared services that support vCenter Server and vCenter Server components. These services include vCenter Single Sign-On, VMware Certificate Authority, or License Service. For the initial handshake, users authenticate with a username and password, and solution users authenticate with a certificate.

Perform a multi-site PSC installation

PSC can also be deployed without a load balancer, but in this case, in a case of failure the PSC, you must manually fail over the vCenter Server instances that are registered to it by repointing them to other functional PSC instances within the same site.

Mixed Operating system – Windows VM hosting PSC with two or more VMs running Windows-based vCenters, “hooked” into PSC.
External PSC with a load balancer
External PSCs with a Load balancer on multiple sites – you must install or deploy at least two joined PSC instances in your vCenter SSO domain.

Configure/Manage Identity Sources

When you install a PSC, you are invited to create a vCenter SSO domain or join an existing domain. The vSphere domain name is used by the VMware Directory Service (vmdir) for all Lightweight Directory Access Protocol (LDAP) internal structuring.

With vSphere 6.0 and later, you can give your vSphere domain a unique name. To prevent authentication conflicts use a name that is not used by OpenLDAP, Microsoft Active Directory, and other directory services. You cannot change the domain to which a Platform Services Controller or vCenter Server instance belongs.

If you are upgrading from vSphere 5.5, your vSphere domain name remains the default (vsphere.local). For all versions of vSphere, you cannot change the name of a domain.

After you specify the name of your domain, you can add users and groups. It usually makes more sense to add an Active Directory or LDAP identity source and allow the users and groups in that identity source to authenticate. You can also add vCenter Server or Platform Services Controller instances, or other VMware products, such as vRealize Operations, to the domain.

Configure/Manage Platform Services Controller (PSC)

The Platform Services Controller (PSC) provides:

Single Sign-On (SSO)
Licensing
Certificate Authority (VMCA)

You can deploy it on at the same time or apart and you can deploy it as Windows-based or Appliance based (VCSA). It’s important to know that PSO is completely transparent working with Windows or VCSA based vCenter!

PSC Deployment Options – A two different type installation are allowed:

Embedded (in the same VM)
External

The embedded PSC is meant to be used for standalone sites where a vCenter server will be the only SSO integrated solution. In this case, a replication to another PSC is not necessary.

External PSC shall be deployed in environments where there is more than one SSO enabled solution (vCenter Server, vRealize Automation, etc…) OR where replication to another PSC (another site) is necessary.

Here is the screenshot of the installation process (VCSA) showing the different options and changing the options also changes the different phases of the deployment (on the left).

PSC features:

Manages and generates SSL certificates for your vSphere environment.
Stores and replicates VMware License Keys
Stores and replicates permissions via the Global Permissions layer.
Manages the storage and replication of TAGS and CATEGORIES.
There is a Built-in automatic replication between different, logical SSO sites. (if any)
There is only one single default domain for the identity sources.

Deployment Options:

Embedded Platform Service Controller
All services bundled with the Platform Services Controller are deployed on the same virtual machine or physical server as vCenter Server.
External Platform Service Controller
The services bundled with the Platform Services Controller and vCenter Server are deployed on different virtual machines or physical servers.

Configure/Manage VMware Certificate Authority (VMCA)

When you first install vSphere, the default certificates are deployed with 10 years of life span. The VMCA generates those self-signed certs during the installation process, and provisions each of the ESXi host with a signed certificate by this root certificate authority. Earlier versions of vSphere with self-signed certificates are automatically replaced by new self-signed certificates by VMCA.

There are different ESXi Certificate replacement modes:

Default – VMCA as cert authority where VMCA issues certs for your hosts. A self-signed root certificate is used. It issues certificates to vCenter, ESXi, etc and manages these certificates. These certificates have a chain of trust that stops at the VMCA root certificate. VMCA is not a general purpose CA and its use is limited to VMware components
Custom – you can override and do issue certs manually via VMCA. You will need to issue a cert for every component, need to be installed into VECS.
Enterprise – VMCA is used as a subordinate CA and is issued subordinate CA signing certificate. It can now issue certificates that trust up to the enterprise CA’s root certificate. If you have already issued certs using VMCA Default and replace VMCA’s root cert with a CA signing cert then all certificates issued will be regenerated and pushed out to the components.

Where to check the certificates in Web client?

Home -> System Configuration -> Nodes -> Node -> Manage -> Certificate Authority

Note: If you’re not a member of “SystemConfiguration.Administrators” group than you might want to add yourself there.

vSphere web client certificate management

View access to look at certs and expiration info
ESXi cert management is performed via web client
Logon to the web client as a member of the CAAdmins group.

VCP6.5-DCV: Enable/Disable Single Sign-On (SSO) Users

The VMware SSO uses different configuration policy which can be found via vSphere Web client only:

Administration > Single Sign-On > Configuration Policies

Password Policy
Lockout Policy
Token Policy

To Enable/Disable SSO User:

Connect via vSphere Web client > Administration > SSO > Users and groups > Right-click User > Disable. will show in the column “disabled”

Password Policy

You can configure the following parameters:

Description – Password policy description. Required.
Maximum lifetime – Maximum number of days that a password can exist before it has to be changed.
Restrict re-use – Number of the user’s previous passwords that cannot be set again.
Maximum length – Maximum number of characters that are allowed in the password.
Minimum length – Minimum number of characters required in the password.
Character requirements – Minimum number of different character types required in the password.
Identical adjacent characters – Maximum number of identical adjacent characters allowed in the password.

SSO groups:

Administrator – can manage SSO users added to this group have global permissions to SSO & all of inventory that is managed by that SSO domain

CAAdmins – can manage VMCA

LicenseService.Administrators – can manage licenses

Upgrade a single/complex PSC installation

Upgrade VCSA 5.5 or 6.0 and the PSC appliance 6.0 to version 6.5. The upgrade of the VCSA or PSC appliance is a migration of the old version to the new version (including deployment of the new appliance of version 6.5). You can deploy the new appliance on an ESXi host 5.5 or later, or on the inventory of a vCenter Server instance 5.5 or later. Wizard driven. You assign a temporary IP address to the new appliance to facilitate the configuration and services data migration from the old appliance to the newly deployed appliance.

After the migration, the IP address and hostname of the old appliance are applied to the new upgraded appliance of version 6.5. At the end of the upgrade, the temporary IP address is released and the old appliance is powered off.

Version 6.5 of the VCSA uses the embedded PostgreSQL DB. If you are upgrading a vCenter Server Appliance that is using an external database, the external database will be migrated to the embedded PostgreSQL database of the new upgraded appliance. During the upgrade, you must select a storage size for the new appliance that is suitable for the database size.

Version 6.5 of the VCSA uses the embedded VMware vSphere Update Manager Extension (VUM) service. If you are upgrading a VCSA that is using an external VUM instance, the external VUM instance will be migrated to the embedded VUM Extension of the new upgraded appliance. The embedded VUM Extension uses the embedded PostgreSQL DB. Before the upgrade, you must run the Migration Assistant on the source VMware Update Manager instance.

For topologies with external PSC instances, you must upgrade the replicating PSC instances in a sequence. After the successful upgrade of all PSC instances in the domain, you can perform concurrent upgrades of multiple VCSA appliances that point to a common external PSC instance.

The VCSA installer contains executable files GUI and CLI upgrades which you can use alternatively.

The GUI upgrade is a two-stage process:

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.
The Second stage – after deployment phase you are redirected to the second stage of the process that sets up and transfers the services and configuration data from the old appliance to the newly deployed appliance.

The CLI upgrade method involves running a CLI command against a JSON file that you previously prepared. The CLI installer parses the configuration parameters and their values from the JSON file and generates an OVF Tool command that automatically deploys the new appliance and transfers the services and configuration data from the old appliance.

If the appliance that you are upgrading is configured in a mixed IPv4 and IPv6 environment, only the IPv4 settings are preserved.

If the appliance that you are upgrading uses a non-ephemeral distributed virtual port group, the port group is not preserved. After the upgrade, you can manually connect the new appliance to the original non-ephemeral distributed virtual port group of the old appliance

Configure SSO policies

VMware SSO policies are accessible through Home > Administration > SSO > Configuration.

By clicking the Edit button you are able to change values there…

If you leave the default values and after 90 days you will want to log-in you might end up with messages saying that:

User Account is locked.
User Account is disabled.

Those SSO policies are pretty much the same as in vSphere 5.5, but with a difference that in vSphere 5.5 we also had an administrator password expiry on the vCenter server appliance (VCSA). The VCSA 6.0 is pretty much locked out and the GUI we use to manage VCSA accessible via the port 5480 is no longer available.

Add an ESXi host to an AD domain

Create the ESX Admins group in the AD domain and populate it with user accounts or groups to which administrative access to the hosts should be granted. Also, additional AD user accounts and groups can be granted with appropriate access to hosts. Go to your Domain controller and create a Global Security group called “ESX Admins” > Make a domain administrator part of this group.

Log in to your vCenter with the vSphere Web Client and Select your ESXi host > Configure > System > Authentication Services > Join Domain.

Enter the domain name and user credentials for your environment > click OK

Use the form name.tld or name.tld/container/path.

Check this: Using the ESX Admins AD group with ESX/ESXi 4.1 and ESXi 5.x/6.x domain membership and user

You should also make sure that on your DNS server you have created static forward AND reverse DNS records for your host. DNS can be a pain if configured wrong. A good DNS resolution is a good start on healthy vSphere setup.

NTP is also an important configuration step. ESXi should use, when possible, an external source of time. Synchronize the time between ESXi and the directory service system using NTP.

TIP: How to configure ESXi 6.5 Network Time Protocol (NTP) via Host Client?

Configure and Manage KMS for VM Encryption

First, you must set up the key management server (KMS) cluster. You add the KMS and establish trust with the KMS. When you add a cluster, you are prompted to make it the default. You can explicitly change the default cluster. vCenter Server provisions keys from the default cluster.

You add a KMS to your vCenter Server system from the vSphere Web Client or by using the public API. vCenter Server creates a KMS cluster when you add the first KMS instance. When you add the KMS, you are prompted to set this cluster as a default. You can later change the default cluster explicitly.

After vCenter Server creates the first cluster, you can add KMS instances from the same vendor to the cluster.You can set up the cluster with only one KMS instance. n If your environment supports KMS solutions from different vendors, you can add multiple KMS clusters.

Who Manages encryption?

It is not a vCenter server, which is only a client. The 3rd party Key Management Server (KMS) is the one responsible for the encryption of the key and the management.

With that, you may ask who will be able to manage encryption of your VMs? Does all your vSphere admins need to have access to encryption? Possibly. But possibly NOT. VMware has created a new default role “No Cryptography Administrator“, but we won't go into details as it is not the purpose of this lesson.

Detailed steps are for setting up KMS cluster can be found on pages 137 and 152 within the latest Security Guide PDF.

So this is it for today. We have covered the VCP6.5-DCV Objective 1.3 – Configure and Enable SSO and Identity Sources. Make sure to bookmark the VCP6.5-DCV Study page.

More from ESX Virtualization

Stay tuned through RSS, and social media channels (Twitter, FB, YouTube)

Vote !

VCP6.5-DCV Objective 1.3 – Configure and Enable SSO and Identity Sources