This is the fifth part of the VCP6-DCV Delta Study Guide. It covers management and security improvements in vSphere 6.0. After this section you should be able to understand the changes to Single-Sign on, the new Certificate Authority and to differentiate vSphere Clients.
- Single Sign-On authentication process
- vSphere Component Communication
- VMware Certificate Authority
- vSphere License Service
- vSphere Client Comparison
Single Sign-On authentication process
vCenter Single Sign-On (SSO) is part of the Platform Services Controller since vSphere 6.0. SSO is an authentication broker and security token exchange infrastructure. When a user or a solution user authenticates with Single Sign-On, that user receives a SAML token. For the initial handshake, users authenticate with a username and password, solution users authenticate with a certificate. With this SAML token, the user can authenticate to the vCenter Server or other services.
vCenter Single Sign-On Authentication for Human Users
- A user logs in to the vSphere Client or vSphere Web Client with his username and password or with his Windows session authentication
- Login information are passed to vCenter Single Sign-On service, which checks the SAML token of the vSphere Web Client. If the vSphere Web Client has a valid token, vCenter Single Sign-On checks whether the user is in the configured identity source (for example Active Directory).
- If only the user name is used, vCenter Single Sign-On checks in the default domain.
- If a domain name is included with the user name (DOMAIN\user or user@DOMAIN), vCenter Single Sign-On checks that domain.
- If the user can authenticate to the identity source, vCenter Single Sign-On returns a token that
represents the user to the vSphere Web Client. - The vSphere Web Client passes the token to the vCenter Server system.
- vCenter Server checks with the vCenter Single Sign-On server that the token is valid and not expired.
- The vCenter Single Sign-On server returns the token to the vCenter Server system.
vCenter Single Sign-On Authentication for Solution Users
Solution users are used by services that are part of the vCenter Server infrastructure. Examples for solution users are the vCenter Server itself, vCenter Server extensions or third-party extensions.
- The solution user connects to a vCenter service
- The solution user is redirected to vCenter Single Sign-On. If the solution user is new to vCenter Single Sign-On, it has to present a valid certificate.
- If the certificate is valid, vCenter Single Sign-On assigns a SAML token to the solution
user. The token is signed by vCenter Single Sign-On. - The solution user is then redirected to the vCenter Server.
The next time the solution user has to authenticate, it can use the SAML token to log in to
vCenter Server directly.
vCenter Single Sign-On Components
- Security Token Service (STS) - The STS issues Security Assertion Markup Language (SAML) tokens. These security tokens represent the identity of a user. The SAML tokens allow both human users and solution users who authenticate successfully to vCenter Single Sign-On to use any vCenter service that vCenter Single SignOn supports without authenticating again to each service.
- Administration server - The administration server is the SSO configuration interface in the vSphere Web Client. It allows administrators to configure SSO and manage users.
- VMware Directory Service (vmdir) - The VMware Directory Service stores vCenter Single Sign-On and certificate information. Vmdir is associated with the domain you specify during the installation and is included in each embedded deployment and on each Platform Services Controller.
- Identity Management Service - Handles identity sources and STS authentication requests.
Identity Sources
An identity source is a collection of user and group data. You can use identity sources to attach one or more domains to vCenter Single Sign-On. At any time, only one default domain exists. If a user from a non-default domain logs in, that user must add the domain name (DOMAIN\user) to authenticate successfully. vCenter Single Sign-On supports the following types of user repositories as identity sources:
- vCenter Single Sign-On users
- Active Directory versions 2003 and later
- Active Directory over LDAP
- OpenLDAP versions 2.4 and later
- Local operating system users
vSphere Component Communication
vSphere components use SSL to communicate securely with each other and with ESXi. SSL communications
ensure data confidentiality and integrity. Data is protected, and cannot be modified in transit without
detection.
vCenter Server services such as the vSphere Web Client also use their certificates for their initial
authentication to vCenter Single Sign-On. vCenter Single Sign-On provisions each component with a SAML
token that the component uses for authentication going forward.
In vSphere 6.0 and later, the VMware Certificate Authority (VMCA) provisions each ESXi host and each
vCenter Server service with certificates that are signed by VMCA by default. You can use the vSphere
Certificate Manager command-line utility to perform certificate replacement operations. In special cases,
you can replace certificates manually.
VMware Certificate Authority
The PSC contains the VMware Certificate Authority (VMCA) and the VMware endpoint certificates services (VECS). The VMCA is a root certificate authority (CA) that issues signed certificates to all vSphere 6.0 components via the solution users. This secures the environment by using a CA to generate certificates as opposed to using self-signed certificates as in previous releases. The VMCA can also be configured as a subordinate CA, enabling it to issue certificates based on an existing enterprise CA. Certificates are stored within VECS and no longer in the filesystem of vCenter Server.
If company policy requires certificates that are signed by a third-party or enterprise certificate authority you have to replace the VMCA root certificate with a CA-signed certificate during the installation. The VMCA certificate acts as an intermediate certificate of this third-party CA. VMCA provisions vCenter Server components and ESXi hosts with certificates that include the full certificate chain.
If you do not want to replace VMware certificates, VMCA can handle all certificate management automatically. VMCA provisions vCenter Server components and ESXi hosts with certificates that use VMCA as the root certificate authority.
If you are upgrading to vSphere 6 from an earlier version of vSphere, all self-signed certificates are replaced with certificates that are signed by VMCA.
VMCA Operation Mode
VMCA can operate in two modes:
- Root CA: VMCA is initialized with a self signed certificate. This is a similar form of certificate that the old vCenter 5.x solutions created for themselves, except those were not CA certs.
- Issuer CA: An Enterprise CA signs the Certificate Signing Request (CSR) that the VMCA generates and the administrator configures VMCA to use this certificate and keys.
Certificate Replacement
There are three certificate replacement options for vCenter.
Default mode - VMCA creates a self signed root certificate. These root certificates can be regenerated on demand as necessary.
Enterprise mode - VMCA has been issued a signing certificate from the enterprise certificate authority. If you have already used VMCA In default mode and issued certificates from the VMCA root certificate authority and wish to migrate to the enterprise mode then you will need to regenerate all of the old certificates.
Custom - To use an external certificate authority or third party certificates you have to disable VMCA as the certificate authority for the vCenter.
View Certificates
You can view the certificates from vCenter Certificate Authority (VMCA) with the vSphere Web Client. This enables and administrator to see whether active certificates are about to expire, to check on expired certificates, and to see the status of the root certificate. All certificate management tasks are also available in the certificate management CLI.
You view certificates associated with the VMCA instance that is included with your embedded deployment or with the Platform Services Controller. Certificate information is replicated across instances of VMware Directory Service (vmdir).
When you attempt to view certificates in the vSphere Web Client, you are prompted for a user name and password. Specify the user name and password of a user with privileges for VMware Certificate Authority, that is, a user in the CAAdmins vCenter Single Sign-On group.
To view certificates, login to the vSphere Web Client with a CAAdmins enabled User (administrator@vsphere.local) and navigate to Administration > System Configuration > Nodes > Manage > Certificate Authority
vSphere License Service
The License Service, which is part of the Platform Services Controller, delivers centralized license management and reporting functionality. It provides an inventory of licenses in the vSphere environment, and manages the license assignments for ESXi hosts, vCenter Server systems, and clusters with enabled Virtual SAN. The License Service also manages the license assignments for products that integrate with vSphere, such as vCenter Operations Manager, vCenter Site Recovery Manager, and so on.
If the environment contains multiple Platform Services Controllers that are joined through one vCenter Single Sign-on domain, the licensing inventory is replicated across all Platform Services Controllers.
The License Service supports both, newly installed vSphere 6.0 environments and environments that are upgraded from vSphere 5.x. Due to the architectural changes in vSphere 6.0, you can either manage the licensing data for all assets that are associated with all vCenter Server 6.0 systems in vSphere, or manage the licensing data for individual vCenter Server 5.5 systems or a group of linked vCenter Server 5.5 systems. The licensing interface in the vSphere Web Client 6.0 lets you select between all vCenter Server 6.0 systems and vCenter Server 5.5 systems.
vSphere License Service Upgrade
During the upgrade of the vCenter Server systems that are connected to a Platform Services Controller, their licensing data is transferred to the License Service. The licensing data includes the available licenses and license assignments for hosts, vCenter Server systems, Virtual SAN clusters, and other products that you use with vSphere.
Licensing for vCenter, ESXi Hosts and other Assets
To assign licenses, use the vSphere Web Client and navigate to Administration > Licensing > Licenses
Add licenses by opening the Licenses tab and press the green plus sign. You can add multiple licenses at the same time and provide a description to identify the license later.
Now your licenses are added to the License Management, but you still have to assign it to your asses. To assign licenses, open the Assets tab. In the Asses tab, you can see an overview of all vCenter Servers, Hosts, Clusters and Solutions that are part of the platform. To assign a licenses rightclick the Asset and press Assign License... and select the licenses you want to assign to your asset.
License Reports
You can track the license usage of your vSphere environment by generating reports for the license usage of assets for a certain time period. Assets are hosts, vCenter Server systems, Virtual SAN clusters, and solutions. You can use the license reporting in vSphere for the following tasks:
- View statistics about the license usage and capacity for all products that have been assigned licenses in vSphere for a certain time period.
- Export license usage reports in CSV format for further analysis and processing.
The License Service takes snapshots of the license usage in the vSphere environment every day. A license usage snapshot contains data about the current license assignment and usage. The license usage information that you can view in the license reporting interface contains aggregated statistics from the snapshots that are collected in the period that you select.
The license usage reports that you can export in CSV format contain the raw data from the license usage snapshots that are collected during the selected period. You can analyze the data from CSV reports by aggregating it with third-party tools or scripts.
vSphere Client Comparison
VMware provides two graphical interfaces to manage your platform. The vSphere Web Client is a Web application installed on a machine with network access to your vCenter Server installation. The vSphere Web Client is the primary interface for connecting to and managing vCenter Server instances. The vSphere Client is still available, but since vSphere 5.1 no new features are added
The vSphere Web Client is the primary management inferface. Nevertheless there are some use cases that require the vSphere Client:
- Direct access to hosts, allows administrators to troubleshoot ESXi in the event vCenter Server is unavailable.
- vSphere Update Manager (VUM) remediation. Administrators love VUM and currently the vSphere client is the only way to perform a remediation task.
- Able to troubleshoot virtual machines with hardware version 10 and 11, this allows the vCenter Server virtual machine to take advantage of the latest improvements in virtual hardware while still allowing an administrator to have access to the virtual machine for maintenance tasks.
- The vSphere Client is installed on a Windows machine with network access to your ESXi or vCenter Server system installation. The interface displays slightly different options depending on which type of server you are connected to. A single vCenter Server system or ESXi host can support multiple, simultaneously connected vSphere Clients.
VCP6-DCV Delta Study Guide
Part 1 - vSphere 6 Summary
Part 2 - How to prepare for the Exam?
Part 3 - Installation and Upgrade
Part 4 - ESXi Enhancements
Part 5 - Management Enhancements
Part 6 - Availability Enhancements
Part 7 - Network Enhancements
Part 8 - Storage Enhancements