Loading…

Virtualisation | Cloud | Strategy

Objective 1.3 –Configure and Enable SSO and Identity Sources

Continuing onward to Objective 1.3 –Configure and Enable SSO and Identity Sources. Happy Revising, Simon

VCP6.5 Certification Blueprint

 

Objective 1.3 –Configure and Enable SSO and Identity Sources

Describe PSC architecture and components

You can deploy the vCenter Server Appliance or install vCenter Server for Windows with an embedded or external Platform Services Controller. You 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.

Before you deploy the vCenter Server Appliance or install vCenter Server for Windows, you must determine the deployment model that is suitable for your environment. For each deployment or installation, you must select one of the three deployment types.

vCenter Server with an embedded Platform Services Controller

All services that are bundled with the Platform Services Controller are deployed together with the vCenter Server services on the same virtual machine or physical server.

Platform Services Controller

Only the services that are bundled with the Platform Services Controller are deployed on the virtual machine or physical server.

vCenter Server with an external Platform Services Controller

Only the vCenter Server services are deployed on the virtual machine or physical server. You must register such a vCenter Server instance with a Platform Services Controller instance that you previously deployed or installed.

vCenter Server with an Embedded Platform Services Controller

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.

Installing vCenter Server with an embedded Platform Services Controller has the following advantages:

  • The connection between vCenter Server and the Platform Services Controller is not over the network, and vCenter Server is not prone to outages caused by connectivity and name resolution issues between vCenter Server and the Platform Services Controller.
  • If you install vCenter Server on Windows virtual machines or physical servers, you need fewer Windows licenses.
  • You manage fewer virtual machines or physical servers.

Installing vCenter Server with an embedded Platform Services Controller has the following disadvantages:

  • There is a Platform Services Controller for each product which might be more than required and which consumes more resources.
  • The model is suitable only for small-scale environments.

Platform Services Controller and vCenter Server with an External Platform Services Controller

When you deploy or install a Platform Services Controller instance, you can create a vCenter Single Sign-On domain or join an existing vCenter Single Sign-On domain. Joined Platform Services Controller instances replicate their infrastructure data, such as authentication and licensing information, and can span multiple vCenter Single Sign-On sites.

You can register multiple vCenter Server instances with one common external Platform Services Controller instance. The vCenter Server instances assume the vCenter Single Sign-On site of the Platform Services Controller instance with which they are registered. All vCenter Server instances that are registered with one common or different joined Platform Services Controller instances are connected in Enhanced Linked Mode.

Installing vCenter Server with an external Platform Services Controller has the following advantages:

  • Fewer resources consumed by the shared services in the Platform Services Controller instances.
  • The model is suitable for large-scale environments.

Installing vCenter Server with an external Platform Services Controller has the following disadvantages:

  • The connection between vCenter Server and Platform Services Controller might have connectivity and name resolution issues.
  • If you install vCenter Server on Windows virtual machines or physical servers, you need more Microsoft Windows licenses.
  • You must manage more virtual machines or physical servers.

Mixed Operating Systems Environment

A vCenter Server instance installed on Windows can be registered with either a Platform Services Controller installed on Windows or a Platform Services Controller appliance. A vCenter Server Appliance can be registered with either a Platform Services Controller installed on Windows or a Platform Services Controller appliance. Both vCenter Server and the vCenter Server Appliance can be registered with the same Platform Services Controller.

 

Differentiate available authentication methods with VMware vCenter

vCenter Single Sign-On is an authentication broker and security token exchange infrastructure. 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.

Because traffic is encrypted for all communications, and because only authenticated users can perform the actions that they have privileges for, your environment is secure.

Starting with vSphere 6.0, vCenter Single Sign-On is part of the Platform Services Controller. The Platform Services Controller contains the shared services that support vCenter Server and vCenter Server components. These services include vCenter Single Sign-On, VMware Certificate Authority, and License Service.

For the initial handshake, users authenticate with a user name and password, and solution users authenticate with a certificate

Perform a multi-site PSC installation

To ensure Platform Services Controller high availability in external deployments, you must install or deploy at least two joined Platform Services Controller instances in your vCenter Single Sign-On domain. When you use a third-party load balancer, you can ensure an automatic failover without downtime.

You can use a third-party load balancer per site to configure Platform Services Controller high availability with automatic failover for this site.

The vCenter Server instances are connected to the load balancer. When a Platform Services Controller instance stops responding, the load balancer automatically distributes the load among the other functional Platform Services Controller instances without downtime.

Your vCenter Single Sign-on domain might span multiple sites. To ensure Platform Services Controller high availability with automatic failover throughout the domain, you must configure a separate load balancer in each site.

Configure/Manage Identity Sources

When you install a Platform Services Controller, you are prompted to create a vCenter Single Sign-On domain or join an existing domain.

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

You manage Platform Services Controller services from the Platform Services Controller Web interface, from the vSphere Web Client, or by using one of the available scripts and CLIs.

Different Platform Services Controller services support different interfaces.

Platform Services Controller Web interface

Web interface for managing all services including vCenter Single Sign-On and Common Access Card. Connect to https://psc_hostname_or_IP/psc.

vSphere Web Client

Web interface for managing some of the services. Some services, such as smart card authentication, are configurable only from the Platform Services Controller Web interface.

Certificate Management utility

Command-line tool that supports CSR generation and certificate replacement.

CLIs for managing Platform Services Controller services

Set of commands for managing certificates the VMware Endpoint Certificate Store (VECS), and VMware Directory Service (vmdir).

Platform Services Controller virtual appliance management interface (VAMI)

Use this interface to reconfigure the system settings of a Platform Services Controller deployment.

Platform Services Controller appliance shell

Use this command-line interface to perform service management operations on VMCA, VECS, and VMDIR.

Configure/Manage VMware Certificate Authority (VMCA)

VMCA Default

VMCA uses a self-signed root certificate. 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.

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

Custom

In this scenario VMCA is completely bypassed. This scenario is for those customers that want to issue and/or install their own certificates. You will need to issue a cert for every component, not unlike you do today for 5.5 when using 3rd party certs. And all of those certs (except for host certs) need to be installed into VECS.

In Default and Enterprise modes VMCA certificates can be easily regenerated on demand.

Certificates can be managed with;

  • vSphere Certificate Manager Utility
  • Certificate management CLI: dir-cli, certool & vecs-cli
  • vSphere web client certificate management
    • View access to look at certs and expiration info
    • ESXi cert management is performed via web client
    • Logon to web client as a member of the CAAdmins group.

Enable/Disable Single Sign-On (SSO) Users

vsphere web client -> administration->SSO->users and groups. right-click user -> disable. will show in the column “disabled”

If you delete the administrator user in the vsphere.local domain you can no longer logon to vcenter single sign-on. You must reinstall vCenter and its components. By default passwords expire every 90 days, but administrator@vsphere.local does not expire.

SSO groups

administrator: can manage SSO users added to this group have global permissions to SSO & all of inventory that are managed by that SSO domain

CAAdmins: can manage VMCA

LicenseService.Administrators: can manage licenses

Upgrade a single/complex PSC installation

You can upgrade the vCenter Server Appliance 5.5 or 6.0 and the Platform Services Controller appliance 6.0 to version 6.5. All of the installation files that are necessary for the upgrade are included in the vCenter Server Appliance installer, which you can download from the VMware Web site.

The upgrade of the vCenter Server Appliance or Platform Services Controller appliance is a migration of the old version to the new version, which includes deploying a 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. 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 host name 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 vCenter Server Appliance uses the embedded PostgreSQL database. 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 vCenter Server Appliance uses the embedded VMware vSphere Update Manager Extension service. If you are upgrading a vCenter Server Appliance that is using an external VMware Update Manager instance, the external VMware Update Manager instance will be migrated to the embedded VMware vSphere Update Manager Extension of the new upgraded appliance. The embedded VMware vSphere Update Manager Extension uses the embedded PostgreSQL database. Before the upgrade, you must run the Migration Assistant on the source VMware Update Manager instance.

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

The vCenter Server Appliance 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. After the OVA deployment finishes, 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

vCenter Single Sign-On policies enforce the security rules in your environment. You can view and edit the default vCenter Single Sign-On password policy, lockout policy, and token policy.

The vCenter Single Sign-On password policy governs the format and expiration of vCenter Single Sign-On user passwords. The password policy applies only to users in the vCenter Single Sign-On domain (vsphere.local). By default, vCenter Single Sign-On passwords expire after 90 days. The vSphere Web Client reminds you when your password is about to expire.

Specific policy configurations are listed from page 57 to 60 of the vsphere-esxi-vcenter-server-65-platform-services-controller-administration-guide.pdf

Add an ESXi host to an AD domain

You can configure a host to use a directory service such as Active Directory to manage users and groups. When you add an ESXi host to Active Directory, the DOMAIN group ESX Admins is assigned full administrative access to the host if it exists.

If a host is provisioned with Auto Deploy, Active Directory credentials cannot be stored on the hosts. You can use the vSphere Authentication Proxy to join the host to an Active Directory domain. Because a trust chain exists between the vSphere Authentication Proxy and the host, the Authentication Proxy can join the host to the Active Directory domain.

  • Synchronize the time between ESXi and the directory service system using NTP.
    • Start the VMware Host Client, and connect to the ESXi host.
    • Click Configure.
    • Under System, click Time Configuration, and click Edit.
    • Select Use Network Time Protocol (Enable NTP client).
    • In the Add NTP Server text box, enter the IP address or fully qualified domain name of one or more NTP server to synchronize with.
    • Set the startup policy and service status.
    • Click OK.
  • Ensure that the DNS servers that you configured for the host can resolve the host names for the Active Directory controllers.
    • Browse to the host in the vSphere Web Client object navigator.
    • Click Configure..
    • Under Networking, click TCP/IP configuration.
    • Under TCP/IP Stack: Default, click DNS and verify that the host name and DNS server information for the host are correct.
  • Browse to the host in the vSphere Web Client inventory.
  • Click Configure.
  • Under System, select Authentication Services.
  • Click Join Domain.
  • Enter a domain.
  • Use the form name.tld or name.tld/container/path.
  • Enter the user name and password of a directory service user who has permissions to join the host to the domain, and click OK.
  • If you intend to use an authentication proxy, enter the proxy server IP address.
  • Click OK to close the Directory Services Configuration dialog box.

Configure and Manage KMS for VM Encryption

Before you can start with virtual machine encryption tasks, you must set up the key management server (KMS) cluster. That task includes adding the KMS and establishing 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.

 

Detailed steps are listed between pages 137 and 152 of vsphere-esxi-vcenter-server-65-security-guide.pdf.