Vmware VSphere Security ESXi 6.0 V Center Server 6.0.3 Sphere Vcenter 602 En

User Manual: vmware vCenter Server - 6.0.3 - vSphere Security Free User Guide for VMware vCenter Software, Manual

Open the PDF directly: View PDF .
Page Count: 294 [warning: Documents this large are best viewed by clicking the View PDF Link!]

vSphere Security

vSphere Security

Update 2

ESXi 6.0

vCenter Server 6.0

This document supports the version of each product listed and

supports all subsequent versions until the document is

replaced by a new edition. To check for more recent editions of

this document, see http://www.vmware.com/support/pubs.

EN-001949-04

vSphere Security

2 VMware, Inc.

You can ﬁnd the most up-to-date technical documentation on the VMware Web site at:

hp://www.vmware.com/support/

The VMware Web site also provides the latest product updates.

If you have comments about this documentation, submit your feedback to:

docfeedback@vmware.com

VMware, Inc.

3401 Hillview Ave.

Palo Alto, CA 94304

www.vmware.com

Contents

About vSphere Security 7

Updated Information 9

1Security in the vSphere Environment 11

Securing the ESXi Hypervisor 11

Securing vCenter Server Systems and Associated Services 13

Securing Virtual Machines 14

Securing the Virtual Networking Layer 14

Passwords in Your vSphere Environment 16

Security Best Practices and Resources 17

2vSphere Authentication with vCenter Single Sign-On 19

Understanding vCenter Single Sign-On 20

Conguring vCenter Single Sign-On Identity Sources 29

vCenter Server Two-Factor Authentication 36

Using vCenter Single Sign-On as the Identity Provider for Another Service Provider 45

Managing the Security Token Service (STS) 47

Managing vCenter Single Sign-On Policies 51

Managing vCenter Single Sign-On Users and Groups 54

vCenter Single Sign-On Security Best Practices 59

Troubleshooting vCenter Single Sign-On 60

3vSphere Security Certicates 65

Certicate Management Overview 66

Managing Certicates with the Platform Services Controller Web Interface 76

Managing Certicates with the vSphere Certicate Manager Utility 83

Manual Certicate Replacement 92

Managing Certicates and Services with CLI Commands 118

View vCenter Certicates with the vSphere Web Client 133

Set the Threshold for vCenter Certicate Expiration Warnings 133

4vSphere Permissions and User Management Tasks 135

Understanding Authorization in vSphere 136

Understanding the vCenter Server Permission Model 136

Hierarchical Inheritance of Permissions 138

Multiple Permission Seings 139

Managing Permissions for vCenter Components 141

Global Permissions 144

Using Roles to Assign Privileges 147

Best Practices for Roles and Permissions 150

VMware, Inc. 3

Required Privileges for Common Tasks 150

5Securing ESXi Hosts 153

Use Scripts to Manage Host Conguration Seings 154

Congure ESXi Hosts with Host Proles 155

General ESXi Security Recommendations 156

Certicate Management for ESXi Hosts 160

Customizing Hosts with the Security Prole 173

Assigning Permissions for ESXi 187

Using Active Directory to Manage ESXi Users 189

Using vSphere Authentication Proxy 192

Conguring Smart Card Authentication for ESXi 196

ESXi SSH Keys 199

Using the ESXi Shell 201

Modifying ESXi Web Proxy Seings 205

vSphere Auto Deploy Security Considerations 206

Managing ESXi Log Files 206

6Securing vCenter Server Systems 209

vCenter Server Security Best Practices 209

Verify Thumbprints for Legacy ESXi Hosts 213

Verify that SSL Certicate Validation Over Network File Copy Is Enabled 214

vCenter Server TCP and UDP Ports 215

Control CIM-Based Hardware Monitoring Tool Access 216

7Securing Virtual Machines 217

Limit Informational Messages from Virtual Machines to VMX Files 217

Prevent Virtual Disk Shrinking 218

Virtual Machine Security Best Practices 218

8Securing vSphere Networking 227

Introduction to vSphere Network Security 227

Securing the Network with Firewalls 228

Secure the Physical Switch 231

Securing Standard Switch Ports With Security Policies 232

Securing vSphere Standard Switches 232

Secure vSphere Distributed Switches and Distributed Port Groups 234

Securing Virtual Machines with VLANs 234

Creating a Network DMZ on a Single ESXi Host 236

Creating Multiple Networks Within a Single ESXi Host 237

Internet Protocol Security 239

Ensure Proper SNMP Conguration 242

Use Virtual Switches with the vSphere Network Appliance API Only If Required 243

vSphere Networking Security Best Practices 243

9Best Practices Involving Multiple vSphere Components 247

Synchronizing Clocks on the vSphere Network 247

Storage Security Best Practices 250

vSphere Security

4 VMware, Inc.

Verify That Sending Host Performance Data to Guests is Disabled 252

Seing Timeouts for the ESXi Shell and vSphere Web Client 253

10 Dened Privileges 255

Alarms Privileges 256

Auto Deploy and Image Prole Privileges 257

Certicates Privileges 257

Content Library Privileges 258

Datacenter Privileges 259

Datastore Privileges 260

Datastore Cluster Privileges 260

Distributed Switch Privileges 261

ESX Agent Manager Privileges 261

Extension Privileges 262

Folder Privileges 262

Global Privileges 262

Host CIM Privileges 263

Host Conguration Privileges 263

Host Inventory 264

Host Local Operations Privileges 265

Host vSphere Replication Privileges 266

Host Prole Privileges 266

Inventory Service Provider Privileges 267

Inventory Service Tagging Privileges 267

Network Privileges 267

Performance Privileges 268

Permissions Privileges 268

Prole-driven Storage Privileges 269

Resource Privileges 269

Scheduled Task Privileges 270

Sessions Privileges 270

Storage Views Privileges 270

Tasks Privileges 271

Transfer Service Privileges 271

VRM Policy Privileges 271

Virtual Machine Conguration Privileges 271

Virtual Machine Guest Operations Privileges 273

Virtual Machine Interaction Privileges 273

Virtual Machine Inventory Privileges 280

Virtual Machine Provisioning Privileges 281

Virtual Machine Service Conguration Privileges 282

Virtual Machine Snapshot Management Privileges 282

Virtual Machine vSphere Replication Privileges 283

dvPort Group Privileges 283

vApp Privileges 284

vServices Privileges 285

Index 287

Contents

VMware, Inc. 5

vSphere Security

6 VMware, Inc.

About vSphere Security

vSphere Security provides information about securing your vSphere® environment for VMware® vCenter®

Server and VMware ESXi.

To help you protect your vSphere environment, this documentation describes available security features and

the measures that you can take to safeguard your environment from aack.

In addition to this document, VMware publishes a Hardening Guide for each release of vSphere, accessible at

hp://www.vmware.com/security/hardening-guides.html. The Hardening Guide is a spreadsheet with entries

for dierent potential security issues. It includes items for three dierent risk proles. This vSphere Security

document does not include information for Risk Prole 1 (highest security environment such as top-secret

government).

Intended Audience

This information is for experienced Windows or Linux system administrators who are familiar with virtual

machine technology and data center operations.

VMware, Inc. 7

vSphere Security

8 VMware, Inc.

Updated Information

This vSphere Security documentation is updated with each release of the product or when necessary.

This table provides the update history of the vSphere Security documentation.

Revision Description

EN-001949-04 nFixed error with parameter name in “Verify that SSL Certicate Validation Over Network File Copy

Is Enabled,” on page 214.

nAdded information about the location of the service-control command on Windows to

“Managing Certicates and Services with CLI Commands,” on page 118.

EN-001949-03 nAdded information on tag permissions in “Permissions on Tag Objects,” on page 146.

nClaried certicate order in “Generate Certicate Signing Requests with vSphere Certicate Manager

(Intermediate CA),” on page 85.

EN-001949-02 nAdded “Certicate Requirements,” on page 71 explicitly at top level. This information was already

included in prerequisites to some tasks.

nAdded a note about login with the vSphere Client to Chapter 2, “vSphere Authentication with

vCenter Single Sign-On,” on page 19.

nClarication in “Active Directory Identity Source Seings,” on page 32. The system must be joined

to an Active Directory name, and the domain name must be resolvable via DNS.

EN-001949-01 nCorrected the order of certicates in “Generate Certicate Signing Requests with vSphere Certicate

Manager (Intermediate CA),” on page 85.

nUpdated “ESXi Passwords and Account Lockout,” on page 157. Pass phrases are not enabled by

default.

nCorrected steps for accessing the appliance shell in “Use the Command Line to Congure Smart

Card Authentication,” on page 37.

nFix to “Change Your vCenter Single Sign-On Password,” on page 59. If your password expires, you

must contact the administrator.

nUpdated PowerCLI script in “Use Scripts to Manage Host Conguration Seings,” on page 154.

nUpdated information on number of vCenter Server instances in “How vCenter Single Sign-On

Aects Installation,” on page 22.

nSeveral updates to “Use the Command Line to Congure Smart Card Authentication,” on page 37,

“Use the Platform Services Controller Web Interface to Manage Smart Card Authentication,” on

page 40, and “Set Up RSA SecureID Authentication,” on page 43.

nCorrections in “vCenter Server TCP and UDP Ports,” on page 215. For example Port 903 and port

5900-5964 are used on the host, not on the vCenter Server system, and some other ports such as 9090

are only used internally.

nRemoved information about DSA keys from “Upload an SSH Key Using a vifs Command,” on

page 200 .

nUpdated “Managing the Security Token Service (STS),” on page 47 to include the procedure for

generating a new STS signing certicate.

EN-001949-00 Initial release.

VMware, Inc. 9

vSphere Security

10 VMware, Inc.

Security in the vSphere Environment 1

The components of a vSphere environment are secured out of the box by a number of features such as

certicates, authorization, a rewall on each ESXi, limited access, and so on. You can modify the default

setup in many ways - for example, you can set permissions on vCenter objects, open rewall ports, or

change the default certicates. This results in maximum exibility in securing vCenter Server systems, ESXi

hosts, and virtual machines.

A high level overview of dierent areas of vSphere that require aention helps you plan your security

strategy. You also benet from additional vSphere Security resources on the VMware website.

This chapter includes the following topics:

n“Securing the ESXi Hypervisor,” on page 11

n“Securing vCenter Server Systems and Associated Services,” on page 13

n“Securing Virtual Machines,” on page 14

n“Securing the Virtual Networking Layer,” on page 14

n“Passwords in Your vSphere Environment,” on page 16

n“Security Best Practices and Resources,” on page 17

Securing the ESXi Hypervisor

The ESXi hypervisor is secured out of the box. You can further protect ESXi hosts by using lockdown mode,

and other built-in features. If you set up a reference host and make changes to all hosts based on that host's

host proles, or if you perform scripted management, you further protect your environment by assuring

changes apply to all hosts.

Use the following features, discussed in detail in this guide, to enhance protection of ESXi hosts that are

managed by vCenter Server. See also the Security of the VMware vSphere Hypervisor white paper.

Limit ESXi Access By default, the ESXi Shell and SSH services are not running and only the root

user can log in to the Direct Console User Interface (DCUI). If you decide to

enable ESXi or SSH access, you can set timeouts to limit the risk of

unauthorized access.

VMware, Inc. 11

Users who can access the ESXi host must have permissions to manage the

host. You set permissions on the host object from vCenter Server that

manages the host.

Use Named Users and

Least Privilege

Many tasks can be performed by the root user by default. Instead of allowing

administrators to log in to the ESXi host using the root user account, you can

apply dierent host conguration privileges to dierent named users from

the vCenter Server permissions management interface. You can create a

custom roles, assign privileges to the role, and associate the role with a

named user and an ESXi host object from the vSphere Web Client.

In a single host scenario, you manage users directly. See the vSphere

Administration with the vSphere Client documentation.

Minimize the Number of

Open ESXi Firewall

Ports

By default, rewall ports on your ESXi host are opened only when you start a

corresponding service. You can use the vSphere Web Client or ESXCLI or

PowerCLI commands to check and manage rewall port status.

See “ESXi Firewall Conguration,” on page 173.

Automate ESXi Host

Management

Because it is often important that dierent hosts in the same data center are

in sync, use scripted installation or vSphere Auto Deploy to provision hosts.

You can manage the hosts using scripts. An alternative to scripted

management are host proles. You set up a reference host, export the host

prole, and apply the host prole to your host. You can apply the host prole

directly or as part of provisioning with Auto Deploy.

See “Use Scripts to Manage Host Conguration Seings,” on page 154 and

see the vSphere Installation and Setup for information about vSphere Auto

Deploy.

Take Advantage of

Lockdown Mode

In lockdown mode, ESXi hosts can be accessed only through vCenter Server

by default. Starting with vSphere 6.0, you can select strict lockdown mode or

normal lockdown mode, and you can dene Exception Users to allow direct

access to service accounts such as backup agents.

See “Lockdown Mode,” on page 180.

Check VIB Package

Integrity

Each VIB package has an associated acceptance level. You can add a VIB to

an ESXi host only if the acceptance level is the same or beer than the

acceptance level of the host. You cannot add a CommunitySupported or

PartnerSupported VIB to a host unless you explicitly change the host's

acceptance level.

See “Check the Acceptance Levels of Hosts and VIBs,” on page 186.

Manage ESXi

Certificates

In vSphere 6.0 and later, the VMware Certicate Authority (VMCA)

provisions each ESXi host with a signed certicate that has VMCA as the root

certicate authority by default. If company policy requires it, you can replace

the existing certicates with certicates that are signed by a third-party CA.

See “Certicate Management for ESXi Hosts,” on page 160

Smart Card

Authentication

Starting with vSphere 6.0, ESXi supports smart card authentication as an

option instead of user name and password authentication.

vSphere Security

12 VMware, Inc.

See “Conguring Smart Card Authentication for ESXi,” on page 196.

ESXi Account Lockout Starting with vSphere 6.0, account locking is supported for access through

SSH and through the vSphere Web Services SDK. The Direct Console

Interface (DCUI) and the ESXi Shell do not support account lockout. By

default, a maximum of ten failed aempts is allowed before the account is

locked. The account is unlocked after two minutes by default.

See “ESXi Passwords and Account Lockout,” on page 157.

Security considerations for standalone hosts are similar, though the management tasks might dier. See the

vSphere Administration with the vSphere Client documentation.

Securing vCenter Server Systems and Associated Services

Your vCenter Server system and associated services are protected by authentication through vCenter Single

Sign-On and by authorization through the vCenter Server permissions model. You can modify the default

behavior, and you can take additional steps to protect access to your environment.

As you protect your vSphere environment, consider that all services that are associated with the

vCenter Server instances must be protected. In some environments, you might protect several

vCenter Server instances and one or more Platform Services Controller instances.

Harden All vCenter Host

Machines

The rst step in protecting your vCenter environment is hardening each

machine on which vCenter Server or an associated service runs. Similar

considerations apply to a physical machine or a virtual machine. Always

install the latest security patches for your operating system and follow

industry standard best practices to protect the host machine.

Learn about the vCenter

Certificate Model

By default, the VMware Certicate Authority provisions each ESXi host, each

machine in the environment, and each solution user with a certicate signed

by VMCA. The environment works out of the box, but if company policy

requires it, you can change the default behavior. See Chapter 3, “vSphere

Security Certicates,” on page 65.

For additional protection, be sure to explicitly remove expired or revoked

certicates and failed installations.

Configure vCenter

Single Sign-On

vCenter Server and associated services are protected by the vCenter Single

Sign-On authentication framework. When you rst install the software, you

specify a password for the administrator@vsphere.local user, and only that

domain is available as an identity source. You can add other identity sources,

either Active Directory or LDAP, and set a default identity source. Going

forward, users who can authenticate to an identity source can view objects

and perform tasks if they are authorized to do so. See Chapter 2, “vSphere

Authentication with vCenter Single Sign-On,” on page 19.

Assign Roles to Users

or Groups

For beer logging, associate each permission you give on an object with a

named user or group and a predened role or custom role. The vSphere 6.0

permissions model allows great exibility through multiple ways of

authorizing users or groups. See “Understanding Authorization in vSphere,”

on page 136 and “Required Privileges for Common Tasks,” on page 150.

Be sure to restrict administrator privileges and the use of the administrator

role. If possible, do not use the anonymous Administrator user.

Set up NTP Set up NTP for each node in your environment. The certicate infrastructure

requires an accurate time stamp and does not work correctly if the nodes are

out of sync.

Chapter 1 Security in the vSphere Environment

VMware, Inc. 13

See “Synchronizing Clocks on the vSphere Network,” on page 247.

Securing Virtual Machines

To secure your virtual machines, keep the guest operating systems patched and protect your environment

just as you would protect a physical machine. Consider disabling unnecessary functionality, minimize the

use of the virtual machine console, and follow other best practices.

Protect the Guest

Operating System

To protect your guest operating system, make sure that it uses the most

recent patches and, if appropriate, anti-spyware and anti-malware programs.

See the documentation from your guest operating system vendor and,

potentially, other information available in books or on the Internet.

Disable Unnecessary

Functionality

Check that unnecessary functionality is disabled to minimize potential points

of aack. Many of the features that are used infrequently are disabled by

default. Remove unnecessary hardware and disable certain features such as

HFSG or copy and paste between the virtual machine and a remote console.

See “Disable Unnecessary Functions Inside Virtual Machines,” on page 221.

Use Templates and

Scripted Management

Virtual machine templates allow you to set up the operating system so it

meets your requirements, and to then create additional virtual machines with

the same seings.

If you want to change seings after initial deployment, consider using

scripts, for example, PowerCLI. This documentation explains many tasks by

using the vSphere Web Client to beer illustrate the process, but scripts help

you keep your environment consistent. In large environments, you can group

virtual machines into folders to optimize scripting.

See “Use Templates to Deploy Virtual Machines,” on page 219. See vSphere

Virtual Machine Administration for details.

Minimize Use of the

Virtual Machine Console

The virtual machine console provides the same function for a virtual

machine that a monitor on a physical server provides. Users with access to

the virtual machine console have access to virtual machine power

management and removable device connectivity controls, which might allow

a malicious aack on a virtual machine.

Securing the Virtual Networking Layer

The virtual networking layer includes virtual network adapters, virtual switches, distributed virtual

switches, and ports and port groups. ESXi relies on the virtual networking layer to support communications

between virtual machines and their users. In addition, ESXi uses the virtual networking layer to

communicate with iSCSI SANs, NAS storage, and so forth.

vSphere includes the full array of features necessary for a secure networking infrastructure. You can secure

each element of the infrastructure, such as virtual switches, distributed virtual switches, virtual network

adapters, and so on separately. In addition, consider the following guidelines, discussed in more detail in

Chapter 8, “Securing vSphere Networking,” on page 227.

Isolate Network Traffic Isolation of network trac is essential to a secure ESXi environment.

Dierent networks require dierent access and level of isolation. A

management network isolates client trac, command-line interface (CLI) or

API trac, and third-party software trac from normal trac. This network

should be accessible only by system, network, and security administrators.

vSphere Security

14 VMware, Inc.

See “ESXi Networking Security Recommendations,” on page 159.

Use Firewalls to Secure

Virtual Network

Elements

You can open and close rewall ports and secure each element in the virtual

network separately. Firewall rules associate services with corresponding

rewalls and can open and close the ESXi rewall according to the status of

the service.

See “ESXi Firewall Conguration,” on page 173.

Consider Network

Security Policies

Networking security policy provides protection of trac against MAC

address impersonation and unwanted port scanning. The security policy of a

standard or distributed switch is implemented in Layer 2 (Data Link Layer)

of the network protocol stack. The three elements of the security policy are

promiscuous mode, MAC address changes, and forged transmits.

See the vSphere Networking documentation for instructions.

Secure Virtual Machine

Networking

The methods you use to secure a virtual machine network depend on which

guest operating system is installed, whether the virtual machines operate in a

trusted environment, and a variety of other factors. Virtual switches and

distributed virtual switches provide a substantial degree of protection when

used with other common security practices, such as installing rewalls.

See Chapter 8, “Securing vSphere Networking,” on page 227.

Consider VLANs to

Protect Your

Environment

ESXi supports IEEE 802.1q VLANs, which you can use to further protect the

virtual machine network or storage conguration. VLANs let you segment a

physical network so that two machines on the same physical network cannot

send packets to or receive packets from each other unless they are on the

same VLAN.

See “Securing Virtual Machines with VLANs,” on page 234.

Secure Connections to

Virtualized Storage

A virtual machine stores operating system les, program les, and other data

on a virtual disk. Each virtual disk appears to the virtual machine as a SCSI

drive that is connected to a SCSI controller. A virtual machine is isolated

from storage details and cannot access the information about the LUN where

its virtual disk resides.

The Virtual Machine File System (VMFS) is a distributed le system and

volume manager that presents virtual volumes to the ESXi host. You are

responsible for securing the connection to storage. For example, if you are

using iSCSI storage, you can set up your environment to use CHAP and, if

required by company policy, mutual CHAP by using the vSphere Web Client

or CLIs.

See “Storage Security Best Practices,” on page 250.

Evaluate the Use of

IPSec

ESXi supports IPSec over IPv6. You cannot use IPSec over IPv4.

See “Internet Protocol Security,” on page 239.

In addition, evaluate whether VMware NSX for vSphere is a good solution for securing the networking layer

in your environment.

Chapter 1 Security in the vSphere Environment

VMware, Inc. 15

Passwords in Your vSphere Environment

Password restrictions, lockout, and expiration in your vSphere environment depend on the system that the

user targets, who the user is, and how policies are set.

ESXi Passwords

ESXi password restrictions are determined by the Linux PAM module pam_passwdqc. See “ESXi Passwords

and Account Lockout,” on page 157.

Passwords for vCenter Server and Other vCenter Services

vCenter Single Sign-On manages authentication for all users who log in to vCenter Server and other vCenter

services. The password restrictions, lockout, and expiration depend on the user's domain and on who the

user is.

administrator@vsphere.

local

The password for administrator@vsphere.local user, or the

administrator@mydomain user if you selected a dierent domain during

installation, does not expire and is not subject to the lockout policy. In all

other regards, the password must follows the restrictions set in the vCenter

Single Sign-On password policy. See “Edit the vCenter Single Sign-On

Password Policy,” on page 51.

If you forget the password for this users, search the VMware Knowledge

Base system for information on reseing this password.

Other vsphere.local

users

The passwords for other vsphere.local users, or users of the local domain you

specied during installation, must follow the restrictions set by the vCenter

Single Sign-On password policy and lockout policy. See “Edit the vCenter

Single Sign-On Password Policy,” on page 51 and “Edit the vCenter Single

Sign-On Lockout Policy,” on page 52. These passwords expire after 90 days

by default, though administrators can change the expiration as part of the

password policy.

If a user forgets their vsphere.local password, an administrator user can reset

the password using the dir-cli command.

Other Users Password restrictions, lockout, and expiration for all other users are

determined by the domain (identity source) to which the user can

authenticate.

vCenter Single Sign-On supports one default identity source, and users can

determines the password parameters. If users want to log in as a user in a

non-default domain, they can include the domain name, that is, specify

user@domain or domain\user. The domains password parameters apply in this

case as well.

Passwords for vCenter Server Appliance Direct Console User Interface Users

The vCenter Server Appliance is a precongured Linux-based virtual machine, which is optimized for

running vCenter Server and the associated services on Linux.

When you deploy the vCenter Server Appliance, you specify a password for the root user of the appliance

Linux operating system and a password for the administrator@vsphere.local user. You can change the root

user password and perform other vCenter Server Appliance local user management tasks from the Direct

Console User Interface. See vCenter Server Appliance Conguration.

vSphere Security

16 VMware, Inc.

Security Best Practices and Resources

If you follow best practices, your ESXi and vCenter Server can be as secure as or even more secure than an

environment that does not include virtualization.

This manual includes best practices for the dierent components of your vSphere infrastructure.

Table 1‑1. Security Best Practices

vSphere component Resource

ESXi host “ESXi Security Best Practices,” on page 198

vCenter Server system “vCenter Server Security Best Practices,” on page 209

Virtual machine “Virtual Machine Security Best Practices,” on page 218

vSphere Networking “vSphere Networking Security Best Practices,” on page 243

This manual is only one of the sources you need to ensure a secure environment.

VMware security resources, including security alerts and downloads, are available on the Web.

Table 1‑2. VMware Security Resources on the Web

Topic Resource

VMware security policy, up-to-date security

alerts, security downloads, and focus

discussions of security topics.

hp://www.vmware.com/go/security

Corporate security response policy hp://www.vmware.com/support/policies/security_response.html

VMware is commied to helping you maintain a secure environment.

Security issues are corrected in a timely manner. The VMware Security

Response Policy states our commitment to resolve possible

vulnerabilities in our products.

Third-party software support policy hp://www.vmware.com/support/policies/

VMware supports a variety of storage systems, software agents such as

backup agents, system management agents, and so forth. You can nd

lists of agents, tools, and other software that supports ESXi by

searching hp://www.vmware.com/vmtn/resources/ for ESXi

compatibility guides.

The industry oers more products and congurations than VMware

can test. If VMware does not list a product or conguration in a

compatibility guide, Technical Support will aempt to help you with

any problems, but cannot guarantee that the product or conguration

can be used. Always evaluate security risks for unsupported products

or congurations carefully.

Compliance and security standards, as well as

partner solutions and in-depth content about

virtualization and compliance

hp://www.vmware.com/go/compliance

Information on security certications and

validations such as CCEVS and FIPS for

dierent versions of the components of

vSphere.

hps://www.vmware.com/support/support-

resources/certications.html

Hardening guides for dierent versions of

vSphere and other VMware products.

hps://www.vmware.com/support/support-resources/hardening-

guides.html

Security of the VMware vSphere Hypervisor white

paper

hp://www.vmware.com/les/pdf/techpaper/vmw-wp-secrty-vsphr-

hyprvsr-uslet-101.pdf

Chapter 1 Security in the vSphere Environment

VMware, Inc. 17

vSphere Security

18 VMware, Inc.

vSphere Authentication with vCenter

Single Sign-On 2

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 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 trac 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 Certicate Authority, License Service,

and Lookup Service. See vSphere Installation and Setup for details on the Platform Services Controller.

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

authenticate with a certicate. For information on replacing solution user certicates, see Chapter 3,

“vSphere Security Certicates,” on page 65.

After a user can authenticate with vCenter Single Sign-On, you can authorize the user to perform certain

tasks. In most cases, you assign vCenter Server privileges, but vSphere includes other permission models.

See “Understanding Authorization in vSphere,” on page 136.

N If you want to enable an Active Directory user to log in to a vCenter Server instance by using the

vSphere Client with SSPI, you must join the vCenter Server instance to the Active Directory domain. For

information about joining a vCenter Server Appliance with an external Platform Services Controller to an

Active Directory domain, see the VMware knowledge base article at hp://kb.vmware.com/kb/2118543.

This chapter includes the following topics:

n“Understanding vCenter Single Sign-On,” on page 20

n“Conguring vCenter Single Sign-On Identity Sources,” on page 29

n“vCenter Server Two-Factor Authentication,” on page 36

n“Using vCenter Single Sign-On as the Identity Provider for Another Service Provider,” on page 45

n“Managing the Security Token Service (STS),” on page 47

n“Managing vCenter Single Sign-On Policies,” on page 51

n“Managing vCenter Single Sign-On Users and Groups,” on page 54

n“vCenter Single Sign-On Security Best Practices,” on page 59

n“Troubleshooting vCenter Single Sign-On,” on page 60

VMware, Inc. 19

Understanding vCenter Single Sign-On

To eectively manage vCenter Single Sign-On, you need to understand the underlying architecture and how

it aects installation and upgrades.

vCenter Single Sign-On 6.0 Domains and Sites

(hp://link.brightcove.com/services/player/bcpid2296383276001?

bctid=ref:video_sso_6_domains_sites)

How vCenter Single Sign-On Protects Your Environment

vCenter Single Sign-On allows vSphere components to communicate with each other through a secure token

mechanism instead of requiring users to authenticate separately with each component.

vCenter Single Sign-On uses a combination of STS (Security Token Service), SSL for secure trac, and

authentication of human users through Active Directory or OpenLDAP and of solution users through

certicates.

vCenter Single Sign-On Handshake for Human Users

The following illustration shows the handshake for human users.

Figure 2‑1. vCenter Single Sign-On Handshake for Human Users

Kerberos

vSphere Web Client

VMware

Directory

Service

vCenter

Server

vCenter Single

Sign-On

For solution users, the interaction proceeds as follows:

1 The solution user aempts to connect to a vCenter service,

2 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 certicate.

3 If the certicate is valid, vCenter Single Sign-On assigns a SAML token (bearer token) to the solution

user. The token is signed by vCenter Single Sign-On.

4 The solution user is then redirected to vCenter Single Sign-On and can perform tasks based on its

permissions.

5 The next time the solution user has to authenticate, it can use the SAML token to log in to

vCenter Server.

By default, this handshake is automatic because VMCA provisions solution users with certicates during

startup. If company policy requires third-party CA-signed certicates, you can replace the solution user

certicates with third-party CA-signed certicates. If those certicates are valid, vCenter Single Sign-On

assigns a SAML token to the solution user. See “Use Third-Party Certicates With vSphere,” on page 112.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 21

vCenter Single Sign-On Components

vCenter Single Sign-On includes the Security Token Service (STS), an administration server, and vCenter

Lookup Service, as well as the VMware Directory Service (vmdir). The VMware Directory Service is also

used for certicate management.

During installation, the components are deployed as part an embedded deployment, or as part of the

Platform Services Controller.

STS (Security Token

Service)

The STS service issues Security Assertion Markup Language (SAML) tokens.

These security tokens represent the identity of a user in one of the identity

source types supported byvCenter Single Sign-On. 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 Sign-

On supports without authenticating again to each service.

The vCenter Single Sign-On service signs all tokens with a signing certicate,

and stores the token signing certicate on disk. The certicate for the service

itself is also stored on disk.

Administration server The administration server allows users with administrator privileges to

vCenter Single Sign-On to congure the vCenter Single Sign-On server and

manage users and groups from the vSphere Web Client. Initially, only the

user administrator@your_domain_name has these privileges. In vSphere 5.5

this user was administrator@vsphere.local. With vSphere 6.0, you can change

the vSphere domain when you install vCenter Server or deploy the

vCenter Server Appliance with a new Platform Services Controller. Do not

name the domain name with your Microsoft Active Directory or OpenLDAP

domain name.

VMware Directory

Service (vmdir)

The VMware Directory service (vmdir) is associated with the domain you

specify during installation and is included in each embedded deployment

and on each Platform Services Controller. This service is a multi-tenanted,

multi-mastered directory service that makes an LDAP directory available on

port 389. The service still uses port 11711 for backward compatibility with

vSphere 5.5 and earlier systems.

If your environment includes more than one instance of the

Platform Services Controller, an update of vmdir content in one vmdir

instance is propagated to all other instances of vmdir.

Starting with vSphere 6.0, the VMware Directory Service stores not only

vCenter Single Sign-On information but also certicate information.

Identity Management

Service

Handles identity sources and STS authentication requests.

How vCenter Single Sign-On Affects Installation

Starting with version 5.1, vSphere includes a vCenter Single Sign-On service as part of the vCenter Server

management infrastructure. This change aects vCenter Server installation.

Authentication with vCenter Single Sign-On makes vSphere more secure because the vSphere software

components communicate with each other by using a secure token exchange mechanism, and all other users

also authenticate with vCenter Single Sign-On.

vSphere Security

22 VMware, Inc.

Starting with vSphere 6.0, vCenter Single Sign-On is either included in an embedded deployment, or part of

the Platform Services Controller. The Platform Services Controller contains all of the services that are

necessary for the communication between vSphere components including vCenter Single Sign-On, VMware

Certicate Authority, VMware Lookup Service, and the licensing service.

The order of installation is important.

First installation If your installation is distributed, you must install the

Platform Services Controller before you install vCenter Server or deploy the

vCenter Server Appliance. For an embedded deployment the correct

installation order happens automatically.

Subsequent

installations

For approximately up to four vCenter Server instances, one

Platform Services Controller can serve your entire vSphere environment. You

can connect the new vCenter Server instances to the same

Platform Services Controller. For more than approximately four

vCenter Server instances, you can install an additional

Platform Services Controller for beer performance. The vCenter Single Sign-

On service on each Platform Services Controller synchronizes authentication

data with all other instances. The precise number depends on how heavily

the vCenter Server instances are being used and on other factors.

How vCenter Single Sign-On Affects Upgrades

If you upgrade a Simple Install environment to a vCenter Server 6 embedded deployment, upgrade is

seamless. If you upgrade a custom installation, the vCenter Single Sign-On service is part of the

Platform Services Controller after the upgrade. Which users can log in to vCenter Server after an upgrade

depends on the version that you are upgrading from and the deployment conguration.

As part of the upgrade, you can dene a dierent vCenter Single Sign-On domain name to be used instead

of vsphere.local.

Upgrade Paths

The result of the upgrade depends on what installation options you had selected, and what deployment

model you are upgrading to.

Table 2‑1. Upgrade Paths

Source Result

vSphere 5.5 and earlier Simple Install vCenter Server with embedded

Platform Services Controller.

vSphere 5.5 and earlier Custom Install If vCenter Single Sign-On was on a dierent node than

vCenter Server, an environment with an external

Platform Services Controller results.

If vCenter Single Sign-On was on the same node as

vCenter Server, but other services are on dierent nodes,

an environment with an embedded

Platform Services Controller results.

If the custom installation included multiple replicating

vCenter Single Sign-On servers, an environment with

multiple replicating Platform Services Controller instances

results.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 23

Who Can Log In After Upgrade of a Simple Install

If you upgrade an environment that you provisioned using the Simple Install option, the result is always an

installation with an embedded Platform Services Controller. Which users are authorized to log in depends

on whether the source environment includes vCenter Single Sign-On.

Table 2‑2. Login Privileges After Upgrade of Simple Install Environment

Source version Login access for Notes

vSphere 5.0 Local operating system users

administrator@vsphere.local

You might be prompted for the

administrator of the root folder

in the vSphere inventory

hierarchy during installation

because of changes in user stores.

If your previous installation

supported Active Directory

users, you can add the Active

Directory domain as an identity

source.

vSphere 5.1 Local operating system users

administrator@vsphere.local

Admin@SystemDomain

Starting with vSphere 5.5,

vCenter Single Sign-On supports

only one default identity source.

You can set the default identity

source.

Users in a non-default domain

can specify the domain when

they log in (DOMAIN\user or

user@DOMAIN).

vSphere 5.5 administrator@vsphere.local or the administrator

of the domain that you specied during upgrade.

All users from all identity sources can log in as

before.

If you upgrade from vSphere 5.0, which does not include vCenter Single Sign-On, to a version that includes

vCenter Single Sign-On, local operating system users become far less important than the users in a directory

service such as Active Directory. As a result, it is not always possible, or even desirable, to keep local

operating system users as authenticated users.

Who Can Log In After Upgrade of a Custom Installation

If you upgrade an environment that you provisioned using the Custom Install option, the result depends on

your initial choices:

nIf vCenter Single Sign-On was on the same node as the vCenter Server system, the result is an

installation with an embedded Platform Services Controller.

nIf vCenter Single Sign-On was on a dierent node than the vCenter Server system, the result is an

installation with an external Platform Services Controller.

nIf you upgrade from vSphere 5.0, you can select an external or embedded Platform Services Controller

as part of the upgrade process.

vSphere Security

24 VMware, Inc.

Table 2‑3. Login Privileges After Upgrade of Custom Install Environment

Source version Login access for Notes

vSphere 5.0 vCenter Single Sign-On recognizes local

operating system users for the machine where

the Platform Services Controller is installed, but

not for the machine where vCenter Server is

installed.

N Using local operating users for

administration is not recommended, especially in

federated environments.

administrator@vsphere.local can log in to

vCenter Single Sign-On and each vCenter Server

instance as an administrator user.

If your 5.0 installation supported

Active Directory users, those

users no longer have access after

the upgrade. You can add the

Active Directory domain as an

identity source.

vSphere 5.1 or vSphere 5.5 vCenter Single Sign-On recognizes local

operating system users for the machine where

the Platform Services Controller is installed, but

not for the machine where vCenter Server is

installed.

N Using local operating users for

administration is not recommended, especially in

federated environments.

administrator@vsphere.localcan log in to vCenter

Single Sign-On and each vCenter Server instance

as an administrator user.

For upgrades from vSphere 5.1

Admin@SystemDomain has the same privileges

as administrator@vsphere.local.

Starting with vSphere 5.5,

vCenter Single Sign-On supports

only one default identity source.

You can set the default identity

source.

Users in a non-default domain

can specify the domain when

they log in (DOMAIN\user or

user@DOMAIN).

Using vCenter Single Sign-On with vSphere

When a user logs in to a vSphere component or when a vCenter Server solution user accesses another

vCenter Server service, vCenter Single Sign-On performs authentication. Users must be authenticated with

vCenter Single Sign-On and have the necessary privileges for interacting with vSphere objects.

vCenter Single Sign-On authenticates both solution users and other users.

nSolution users represent a set of services in your vSphere environment. During installation, VMCA

assigns a certicate to each solution user by default. The solution user uses that certicate to

authenticate to vCenter Single Sign-On. vCenter Single Sign-On gives the solution user a SAML token,

and the solution user can then interact with other services in the environment.

nWhen other users log in to the environment, for example, from the vSphere Web Client, vCenter Single

Sign-On prompts for a user name and password. If vCenter Single Sign-On nds a user with those

credentials in the corresponding identity source, it assigns the user a SAML token. The user can now

access other services in the environment without being prompted to authenticate again.

Which objects the user can view, and what a user can do, is usually determined by vCenter Server

permission seings. vCenter Server administrators assign those permissions from the Manage >

Permissions interface in the vSphere Web Client, not through vCenter Single Sign-On. See Chapter 4,

“vSphere Permissions and User Management Tasks,” on page 135.

vCenter Single Sign-On and vCenter Server Users

Using the vSphere Web Client, users authenticate to vCenter Single Sign-On by entering their credentials on

the vSphere Web Client login page. After connecting to vCenter Server, authenticated users can view all

vCenter Server instances or other vSphere objects for which their role gives them privileges. No further

authentication is required. See Chapter 4, “vSphere Permissions and User Management Tasks,” on page 135.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 25

After installation, the administrator@vsphere.local user has administrator access to both vCenter Single

Sign-On and vCenter Server. That user can then add identity sources, set the default identity source, and

manage users and groups in the vCenter Single Sign-On domain (vsphere.local).

All users that can authenticate to vCenter Single Sign-On can reset their password, even if the password has

expired, as long as they know the password. See “Change Your vCenter Single Sign-On Password,” on

page 59. Only vCenter Single Sign-On administrators can reset the password for users who no longer have

their password.

vCenter Single Sign-On Administrator Users

The vCenter Single Sign-On administrative interface is accessible from the vSphere Web Client.

To congure vCenter Single Sign-On and manage vCenter Single Sign-On users and groups, the user

administrator@vsphere.local or a user in the vCenter Single Sign-On Administrators group must log in to

the vSphere Web Client. Upon authentication, that user can access the vCenter Single Sign-On

administration interface from the vSphere Web Client and manage identity sources and default domains,

specify password policies, and perform other administrative tasks. See “Conguring vCenter Single Sign-On

Identity Sources,” on page 29.

N You cannot rename the administrator@vsphere.local user. For improved security, consider creating

additional named users in the vsphere.local domain and assigning them administrative privileges. You can

then stop using administrator@vsphere.local.

Authentication in Different Versions of vSphere

If a user connects to a vCenter Server system version 5.0.x or earlier, vCenter Server authenticates the user

by validating the user against an Active Directory domain or against the list of local operating system users.

In vCenter Server 5.1 and later, users authenticate through vCenter Single Sign-On.

N You cannot use the vSphere Web Client to manage vCenter Server version 5.0 or earlier. Upgrade

vCenter Server to version 5.1 or later.

ESXi Users

ESXi is not integrated with vCenter Single Sign-On. You add the ESXi host to an Active Directory domain

explicitly. See “Congure a Host to Use Active Directory,” on page 190.

You can still create local ESXi users with the vSphere Client, vCLI, or PowerCLI. vCenter Server is not aware

of users that are local to ESXi and ESXi is not aware of vCenter Server users.

N Manage permissions for ESXi hosts through vCenter Server if possible.

How to Log In to vCenter Server Components

When a user logs in to a vCenter Server system from the vSphere Web Client, the login behavior depends on

whether the user is in the default domain, that is, the domain that is set as the default identity source.

nUsers who are in the default domain can log in with their user name and password.

nUsers who are in a domain that has been added to vCenter Single Sign-On as an identity source but is

not the default domain can log in to vCenter Server but must specify the domain in one of the following

ways.

nIncluding a domain name prex, for example, MYDOMAIN\user1

nIncluding the domain, for example, user1@mydomain.com

vSphere Security

26 VMware, Inc.

nUsers who are in a domain that is not a vCenter Single Sign-On identity source cannot log in to

vCenter Server. If the domain that you add to vCenter Single Sign-On is part of a domain hierarchy,

Active Directory determines whether users of other domains in the hierarchy are authenticated or not.

N If your environment includes an Active Directory hierarchy, see VMware Knowledge Base article

2064250 for details on supported and unsupported setups.

Groups in the vsphere.local Domain

The vsphere.local domain includes several predened groups. Assign users to one of those groups to be able

to perform the corresponding actions.

For all objects in the vCenter Server hierarchy, permissions are assigned by pairing a user and a role with the

object. For example, you can select a resource pool and give a group of users read privileges to that resource

pool by giving them the corresponding role.

For some services that are not managed by vCenter Server directly, privileges are determined by

membership to one of the vCenter Single Sign-On groups. For example, a user who is a member of the

Administrator group can manage vCenter Single Sign-On. A user who is a member of the CAAdmins group

can manage the VMware Certicate Authority, and a user who is in the LicenseService.Administrators

group can manage licenses.

The following groups are predened in vsphere.local.

N Many of these groups are internal to vsphere.local or give users high-level administrative privileges.

Add users to any of these groups only after careful consideration of the risks.

N Do not delete any of the predened groups in the vsphere.local domain. If you do, errors with

authentication or certicate provisioning might result.

Table 2‑4. Groups in the vsphere.local Domain

Privilege Description

Users Users in the vsphere.local domain.

SolutionUsers Solution users group vCenter services. Each solution user authenticates

individually to vCenter Single Sign-On with a certicate. By default, VMCA

provisions solution users with certicates. Do not add members to this group

explicitly.

CAAdmins Members of the CAAdmins group have administrator privileges for VMCA.

Adding members to these groups is not usually recommended.

DCAdmins Members of the DCAdmins group can perform Domain Controller

Administrator actions on VMware Directory Service.

N Do not manage the domain controller directly. Instead, use the vmdir CLI

or vSphere Web Client to perform corresponding tasks.

SystemConguration.BashShellAdmi

nistrators

This group is available only for vCenter Server Appliance deployments.

A user in this group can enable and disable access to the BASH shell. By default

a user who connects to the vCenter Server Appliance with SSH can access only

commands in the restricted shell. Users who are in this group can access the

BASH shell.

ActAsUsers Members of Act-As Users are allowed to get actas tokens from vCenter Single

Sign-On.

ExternalIPDUsers This group is not used by vSphere. This group is needed in conjunction with

VMware vCloud Air.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 27

Table 2‑4. Groups in the vsphere.local Domain (Continued)

Privilege Description

SystemConguration.Administrators Members of the SystemConguration.Administrators group can view and

manage the system conguration in the vSphere Web Client. These users can

view, start and restart services, troubleshoot services, see the available nodes and

manage those nodes.

DCClients This group is used internally to allow the management node access to data in

VMware Directory Service.

N Do not modify this group. Any changes might compromise your

certicate infrastructure.

ComponentManager.Administrators Members of the ComponentManager.Administrators group can invoke

component manager APIs that register or unregister services, that is, modify

services. Membership in this group is not necessary for read access on the

services.

LicenseService.Administrators Members of LicenseService.Administrators have full write access to all licensing

related data and can add, remove, assign, and unassign serial keys for all

product assets registered in licensing service.

Administrators Administrators of the VMware Directory Service (vmdir). Members of this group

can perform vCenter Single Sign-On administration tasks. Adding members to

this group is not usually recommended.

vCenter Server Password Requirements and Lockout Behavior

To manage your environment, you must be aware of the vCenter Single Sign-On password policy, of

vCenter Server passwords, and of lockout behavior.

vCenter Single Sign-On Administrator Password

The password for administrator@vsphere.local must meet the following requirements:

nAt least 8 characters

nAt least one lowercase character

nAt least one numeric character

nAt least one special character

The password for administrator@vsphere.local cannot be more than 20 characters long. Only visible ASCII

characters are allowed. That means, for example, that you cannot use the space character.

vCenter Server Passwords

In vCenter Server, password requirements are dictated by vCenter Single Sign-On or by the congured

identity source, which can be Active Directory, OpenLDAP, or the local operating system for the vCenter

Single Sign-On server (not recommended).

Lockout Behavior

Users are locked out after a preset number of consecutive failed aempts. By default, users are locked out

after ve consecutive failed aempt in three minutes and a locked account is unlocked automatically after

ve minutes. You can change these defaults using the lockout policy. See “Edit the vCenter Single Sign-On

Lockout Policy,” on page 52.

Starting with vSphere 6.0, the system domain administrator, administrator@vsphere.local by default, is not

aected by the lockout policy.

Any user can change their password by using the dir-cli password change command. If a user forgets the

password, the administrator can reset the password by using the dir-cli password reset command.

vSphere Security

28 VMware, Inc.

See “ESXi Passwords and Account Lockout,” on page 157 for a discussion of passwords of ESXi local users.

Configuring vCenter Single Sign-On Identity Sources

When a user logs in, vCenter Single Sign-On checks in the default identity source whether that user can

authenticate. You can add identity sources, remove identity sources, and change the default.

You congure vCenter Single Sign-On from the vSphere Web Client. To congure vCenter Single Sign-On,

you must have vCenter Single Sign-On administrator privileges. Having vCenter Single Sign-On

administrator privileges is dierent from having the Administrator role on vCenter Server or ESXi. By

default, only the user administrator@vsphere.local has administrator privileges on the vCenter Single Sign-

On server in a new installation.

nIdentity Sources for vCenter Server with vCenter Single Sign-On on page 29

You can use identity sources to aach one or more domains to vCenter Single Sign-On. A domain is a

repository for users and groups that the vCenter Single Sign-On server can use for user authentication.

nSet the Default Domain for vCenter Single Sign-On on page 30

Each vCenter Single Sign-On identity source is associated with a domain. vCenter Single Sign-On uses

the default domain to authenticate a user who logs in without a domain name. Users who belong to a

domain that is not the default domain must include the domain name when they log in.

nAdd a vCenter Single Sign-On Identity Source on page 31

Users can log in to vCenter Server only if they are in a domain that has been added as a vCenter Single

Sign-On identity source. vCenter Single Sign-On administrator users can add identity sources from the

vSphere Web Client.

nEdit a vCenter Single Sign-On Identity Source on page 34

vSphere users are dened in an identity source. You can edit the details of an identity source that is

associated with vCenter Single Sign-On.

nRemove a vCenter Single Sign-On Identity Source on page 35

vSphere users are dened in an identity source. You can remove an identity source from the list of

registered identity sources.

nUse vCenter Single Sign-On with Windows Session Authentication on page 35

You can use vCenter Single Sign-On with Windows Session Authentication (SSPI). To make the

checkbox on the login page available, the Client Integration Plug-in must be installed.

Identity Sources for vCenter Server with vCenter Single Sign-On

You can use identity sources to aach one or more domains to vCenter Single Sign-On. A domain is a

repository for users and groups that the vCenter Single Sign-On server can use for user authentication.

An identity source is a collection of user and group data. The user and group data is stored in Active

Directory, OpenLDAP, or locally to the operating system of the machine where vCenter Single Sign-On is

installed.

After installation, every instance of vCenter Single Sign-On has the identity source your_domain_name, for

example vsphere.local. This identity source is internal to vCenter Single Sign-On. A vCenter Single Sign-On

administrator can add identity sources, set the default identity source, and create users and groups in the

vsphere.local identity source.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 29

Types of Identity Sources

vCenter Server versions earlier than version 5.1 supported Active Directory and local operating system users

as user repositories. As a result, local operating system users could always authenticate to the

vCenter Server system. vCenter Server version 5.1 and version 5.5 uses vCenter Single Sign-On for

authentication. See the vSphere 5.1 documentation for a list of supported identity sources with vCenter

Single Sign-On 5.1. vCenter Single Sign-On 5.5 supports the following types of user repositories as identity

sources, but supports only one default identity source.

nActive Directory versions 2003 and later. Shown as Active Directory (Integrated Windows

Authentication) in the vSphere Web Client. vCenter Single Sign-On allows you to specify a single

Active Directory domain as an identity source. The domain can have child domains or be a forest root

domain. VMware KB article 2064250 discusses Microsoft Active Directory Trusts supported with

vCenter Single Sign-On.

nActive Directory over LDAP. vCenter Single Sign-On supports multiple Active Directory over LDAP

identity sources. This identity source type is included for compatibility with the vCenter Single Sign-On

service included with vSphere 5.1. Shown as Active Directory as an LDAP Server in the vSphere Web

Client.

nOpenLDAP versions 2.4 and later. vCenter Single Sign-On supports multiple OpenLDAP identity

sources. Shown as OpenLDAP in the vSphere Web Client.

nLocal operating system users. Local operating system users are local to the operating system where the

vCenter Single Sign-On server is running. The local operating system identity source exists only in basic

vCenter Single Sign-On server deployments and is not available in deployments with multiple vCenter

Single Sign-On instances. Only one local operating system identity source is allowed. Shown as localos

in the vSphere Web Client.

N Do not use local operating system users if the Platform Services Controller is on a dierent

machine than the vCenter Server system. Using local operating system users might make sense in an

embedded deployment but is not recommended.

nvCenter Single Sign-On system users. Exactly one system identity source named vsphere.local is created

when you install vCenter Single Sign-On. Shown as vsphere.local in the vSphere Web Client.

N 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 identity sources are managed by vCenter Single Sign-On administrator users.

You can add identity sources to a vCenter Single Sign-On server instance. Remote identity sources are

limited to Active Directory and OpenLDAP server implementations.

Set the Default Domain for vCenter Single Sign-On

Each vCenter Single Sign-On identity source is associated with a domain. vCenter Single Sign-On uses the

default domain to authenticate a user who logs in without a domain name. Users who belong to a domain

that is not the default domain must include the domain name when they log in.

When a user logs in to a vCenter Server system from the vSphere Web Client, the login behavior depends on

whether the user is in the default domain, that is, the domain that is set as the default identity source.

nUsers who are in the default domain can log in with their user name and password.

nUsers who are in a domain that has been added to vCenter Single Sign-On as an identity source but is

not the default domain can log in to vCenter Server but must specify the domain in one of the following

ways.

nIncluding a domain name prex, for example, MYDOMAIN\user1

vSphere Security

30 VMware, Inc.

nIncluding the domain, for example, user1@mydomain.com

nUsers who are in a domain that is not a vCenter Single Sign-On identity source cannot log in to

vCenter Server. If the domain that you add to vCenter Single Sign-On is part of a domain hierarchy,

Active Directory determines whether users of other domains in the hierarchy are authenticated or not.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Browse to Administration > Single Sign-On > .

3 On the Identity Sources tab, select an identity source and click the Set as Default Domain icon.

In the domain display, the default domain shows (default) in the Domain column.

Add a vCenter Single Sign-On Identity Source

Users can log in to vCenter Server only if they are in a domain that has been added as a vCenter Single Sign-

On identity source. vCenter Single Sign-On administrator users can add identity sources from the

vSphere Web Client.

An identity source can be a native Active Directory (Integrated Windows Authentication) domain or an

OpenLDAP directory service. For backward compatibility, Active Directory as an LDAP Server is also

available. See “Identity Sources for vCenter Server with vCenter Single Sign-On,” on page 29

Immediately after installation, the following default identity sources and users are available:

localos All local operating system users. If you are upgrading, those users who can

already authenticate continue to be able to authenticate. Using the localos

identity source does not make sense in environments that use a

Platform Services Controller.

vsphere.local Contains the vCenter Single Sign-On internal users.

Prerequisites

The domain that you want to add as an identity source must be available to the machine where vCenter

Single Sign-On is running. If you are using a vCenter Server Appliance, see the vCenter Server Appliance

Conguration documentation.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Browse to Administration > Single Sign-On > .

3 On the Identity Sources tab, click the Add Identity Source icon.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 31

4 Select the type of identity source and enter the identity source seings.

Option Description

Active Directory (Integrated

Windows Authentication)

Use this option for native Active Directory implementations. The machine

on which the vCenter Single Sign-Onservice is running must be in an

Active Directory domain if you want to use this option.

See “Active Directory Identity Source Seings,” on page 32.

Active Directory as an LDAP Server This option is available for backward compatibility. It requires that you

specify the domain controller and other information. See “Active Directory

LDAP Server and OpenLDAP Server Identity Source Seings,” on

page 33.

OpenLDAP Use this option for an OpenLDAP identity source. See “Active Directory

LDAP Server and OpenLDAP Server Identity Source Seings,” on

page 33.

LocalOS Use this option to add the local operating system as an identity source. You

are prompted only for the name of the local operating system. If you select

this option, all users on the specied machine are visible to vCenter Single

Sign-On, even if those users are not part of another domain.

N If the user account is locked or disabled, authentications and group and user searches in the

Active Directory domain will fail. The user account must have read-only access over the User and

Group OU, and must be able to read user and group aributes. This is the default Active Directory

domain conguration for authentication permissions. VMware recommends using a special service

user.

5 If you congured an Active Directory as an LDAP Server or an OpenLDAP identity source, click Test

Connection to ensure that you can connect to the identity source.

6 Click OK.

What to do next

When an identity source is added, all users can be authenticated but have the No access role. A user with

vCenter Server Modify.permissions privileges can assign give users or groups of users privileges that

enable them to log in to vCenter Server and view and manage objects. See the vSphere Security

documentation.

Active Directory Identity Source Settings

If you select the Active Directory (Integrated Windows Authentication) identity source type, you can use

the local machine account as your SPN (Service Principal Name) or specify an SPN explicitly. You can use

this option only if the vCenter Single Sign-On server is joined to an Active Directory domain.

Prerequisites for Using an Active Directory Identity Source

You can set up vCenter Single Sign-On to use an Active Directory identity source only if that identity source

is available.

nFor a Windows installation, join the Windows machine to the Active Directory domain.

nFor a vCenter Server Appliance, follow the instructions in the vCenter Server Appliance Conguration

documentation.

N Active Directory (Integrated Windows Authentication) always uses the root of the Active Directory

domain forest. To congure your Integrated Windows Authentication identity source with a child domain

within your Active Directory forest, see VMware Knowledge Base article 2070433.

vSphere Security

32 VMware, Inc.

Select Use machine account to speed up conguration. If you expect to rename the local machine on which

vCenter Single Sign-On runs, specifying an SPN explicitly is preferable.

N In vSphere 5.5, vCenter Single Sign-On uses the machine account even if you specify the SPN. See

VMware Knowledge Base article 2087978.

Table 2‑5. Add Identity Source Settings

Text Box Description

Domain name FDQN of the domain name, for example, mydomain.com.

Do not provide an IP address. This domain name must be

DNS-resolvable by the vCenter Server system. If you are

using a vCenter Server Appliance, use the information on

conguring network seings to update the DNS server

seings.

Use machine account Select this option to use the local machine account as the

SPN. When you select this option, you specify only the

domain name. Do not select this option if you expect to

rename this machine.

Use Service Principal Name (SPN) Select this option if you expect to rename the local

machine. You must specify an SPN, a user who can

authenticate with the identity source, and a password for

the user.

Service Principal Name (SPN) SPN that helps Kerberos to identify the Active Directory

service. Include the domain in the name, for example,

STS/example.com.

The SPN must be unique across the domain. Running

setspn -S checks that no duplicate is created. See the

Microsoft documentation for information on setspn.

User Principal Name (UPN)

Password

Name and password of a user who can authenticate with

this identity source. Use the email address format, for

example, jchin@mydomain.com. You can verify the User

Principal Name with the Active Directory Service

Interfaces Editor (ADSI Edit).

Active Directory LDAP Server and OpenLDAP Server Identity Source Settings

The Active Directory as an LDAP Server identity source is available for backward compatibility. Use the

Active Directory (Integrated Windows Authentication) option for a setup that requires less input. The

OpenLDAP Server identity source is available for environments that use OpenLDAP.

If you are conguring an OpenLDAP identity source, see VMware Knowledge Base article 2064977 for

additional requirements.

Table 2‑6. Active Directory as an LDAP Server and OpenLDAP Settings

Field Description

Name Name of the identity source.

Base DN for users Base Distinguished Name for users.

Domain name FDQN of the domain, for example, example.com. Do not

provide an IP address in this eld.

Domain alias For Active Directory identity sources, the domain's

NetBIOS name. Add the NetBIOS name of the Active

Directory domain as an alias of the identity source if you

are using SSPI authentications.

For OpenLDAP identity sources, the domain name in

capital leers is added if you do not specify an alias.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 33

Table 2‑6. Active Directory as an LDAP Server and OpenLDAP Settings (Continued)

Field Description

Base DN for groups The base Distinguished Name for groups.

Primary Server URL Primary domain controller LDAP server for the domain.

Use the format ldap://hostname:port or

ldaps://hostname:port. The port is typically 389 for ldap:

connections and 636 for ldaps: connections. For Active

Directory multi-domain controller deployments, the port is

typically 3268 for ldap: connections and 3269 for ldaps:

connections.

A certicate that establishes trust for the LDAPS endpoint

of the Active Directory server is required when you use

ldaps:// in the primary or secondary LDAP URL.

Secondary server URL Address of a secondary domain controller LDAP server

that is used for failover.

Choose certicate If you want to use LDAPS with your Active Directory

LDAP Server or OpenLDAP Server identity source, a

Choose certicate buon becomes available after you type

ldaps:// in the URL eld. A secondary URL is not

required.

Username ID of a user in the domain who has a minimum of read-

only access to Base DN for users and groups.

Password Password of the user who is specied by Username.

Edit a vCenter Single Sign-On Identity Source

vSphere users are dened in an identity source. You can edit the details of an identity source that is

associated with vCenter Single Sign-On.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Browse to Administration > Single Sign-On > .

3 Click the Identity Sources tab.

4 Right-click the identity source in the table and select Edit Identity Source.

5 Edit the identity source seings. The available options depend on the type of identity source you

selected.

Option Description

Active Directory (Integrated

Windows Authentication)

Use this option for native Active Directory implementations. The machine

on which the vCenter Single Sign-Onservice is running must be in an

Active Directory domain if you want to use this option.

See “Active Directory Identity Source Seings,” on page 32.

Active Directory as an LDAP Server This option is available for backward compatibility. It requires that you

specify the domain controller and other information. See “Active Directory

LDAP Server and OpenLDAP Server Identity Source Seings,” on page 33.

vSphere Security

34 VMware, Inc.

Option Description

OpenLDAP Use this option for an OpenLDAP identity source. See “Active Directory

LDAP Server and OpenLDAP Server Identity Source Seings,” on page 33.

LocalOS Use this option to add the local operating system as an identity source. You

are prompted only for the name of the local operating system. If you select

this option, all users on the specied machine are visible to vCenter Single

Sign-On, even if those users are not part of another domain.

6 Click Test Connection to ensure that you can connect to the identity source.

7 Click OK.

Remove a vCenter Single Sign-On Identity Source

vSphere users are dened in an identity source. You can remove an identity source from the list of registered

identity sources.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Browse to Administration > Single Sign-On > .

3 On the Identity Sources tab, select an identity source and click the Delete Identity Source icon.

4 Click Yes when prompted to conrm.

Use vCenter Single Sign-On with Windows Session Authentication

You can use vCenter Single Sign-On with Windows Session Authentication (SSPI). To make the checkbox on

the login page available, the Client Integration Plug-in must be installed.

Using SSPI speeds up login for the user who is currently logged in to a machine.

Prerequisites

Your Windows domain must be set up properly. See VMware Knowledge Base article 2064250.

Procedure

1 Navigate to the vSphere Web Client login page.

2 If the Use Windows session authentication check box is not available, click Download the Client

Integration Plug-in at the boom of the login page.

3 If the browser blocks the installation by issuing certicate errors or by running a pop-up blocker, follow

the Help instructions for your browser to resolve the problem.

4 Close other browsers if you are prompted to do so.

After installation, the plug-in is available for all browsers. If your browser requires it, you might have to

allow the plug-in for individual sessions or for all sessions.

5 Exit and restart your browser.

After the restart, you can select the Use Windows session authentication check box.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 35

vCenter Server Two-Factor Authentication

vCenter Single Sign-On allows you to authenticate by using the name and password of a user in an identity

source that is known to vCenter Single Sign-On, or using Windows session authentication for Active

Directory identity sources. Starting with vSphere 6.0 Update 2, you can also authenticate by using a smart

card (UPN-based Common Access Card or CAC), or by using an RSA SecurID token.

Two-Factor Authentication Methods

The two-factor authentication methods are often required by government agencies or large enterprises.

Common Access Card

(CAC) Authentication

CAC authentication allows access only to users who aach a physical card to

the USB drive of the computer where they log in. If the PKI is deployed so

that the smart card certicates are the only client certicates that are issued

by the CA, then only smart card certicates are presented to the user. The

user selects a certicate, and is then prompted for a PIN. Only users who

have both the physical card and the PIN that matches the certicate can log

in.

RSA SecurID

Authentication

For RSA SecureID authentication, your environment must include a correctly

congured RSA Authentication Manager. If the Platform Services Controller

is congured to point to the RSA server, and if RSA SecurID Authentication

is enabled, users can then log in with their user name and token.

N vCenter Single Sign-On supports only native SecurID, it does not

support RADIUS authentication.

Specifying a Non-Default Authentication Method

Administrators can perform the setup from the Platform Services Controller Web interface, or by using the

sso-config script (sso-config.bat on Windows and sso-config.sh on the appliance).

nFor Common Access Card authentication, you set up your Web browser by using the sso-config script,

and you can perform the vCenter Single Sign-On setup from the Platform Services Controller Web

interface or by using sso-config. Setup includes enabling CAC authentication, conguring certicate

revocation policies, and seing up a login banner.

nFor RSA SecureID, you use the sso-config script to congure RSA Authentication Manager for the

domain, and to enable RSA token authetication. The authentication method displays in the

Platform Services Controller Web interface if enabled, but you cannot congure RSA SecureID

authentication from the Web interface.

Combining Different Authentication Methods

You can enable or disable each authentication method separately using sso-config. It might make sense, for

example, to leave user name and password authentication enabled initially while you are testing one of the

two-factor authentication methods, and to then set only one authentication method as enabled.

vSphere Security

36 VMware, Inc.

Configuring Smart Card Authentication for vCenter Single Sign-On

You can set up your environment to require smart card authentication when a user connects to a

vCenter Server or associated Platform Services Controller from the vSphere Web Client.

Smart Card Authentication Login

A smart card is a small plastic card with an embedded integrated circuit chip. Many government agencies

and large enterprises use smart cards such as Common Access Card (CAC) to increase the security of their

systems and to comply with security regulations. A Common Access Card is used in environments where

each machine includes a smart card reader, and where smart card hardware drivers that manage Common

Access Card are typically preinstalled.

When you congure smart card authentication for vCenter Single Sign-On, users who log in to a

vCenter Server or Platform Services Controller system are prompted to authenticate with a smart card and

PIN combination, as follows:

1 When the user inserts the smart card into the smart card reader, vCenter Single Sign-On reads the

certicates on the card.

2 vCenter Single Sign-On prompts the user to select a certicate, and then prompts the user for the PIN

for that certicate.

3 vCenter Single Sign-On checks whether the certicate on the smart card is known and whether the PIN

is correct. If the revocation checking is turned on, vCenter Single Sign-On also checks whether the

certicate is revoked.

4 If the certicate is known, and is not a revoked certicate, the user is authenticated and can then

perform tasks that user has permissions for.

N In most cases, it makes sense to leave user name and password authentication enabled during

testing. After testing is complete, disable user name and password authentication and enable smart card

authentication. After that, the vSphere Client allows only smart card login. Only users with root or

administrator privileges on the machine can reenable user name and password by logging into

thePlatform Services Controller directly.

Use the Command Line to Configure Smart Card Authentication

You can use the sso-config utility to congure smart card authentication from the command line. The utility

supports all smart card conguration tasks.

When you congure smart card authentication from the command line, you always set up the

Platform Services Controller using the sso-config command rst. Then you can perform other tasks by

using the Platform Services Controller Web interface.

1Congure the Platform Services Controller so that the Web browser requests submission of the smart

card certicate when the user logs in.

2Congure the authentication policy. You can congure the policy by using the sso-config script or the

Platform Services Controller Web interface. Conguration of supported authentication types and

revocation seings is stored in VMware Directory Service and replicated across all

Platform Services Controller instances in a vCenter Single Sign-On domain.

If smart card authentication is enabled and other authentication methods are disabled, users are then

required to log in using smart card authentication.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 37

If login from the vSphere Web Client is not working, and if user name and password authentication is

turned o, a root or administrator user can turn user name and password authentication back on from the

Platform Services Controller command line by running the following command. The example is for

Windows; for Linux, use sso-config.sh.

sso-config.bat -set_authn_policy -pwdAuthn true

Prerequisites

nVerify that your environment uses Platform Services Controller version 6.0 Update 2 or later, and that

you use vCenter Server version 6.0 or later. Upgrade version 5.5 nodes to version 6.0.

nVerify that an enterprise Public Key Infrastructure (PKI) is set up in your environment, and that

certicates meet the following requirements:

nA User Principal Name (UPN) that corresponds to an Active Directory account in the Subject

Alternative Name (SAN) extension.

nClient Authentication must be specied in the Application Policy or Enhanced Key Usage eld of a

certicate, or the browser does not show that certicate.

nVerify that the Platform Services Controller Web interface certicate is trusted by the end user’s

workstation; otherwise, the browser does not aempt the authentication.

nCongure an Active Directory identity source and add it to vCenter Single Sign-On as an identity

source.

nAssign the vCenter Server Administrator role to one or more users in the Active Directory identity

source. Those users can then authenticate because they are in the Active Directory group, and they have

vCenter Server administrator privileges. The administrator@vsphere.local user cannot perform smart

card authentication.

nIf you want to use the Platform Services Controller HA solution in your environment, complete all HA

conguration before you set up smart card authentication. See VMware Knowledge Base article 2112085

(Windows) or 2113315 (vCenter Server Appliance).

Procedure

1 Obtain the certicates and copy them to a folder that the sso-config utility can see.

Option Description

Windows Log in to the Platform Services Controller Windows installation and use

WinSCP or a similar utility to copy the les.

Appliance a Log in to the appliance console, either directly or by using SSH.

b Enable the appliance shell, as follows.

shell.set --enabled True

shell

chsh -s "/bin/bash" root

csh -s "bin/appliance/sh" root

c Use WinSCP or a similar utility to copy the certicates to

the /usr/lib/vmware-sso/vmware-sts/conf on the

Platform Services Controller.

d Optionally disable the appliance shell, as follows.

chsh -s "bin/appliancesh" root

vSphere Security

38 VMware, Inc.

2 On each Platform Services Controller node, congure smart card authentication seings by using the

sso-config CLI.

a Go to the directory where the sso-config script is located.

Option Description

Windows C:\Program Files\VMware\VCenter server\VMware Identity

Services

Appliance /opt/vmware/bin

b Run the following command:

sso-config.[bat|sh] -set_tc_cert_authn -switch true -cacerts

[FirstTrustedCA.cer,SecondTrustedCA.cer,...] -t tenant

For example:

sso-config.bat -set_tc_cert_authn -switch true -cacerts MySmartCA1.cer -t vsphere.local

c Restart the virtual or physical machine.

service-control --stop vmware-stsd

service-control --start vmware-stsd

3 To enable smart cart authentication for VMware Directory Service (vmdir), run the following command.

sso-config.[bat|sh] -set_authn_policy -certAuthn true -cacerts first_trusted_cert.cer,

second_trusted_cert.cer -t tenant

For example:

sso-config.[bat|sh] -set_authn_policy -certAuthn true -cacerts MySmartCA1.cer,

MySmartCA2.cer -t vsphere.local

4 To disable all other authentication methods, run the following commands.

sso-config.sh -set_authn_policy -pwdAuthn false -t vsphere.local

sso-config.sh -set_authn_policy -winAuthn false -t vsphere.local

sso-config.sh -set_authn_policy -securIDAuthn false -t vsphere.local

You can use these commands to enable and disable dierent authentication methods as needed.

5 (Optional) To set a certicate policies white list, run the following command.

sso-config.[bat|sh] -set_authn_policy -certPolicies policies

To specify multiple policies, separate them with a command, for example:

sso-config.bat -set_authn_policy -certPolicies

2.16.840.1.101.2.1.11.9,2.16.840.1.101.2.1.11.19

This white list species object IDs of policies that are allowed in the certicate's certicate policy

extension. An X509 certicate can have a Certicate Policy extension.

6 (Optional) To list conguration information, run the following command.

sso-config.[bat|sh] -get_authn_policy -t tenantName

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 39

Use the Platform Services Controller Web Interface to Manage Smart Card

Authentication

You can enable and disable smart card authentication, customize the login banner, and set up the revocation

policy from the Platform Services Controller Web interface.

When you congure smart card authentication from the command line, you always set up the

Platform Services Controller using the sso-config command rst. Then you can perform other tasks by

using the Platform Services Controller Web interface.

1Congure the Platform Services Controller so that the Web browser requests submission of the smart

card certicate when the user logs in.

2Congure the authentication policy. You can congure the policy by using the sso-config script or the

Platform Services Controller Web interface. Conguration of supported authentication types and

revocation seings is stored in VMware Directory Service and replicated across all

Platform Services Controller instances in a vCenter Single Sign-On domain.

If smart card authentication is enabled and other authentication methods are disabled, users are then

required to log in using smart card authentication.

If login from the vSphere Web Client is not working, and if user name and password authentication is

turned o, a root or administrator user can turn user name and password authentication back on from the

Platform Services Controller command line by running the following command. The example is for

Windows; for Linux, use sso-config.sh.

sso-config.bat -set_authn_policy -pwdAuthn true

Prerequisites

nVerify that your environment uses Platform Services Controller version 6.0 Update 2 or later, and that

you use vCenter Server version 6.0 or later. Upgrade version 5.5 nodes to version 6.0.

nVerify that an enterprise Public Key Infrastructure (PKI) is set up in your environment, and that

certicates meet the following requirements:

nA User Principal Name (UPN) that corresponds to an Active Directory account in the Subject

Alternative Name (SAN) extension.

nClient Authentication must be specied in the Application Policy or Enhanced Key Usage eld of a

certicate, or the browser does not show that certicate.

nVerify that the Platform Services Controller Web interface certicate is trusted by the end user’s

workstation; otherwise, the browser does not aempt the authentication.

nCongure an Active Directory identity source and add it to vCenter Single Sign-On as an identity

source.

nAssign the vCenter Server Administrator role to one or more users in the Active Directory identity

source. Those users can then authenticate because they are in the Active Directory group, and they have

vCenter Server administrator privileges. The administrator@vsphere.local user cannot perform smart

card authentication.

nIf you want to use the Platform Services Controller HA solution in your environment, complete all HA

conguration before you set up smart card authentication. See VMware Knowledge Base article 2112085

(Windows) or 2113315 (vCenter Server Appliance).

vSphere Security

40 VMware, Inc.

Procedure

1 Obtain the certicates and copy them to a folder that the sso-config utility can see.

Option Description

Windows Log in to the Platform Services Controller Windows installation and use

WinSCP or a similar utility to copy the les.

Appliance a Log in to the appliance console, either directly or by using SSH.

b Enable the appliance shell, as follows.

shell.set --enabled True

shell

chsh -s "/bin/bash" root

csh -s "bin/appliance/sh" root

c Use WinSCP or a similar utility to copy the certicates to

the /usr/lib/vmware-sso/vmware-sts/conf on the

Platform Services Controller.

d Optionally disable the appliance shell, as follows.

chsh -s "bin/appliancesh" root

2 On each Platform Services Controller node, congure smart card authentication seings by using the

sso-config CLI.

a Go to the directory where the sso-config script is located.

Option Description

Windows C:\Program Files\VMware\VCenter server\VMware Identity

Services

Appliance /opt/vmware/bin

b Run the following command:

sso-config.[bat|sh] -set_tc_cert_authn -switch true -cacerts

[FirstTrustedCA.cer,SecondTrustedCA.cer,...] -t tenant

For example:

sso-config.bat -set_tc_cert_authn -switch true -cacerts Root64.cer -t vsphere.local

c Restart the virtual or physical machine.

service-control --stop vmware-stsd

service-control --start vmware-stsd

3 From a Web browser, connect to the Platform Services Controller by specifying the following URL:

https://psc_hostname_or_IP/psc

In an embedded deployment, the Platform Services Controller host name or IP address is the same as

the vCenter Server host name or IP address.

4 Specify the user name and password for administrator@vsphere.local or another member of the vCenter

Single Sign-On Administrators group.

If you specied a dierent domain during installation, log in as administrator@mydomain.

5 Browse to Single Sign-On > .

6 Click Smart Card , and select the Trusted CA  tab.

7 To add one or more trusted certicates, click Add , click Browse, select all certicates from

trusted CAs, and click OK.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 41

8 To specify the authentication conguration, click Edit next to Authentication  and select

or deselect authentication methods.

You cannot enable or disable RSA SecurID authentication from this Web interface. However, if RSA

SecurID has been enabled from the command line, the status appears in the Web interface.

Set Revocation Policies for Smart Card Authentication

You can customize certicate revocation checking, and you can specify where vCenter Single Sign-On looks

for information on revoked certicates.

You can customize the behavior by using the Platform Services Controller Web interface or by using the sso-

config script. The seings that you select depend in part on what the CA supports.

nIf revocation checking is disabled, vCenter Single Sign-On ignores any CRL or OCSP seings.

nIf revocation checking is enabled, the recommended setup depends on the PKI setup.

OCSP only If the issuing CA supports an OCSP responder, enable OCSP and disable

using CRL as failover.

CRL only If the issuing CA does not support OSCP, enable CRL checking and

disable OSCP checking.

Both OSCP and CRL If the issuing CA supports both an OCSP responder and a CRL, vCenter

Single Sign-On checks the OCSP responder rst. If the responder returns

an unknown status or is not available, vCenter Single Sign-On checks the

CRL. For this case, enable both OCSP checking and CRL checking, and

enable CRL as failover for OCSP.

nIf revocation checking is enabled, advanced users can specify the following additional seings.

OSCP URL By default, vCenter Single Sign-On checks the location of the OCSP

responder that is dened in the certicate being validated. You can

explicitly specify a location if the Authority Information Access extension

is absent from the certicate or if you want to override it, for example,

because it is not available in your environment.

Use CRL from

certificate

By default, vCenter Single Sign-On checks the location of the CRL that is

dened in the certicate being validated. Disable this option when the

CRL Distribution Point extension is absent from the certicate or if you

want to override the default.

CRL location Use this property if you disable Use CRL from  and you want

to specify a location (le or HTTP URL) where the CRL is located.

In addition, you can further limit which certicates vCenter Single Sign-On accepts by adding a certicate

policy.

Prerequisites

nVerify that your environment uses Platform Services Controller version 6.0 Update 2 or later, and that

you use vCenter Server version 6.0 or later. Upgrade version 5.5 nodes to version 6.0.

nVerify that an enterprise Public Key Infrastructure (PKI) is set up in your environment, and that

certicates meet the following requirements:

nA User Principal Name (UPN) that corresponds to an Active Directory account in the Subject

Alternative Name (SAN) extension.

nClient Authentication must be specied in the Application Policy or Enhanced Key Usage eld of a

certicate, or the browser does not show that certicate.

vSphere Security

42 VMware, Inc.

nVerify that the Platform Services Controller Web interface certicate is trusted by the end user’s

workstation; otherwise, the browser does not aempt the authentication.

nCongure an Active Directory identity source and add it to vCenter Single Sign-On as an identity

source.

nAssign the vCenter Server Administrator role to one or more users in the Active Directory identity

source. Those users can then authenticate because they are in the Active Directory group, and they have

vCenter Server administrator privileges. The administrator@vsphere.local user cannot perform smart

card authentication.

nIf you want to use the Platform Services Controller HA solution in your environment, complete all HA

conguration before you set up smart card authentication. See VMware Knowledge base article 2113085

(Windows) or 2113315 (vCenter Server Appliance).

Procedure

1 From a Web browser, connect to the Platform Services Controller by specifying the following URL:

https://psc_hostname_or_IP/psc

In an embedded deployment, the Platform Services Controller host name or IP address is the same as

the vCenter Server host name or IP address.

2 Specify the user name and password for administrator@vsphere.local or another member of the vCenter

Single Sign-On Administrators group.

If you specied a dierent domain during installation, log in as administrator@mydomain.

3 Browse to Single Sign-On > .

4 Click  Revocation  and enable or disable revocation checking.

5 If certicate policies are in eect in your environment, you can add a policy in the  policies

accepted pane.

Set Up RSA SecureID Authentication

You can set up your environment to require that users log in with an RSA SecureID token instead of a

password. SecureID setup is supported only from the command line.

N RSA Authentication Manager requires that the user ID is a unique identier that uses 1 to 255 ASCII

characters. The characters ampersand (&), percent (%), greater than (>), less than (<), and single quote (`) are

not allowed.

Prerequisites

nVerify that your environment uses Platform Services Controller version 6.0 Update 2 or later, and that

you use vCenter Server version 6.0 or later. Upgrade version 5.5 nodes to version 6.0.

nVerify that your environment has a correctly congured RSA Authentication Manager and that users

have RSA tokens. RSA Authentication Manager version 8.0 or later is required.

nVerify that the identity source that RSA Manager uses has been added to vCenter Single Sign-On. See

“Add a vCenter Single Sign-On Identity Source,” on page 31.

nVerify that the RSA Authentication Manager system can resolve the Platform Services Controller host

name, and that the Platform Services Controller system can resolve the RSA Authentication Manager

host name.

nExport the sdconf.rec le from the RSA Manager by selecting Access > Authentication Agents >

Generate  . Decompress the resulting AM_Config.zip le to nd the sdconf.rec le.

nCopy the sdconf.rec le to the Platform Services Controller node.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 43

Procedure

1 Change to the directory where the sso-config script is located.

Option Description

Windows C:\Program Files\VMware\VCenter server\VMware Identity

Services

Appliance /opt/vmware/bin

2 To enable RSA SecurID authentication, run the following command.

sso-config.[sh|bat] -t tenantName -set_authn_policy –securIDAuthn true

tenantName is the name of the vCenter Single Sign-On domain, vsphere.local by default.

3 (Optional) To disable other authentication methods, run the following command.

sso-config.sh -set_authn_policy -pwdAuthn false -winAuthn false -certAuthn false -t

vsphere.local

4 To congure the environment so that the tenant at the current site uses the RSA site, run the following

command.

sso-config.[sh|bat] -set_rsa_site [-t tenantName] [-siteID Location] [-agentName Name] [-

sdConfFile Path]

For example:

sso-config.sh -set_rsa_site -agentName SSO_RSA_AUTHSDK_AGENT -sdConfFile /tmp/sdconf.rec

You can specify the following options.

Option Description

siteID Optional Platform Services Controller site ID. Platform Services Controller

supports one RSA Authentication Manager instance or cluster per site. If

you do not explicitly specify this option, the RSA conguration is for the

current Platform Services Controller site. Use this option only if you are

adding a dierent site.

agentName Dened in RSA Authentication Manager.

sdConfFile Copy of the sdconf.rec le that was downloaded from RSA Manager and

includes conguration information for the RSA Manager, such as the IP

address.

5 (Optional) To change the tenant conguration to nondefault values, run the following command.

sso-config.[sh|bat] -set_rsa_config [-t tenantName] [-logLevel Level] [-logFileSize Size] [-

maxLogFileCount Count] [-connTimeOut Seconds] [-readTimeOut Seconds] [-encAlgList

Alg1,Alg2,...]

The default is usually appropriate, for example:

sso-config.sh -set_rsa_config -t vsphere.local -logLevel DEBUG

6 (Optional) If your identity source is not using the User Principal Name as the user ID, set up the

identity source userID aribute.

The userID aribute determines which LDAP aribute is used as the RSA userID.

sso-config.[sh|bat] -set_rsa_userid_attr_map [-t tenantName] [-idsName Name] [-ldapAttr

AttrName] [-siteID Location]

vSphere Security

44 VMware, Inc.

For example:

sso-config.sh -set_rsa_userid_attr_map -t vsphere.local -idsName ssolabs.com -ldapAttr

userPrincipalName

7 To display the current seings, run the following command.

sso-config.sh -t tenantName -get_rsa_config

If user name and password authentication is disabled and SecurID token authentication is enabled, users

must log in with their user name and SecureID token. User name and password login is no longer possible.

Manage the Login Banner

Starting with vSphere 6.0 Update 2, you can include a Login Banner with your environment. You can

display some text, or you can require that the user click a check box, for example, to indicate that they accept

terms and conditions. You can enable and disable the login banner, and you can require that users click an

explicit consent check box.

Procedure

1 From a Web browser, connect to the Platform Services Controller by specifying the following URL:

https://psc_hostname_or_IP/psc

In an embedded deployment, the Platform Services Controller host name or IP address is the same as

the vCenter Server host name or IP address.

2 Specify the user name and password for administrator@vsphere.local or another member of the vCenter

Single Sign-On Administrators group.

If you specied a dierent domain during installation, log in as administrator@mydomain.

3 Under Single Sign-On, select  and click the Login Banner tab.

4 Click Edit and congure the login banner.

Option Description

Status Click the Enabled check box to enable to login banner. You cannot change

the other elds unless you click this check box.

Explicit Consent Click the Explicit Consent check box to require that the user click a check

box before logging in. You can also display a message without a check box.

Title Title of the banner. By default, the Login Banner text is I agree to the.

You can add to that, for example Terms and Conditions.

Message Message that the user sees when clicking on the banner. For example, the

text of the terms and conditions. The message is required if you use

explicit consent.

Using vCenter Single Sign-On as the Identity Provider for Another

Service Provider

You can use vCenter Single Sign-On as an identity provider with a service provider that supports the SAML

2.0 standard. If you do, the other service provider grants access to a user if that user can authenticate to

vCenter Single Sign-On.

For example, vRealize Automation 7.0 and later supports vCenter Single Sign-On as an identity provider.

When you log in to vRealize Automation, vCenter Single Sign-On performs the authentication is performed.

The SAML token that vCenter Single Sign-On generates is trusted by both vCenter Single Sign-On and

vRealize Automation.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 45

Required Setup

You have to perform integration tasks for both vCenter Single Sign-On and the service that is using vCenter

Single Sign-On.

1 Export the vCenter Single Sign-On metadata and register vCenter Single Sign-On as an identity

provider into the other service provider.

2 Export the metadata of the other service provider and import them into vCenter Single Sign-On.

If you are using vRealize Automation as the service provider, see the vRealize Automation documentation

for details.

N The service must fully support the SAML 2.0 standard or integration does not work.

Add a SAML Service Provider

You add a SAML service provider to vCenter Single Sign-On, and add vCenter Single Sign-On as the

identity provider to that service. Going forward, when users log in to the service provider, the service

provider authenticates those users with vCenter Single Sign-On.

Use this process if you want to integrate the Single Sign-On solution that is included with VMware vRealize

Automation 7.0 and later with the vCenter Single Sign-On identity provider, or if you are working with

another external SAML Service Provider.

The process involves importing the metadata from your SAML service provider into vCenter Single Sign-

On, and importing the vCenter Single Sign-On metadata into your SAML service provider so the two

providers share all data.

Prerequisites

The target service must fully support the SAML 2.0 standard.

If the metadata do not follow the SAML 2.0 metadata schema precisely, you might have to edit the schema

before you import it. For example, if you are using an Active Directory Federation Services (ADFS) SAML

service provider, you have to edit the metadata before you can import them. Remove the following non-

standard elements:

fed:ApplicationServiceType

fed:SecurityTokenServiceType

You cannot currently import SAML IDP metadata from the vSphere Web Client.

Procedure

1 Export the metadata from your service provider to a le.

2 Import the service provider's metadata into vCenter Single Sign-On.

a Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter

Single Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

b Browse to Single Sign-On > .

c Select the SAML Service Providers tab.

d In the Metadata from your SAML service provider eld, click Import and paste the XML strings

into the dialog, or click Import from File to import a le and then click Import.

vSphere Security

46 VMware, Inc.

3 Export the vCenter Single Sign-On metadata.

a In the Metadata for your SAML service provider eld, click Download.

b Specify a le location.

4 Go to the SAML service provider, for example VMware vRealize Automation 7.0 or later, and follow the

instructions for your SAML service provider to add the vCenter Single Sign-On metadata to that service

provider.

See the vRealize Automation documentation for details on importing the metadata.

Managing the Security Token Service (STS)

The vCenter Single Sign-On Security Token Service (STS) is a Web service that issues, validates, and renews

security tokens.

To acquire SAML tokens, users present their primary credentials to the STS interface. The primary

credentials depend on the type of user.

User User name and password available in a vCenter Single Sign-On identity

source.

Application user Valid certicate.

STS authenticates the user based on the primary credentials, and constructs a SAML token that contains user

aributes. STS signs the SAML token with its STS signing certicate, and assigns the token to the user. By

default, the STS signing certicate is generated by VMCA. You can replace the default STS signing certicate

from the vSphere Web Client.

After a user has a SAML token, the SAML token is sent as part of that user's HTTP requests, possibly

through various proxies. Only the intended recipient (service provider) can use the information in the

SAML token.

Generate a New STS Signing Certificate on the Appliance

If you want to replace the default vCenter Single Sign-On Security Token Service (STS) signing certicate,

you have to rst generate a new certicate and add it to the Java key store. This procedure explains the steps

on an embedded deployment appliance or an external Platform Services Controller appliance.

Procedure

1 Create a top-level directory to hold the new certicate and verify the location of the directory.

mkdir newsts

cd newsts

pwd

#resulting output: /root/newst

2 Copy the certool.cfg le into the new directory.

cp /usr/lib/vmware-vmca/share/config/certool.cfg /root/newsts

3 Open your copy of the certool.cfg le and edit it to use the local Platform Services Controller IP

address and hostname.

The country is required and has to be two characters. The following sample illustrates this.

# Template file for a CSR request

# Country is needed and has to be 2 characters

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 47

Country = US

Name = STS

Organization = ExampleInc

OrgUnit = ExampleInc Dev

State = Indiana

Locality = Indianapolis

IPAddress = 10.0.1.32

Email = chen@exampleinc.com

Hostname = homecenter.exampleinc.local

4 Generate the key.

/usr/lib/vmware-vmca/bin/certool --server localhost --genkey --privkey=/root/newsts/sts.key

--pubkey=/root/newsts/sts.pub

5 Generate the certicate

/usr/lib/vmware-vmca/bin/certool --gencert --cert=/root/newsts/newsts.cer --

privkey=/root/newsts/sts.key --config=/root/newsts/certool.cfg

6 Convert the certicate to PK12 format.

openssl pkcs12 -export -in /root/newsts/newsts.cer -inkey /root/newsts/sts.key -

certfile /etc/vmware-sso/keys/ssoserverRoot.crt -name "newstssigning" -passout pass:changeme

-out newsts.p12

7 Add the certicate to the Java key store (JKS).

/usr/java/jre-vmware/bin/keytool -v -importkeystore -srckeystore newsts.p12 -srcstoretype

pkcs12 -srcstorepass changeme -srcalias newstssigning -destkeystore root-trust.jks -

deststoretype JKS -deststorepass testpassword -destkeypass testpassword

/usr/java/jre-vmware/bin/keytool -v -importcert -keystore root-trust.jks -deststoretype JKS -

storepass testpassword -keypass testpassword -file /etc/vmware-sso/keys/ssoserverRoot.crt -

alias root-ca

8 When prompted, type Yes to accept the certicate into the keystore.

What to do next

You can now import the new certicate. See “Refresh the STS Root Certicate,” on page 50.

Generate a New STS Signing Certificate on a vCenter Windows Installation

If you want to replace the default STS signing certicate, you have to rst generate a new certicate and add

it to the Java key store. This procedure explains the steps on a Windows installation.

Procedure

1 Create a new directory to hold the new certicate.

cd C:\ProgramData\VMware\vCenterServer\cfg\sso\keys\

mkdir newsts

cd newsts

2 Make a copy of the certool.cfg le and place it in the new directory.

copy "C:\Program Files\VMware\vCenter Server\vmcad\certool.cfg" .

vSphere Security

48 VMware, Inc.

3 Open your copy of the certool.cfg le and edit it to use the local Platform Services Controller IP

address and hostname.

The country is required and has to be two characters. The following sample illustrates this.

# Template file for a CSR request

# Country is needed and has to be 2 characters

Country = US

Name = STS

Organization = ExampleInc

OrgUnit = ExampleInc Dev

State = Indiana

Locality = Indianapolis

IPAddress = 10.0.1.32

Email = chen@exampleinc.com

Hostname = homecenter.exampleinc.local

4 Generate the key.

"C:\Program Files\VMware\vCenter Server\vmcad\certool.exe" --server localhost --genkey --

privkey=sts.key --pubkey=sts.pub

5 Generate the certicate

"C:\Program Files\VMware\vCenter Server\vmcad\certool.exe" --gencert --cert=newsts.cer --

privkey=sts.key --config=certool.cfg

6 Convert the certicate to PK12 format.

"C:\Program Files\VMware\vCenter Server\openSSL\openssl.exe" pkcs12 -export -in newsts.cer -

inkey sts.key -certfile ..\ssoserverRoot.crt -name "newstssigning" -passout pass:changeme -

out newsts.p12

7 Add the certicate to the Java key store (JKS).

"C:\Program Files\VMware\vCenter Server\jre\bin\keytool.exe" -v -importkeystore -srckeystore

newsts.p12 -srcstoretype pkcs12 -srcstorepass changeme -srcalias newstssigning -destkeystore

root-trust.jks -deststoretype JKS -deststorepass testpassword -destkeypass testpassword

"C:\Program Files\VMware\vCenter Server\jre\bin\keytool.exe" -v -importcert -keystore root-

trust.jks -deststoretype JKS -storepass testpassword -keypass testpassword -

file ..\ssoserverRoot.crt -alias root-ca

What to do next

You can now import the new certicate. See “Refresh the STS Root Certicate,” on page 50.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 49

Refresh the STS Root Certificate

The vCenter Single Sign-On server includes a Security Token Service (STS). The Security Token Service is a

Web service that issues, validates, and renews security tokens. You can manually refresh the existing

Security Token Service certicate from the vSphere Web Client when the certicate expires or changes.

To acquire a SAML token, a user presents the primary credentials to the Secure Token Server (STS). The

primary credentials depend on the type of user:

Solution user Valid certicate

Other users User name and password available in a vCenter Single Sign-On identity

source.

The STS authenticates the user using the primary credentials, and constructs a SAML token that contains

user aributes. The STS service signs the SAML token with its STS signing certicate, and then assigns the

token to a user. By default, the STS signing certicate is generated by VMCA.

After a user has a SAML token, the SAML token is sent as part of that user's HTTP requests, possibly

through various proxies. Only the intended recipient (service provider) can use the information in the

SAML token.

You can replace the existing STS signing certicate vSphere Web Client if your company policy requires it,

or if you want to update an expired certicate.

C Do not replace the le in the lesystem. If you do, errors that are unexpected and dicult to

debug result.

N After you replace the certicate, you must restart the node to restart both the vSphere Web Client

service and the STS service.

Prerequisites

Copy the certicate that you just added to the java keystore from the Platform Services Controller to your

local workstation.

Platform Services

Controller appliance

certificate_location/keys/root-trust.jks For example: /keys/root-

trust.jks

For example:

/root/newsts/keys/root-trust.jks

Windows installation certificate_location\root-trust.jks

For example:

C:\Program Files\VMware\vCenter Server\jre\bin\root-trust.jks

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Select the  tab, then the STS Signing subtab, and click the Add STS Signing 

icon.

vSphere Security

50 VMware, Inc.

3 Add the certicate.

a Click Browse to browse to the key store JKS le that contains the new certicate and click Open

b Type the password when prompted.

c Click the top of the STS alias chain and click OK.

d Type the password again when prompted

4 Click OK.

5 Restart the Platform Services Controller node to start both the STS service and the vSphere Web Client.

Before the restart, authentication does not work correctly so the restart is essential.

Determine the Expiration Date of an LDAPS SSL Certificate

If you select a Active Directory LDAP Server and OpenLDAP Server identity source, and you decide to use

LDAPS, you can upload an SSL certicate for the LDAP trac. SSL certicates expire after a predened

lifespan. Knowing when a certicate expires lets you replace or renew the certicate before the expiration

date.

You see certicate expiration information only if you use an Active Directory LDAP Server and OpenLDAP

Server and specify an ldaps:// URL for the server. The Identity Sources TrustStore tab remains empty for

other types of identity sources or for ldap:// trac.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Browse to Administration > Single Sign-On > .

3 Click the  tab, and then the Identity Sources TrustStore subtab.

4 Find the certicate and verify the expiration date in the Valid To text box.

You might see a warning at the top of the tab which indicates that a certicate is about to expire.

Managing vCenter Single Sign-On Policies

vCenter Single Sign-On policies enforce the security rules in your environment. You can view and edit the

default vCenter Single Sign-On passwords, lockout policies, and token policies.

Edit the vCenter Single Sign-On Password Policy

The vCenter Single Sign-On password policy is a set of rules and restrictions on 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.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 51

2 Browse to Administration > Single Sign-On > .

3 Click the Policies tab and select Password Policies.

4 Click Edit.

5 Edit the password policy parameters.

Option Description

Description Password policy description.

Maximum lifetime Maximum number of days that a password can exist before the user must

change it.

Restrict reuse Number of the user's previous passwords that cannot be selected. For

example, if a user cannot reuse any of the last six passwords, type 6.

Maximum length Maximum number of characters that are allowed in the password.

Minimum length Minimum number of characters required in the password. The minimum

length must be no less than the combined minimum of alphabetic,

numeric, and special character requirements.

Character requirements Minimum number of dierent character types that are required in the

password. You can specify the number of each type of character, as

follows:

nSpecial: & # %

nAlphabetic: A b c D

nUppercase: A B C

nLowercase: a b c

nNumeric: 1 2 3

The minimum number of alphabetic characters must be no less than the

combined uppercase and lowercase requirements.

In vSphere 6.0 and later, non-ASCII characters are supported in passwords.

In earlier versions of vCenter Single Sign-On, limitations on supported

characters exist.

Identical adjacent characters Maximum number of identical adjacent characters that are allowed in the

password. The number must be greater than 0. For example, if you enter 1,

the following password is not allowed: p@$$word.

6 Click OK.

Edit the vCenter Single Sign-On Lockout Policy

A vCenter Single Sign-On lockout policy species the conditions under which a user's vCenter Single Sign-

On account is locked when the user aempts to log in with incorrect credentials. You can edit the lockout

policy.

If a user logs in to vsphere.local multiple times with the wrong password, the user is locked out. The lockout

policy allows you to specify the maximum number of failed login aempts and how much time can elapse

between failures. The policy also species how much time must elapse before the account is automatically

unlocked.

N The lockout policy applies only to user accounts, not to system accounts such as

administrator@vsphere.local.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

vSphere Security

52 VMware, Inc.

2 Browse to Administration > Single Sign-On > .

3 Click the Policies tab and select Lockout Policy.

4 Click Edit.

5 Edit the parameters.

Option Description

Description Optional description of the lockout policy.

Max number of failed login attempts Maximum number of failed login aempts that are allowed before the

account is locked.

Time interval between failures Time period in which failed login aempts must occur to trigger a lockout.

Unlock time Amount of time that the account remains locked. If you enter 0, the

administrator must unlock the account explicitly.

6 Click OK.

Edit the vCenter Single Sign-On Token Policy

ThevCenter Single Sign-On token policy species the clock tolerance, renewal count, and other token

properties. You can edit the vCenter Single Sign-On token policy to ensure that the token specication

conforms to your corporation's security standards.

Procedure

1 Log in to the vSphere Web Client.

2 Select Administration > Single Sign-On, and select .

3 Click the Policies tab and select Token Policy.

The vSphere Web Client displays the current conguration seings. If you have not modied the

default seings, vCenter Single Sign-On uses them.

4 Edit the token policy conguration parameters.

Option Description

Clock tolerance Time dierence, in milliseconds, that vCenter Single Sign-On tolerates

between a client clock and the domain controller clock. If the time

dierence is greater than the specied value, vCenter Single Sign-On

declares the token invalid.

Maximum token renewal count Maximum number of times that a token can be renewed. After the

maximum number of renewal aempts, a new security token is required.

Maximum token delegation count Holder-of-key tokens can be delegated to services in the vSphere

environment. A service that uses a delegated token performs the service on

behalf of the principal that provided the token. A token request species a

DelegateTo identity. The DelegateTo value can either be a solution token or

a reference to a solution token. This value species how many times a

single holder-of-key token can be delegated.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 53

Option Description

Maximum bearer token lifetime Bearer tokens provide authentication based only on possession of the

token. Bearer tokens are intended for short-term, single-operation use. A

bearer token does not verify the identity of the user or entity that is

sending the request. This value species the lifetime value of a bearer

token before the token has to be reissued.

Maximum holder-of-key token

lifetime

Holder-of-key tokens provide authentication based on security artifacts

that are embedded in the token. Holder-of-key tokens can be used for

delegation. A client can obtain a holder-of-key token and delegate that

token to another entity. The token contains the claims to identify the

originator and the delegate. In the vSphere environment, a vCenter Server

system obtains delegated tokens on a user's behalf and uses those tokens to

perform operations.

This value determines the lifetime of a holder-of-key token before the

token is marked invalid.

5 Click OK.

Managing vCenter Single Sign-On Users and Groups

A vCenter Single Sign-On administrator user can manage users and groups in the vsphere.local domain

from the vSphere Web Client.

The vCenter Single Sign-On administrator user can perform the following tasks.

nAdd vCenter Single Sign-On Users on page 55

Users listed on the Users tab in the vSphere Web Client are internal to vCenter Single Sign-On and

belong to the vsphere.local domain.

nDisable and Enable vCenter Single Sign-On Users on page 55

When a vCenter Single Sign-Onuser account is disabled, the user cannot log in to the vCenter Single

Sign-On server until the account is enabled by an administrator. You can disable and enable users from

the vSphere Web Client interface.

nDelete a vCenter Single Sign-On User on page 56

You can delete users that are in the vsphere.local domain from the vCenter Single Sign-On. You cannot

delete local operating system users or users in another domain from the vSphere Web Client.

nEdit a vCenter Single Sign-On User on page 56

You can change the password or other details of a vCenter Single Sign-On user from the

vSphere Web Client. You cannot rename users in the vsphere.local domain. That means you cannot

rename administrator@vsphere.local.

nAdd a vCenter Single Sign-On Group on page 57

In the vCenter Single Sign-On, groups listed on the Groups tab are internal to vCenter Single Sign-On.

A group lets you create a container for a collection of group members (principals).

nAdd Members to a vCenter Single Sign-On Group on page 57

Members of a vCenter Single Sign-On group can be users or other groups from one or more identity

sources. You can add new members from the vSphere Web Client.

nRemove Members from a vCenter Single Sign-On Group on page 58

You can remove members from a vCenter Single Sign-On group from the vSphere Web Client. When

you remove a member (user or group) from a local group, you do not delete the member from the

system.

vSphere Security

54 VMware, Inc.

nDelete vCenter Single Sign-On Solution Users on page 58

vCenter Single Sign-On displays solution users. A solution user is a collection of services. Several

vCenter Server solution users are predened and authenticate to vCenter Single Sign-On as part of

installation. In troubleshooting situations, for example, if an uninstall did not complete cleanly, you

can delete individual solution users from the vSphere Web Client.

nChange Your vCenter Single Sign-On Password on page 59

Users in the vsphere.local domain can change their vCenter Single Sign-On passwords from the

vSphere Web Client. Users in other domains change their passwords following the rules for that

domain. You can change a vCenter Single Sign-On password from the vSphere Web Client.

Add vCenter Single Sign-On Users

Users listed on the Users tab in the vSphere Web Client are internal to vCenter Single Sign-On and belong to

the vsphere.local domain.

You can select other domains and view information about the users in those domains, but you cannot add

users to other domains from the vCenter Single Sign-On management interface of the vSphere Web Client.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Click Home, and browse to Administration > Single Sign-On > Users and Groups.

3 If vsphere.local is not the currently selected domain, select it from the dropdown menu.

You cannot add users to other domains.

4 On the Users tab, click the New User icon.

5 Type a user name and password for the new user.

You cannot change the user name after you create a user.

The password must meet the password policy requirements for the system.

6 (Optional) Type the rst name and last name of the new user.

7 (Optional) Enter an email address and description for the user.

8 Click OK.

When you add a user, that user initially has no privileges to perform management operations.

What to do next

Add the user to a group in the vsphere.local domain, for example, to the group of users who can

administrator VMCA (CAAdmins) or to the group of users who can administer vCenter Single Sign-On

(Administrators). See “Add Members to a vCenter Single Sign-On Group,” on page 57.

Disable and Enable vCenter Single Sign-On Users

When a vCenter Single Sign-Onuser account is disabled, the user cannot log in to the vCenter Single Sign-

On server until the account is enabled by an administrator. You can disable and enable users from the

vSphere Web Client interface.

Disabled user accounts remain available in the vCenter Single Sign-On system, but the user cannot log in or

perform operations on the server. Users with administrator privileges can disable and enable users from the

vCenter Users and Groups page.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 55

Prerequisites

You must be a member of the vCenter Single Sign-On Administrators group to disable and enable vCenter

Single Sign-On users.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Click Home, and browse to Administration > Single Sign-On > Users and Groups.

3 Select a user, click the Disable icon, and click Yes when prompted.

4 To enable the user again, right-click the user, select Enable, and click Yes when prompted.

Delete a vCenter Single Sign-On User

You can delete users that are in the vsphere.local domain from the vCenter Single Sign-On. You cannot

delete local operating system users or users in another domain from the vSphere Web Client.

C If you delete the administrator user in the vsphere.local domain, you can no longer log in to

vCenter Single Sign-On. Reinstall vCenter Server and its components.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Click Home, and browse to Administration > Single Sign-On > Users and Groups.

3 Select the Users tab, and select the vsphere.local domain.

4 In the list of users, select the user that you want to delete and click the Delete icon.

Proceed with caution. You cannot undo this action.

Edit a vCenter Single Sign-On User

You can change the password or other details of a vCenter Single Sign-On user from the

vSphere Web Client. You cannot rename users in the vsphere.local domain. That means you cannot rename

administrator@vsphere.local.

You can create additional users with the same privileges as administrator@vsphere.local.

vCenter Single Sign-On users are stored in the vCenter Single Sign-On vsphere.local domain.

You can review the vCenter Single Sign-On password policies from the vSphere Web Client. Log in as

administrator@vsphere.local and select  > Policies > Password Policies.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Click Home, and browse to Administration > Single Sign-On > Users and Groups.

vSphere Security

56 VMware, Inc.

3 Click the Users tab.

4 Right-click the user and select Edit User.

5 Make changes to the user.

You cannot change the user name of the user.

The password must meet the password policy requirements for the system.

6 Click OK.

Add a vCenter Single Sign-On Group

In the vCenter Single Sign-On, groups listed on the Groups tab are internal to vCenter Single Sign-On. A

group lets you create a container for a collection of group members (principals).

When you add a vCenter Single Sign-On group from the vSphere Web Client administration interface, the

group is added to the vsphere.local domain.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Click Home, and browse to Administration > Single Sign-On > Users and Groups.

3 Select the Groups tab and click the New Group icon.

4 Enter a name and description for the group.

You cannot change the group name after you create the group.

5 Click OK.

What to do next

nAdd members to the group.

Add Members to a vCenter Single Sign-On Group

Members of a vCenter Single Sign-On group can be users or other groups from one or more identity sources.

You can add new members from the vSphere Web Client.

You can add members of Microsoft Active Directory or OpenLDAP groups to a vCenter Single Sign-On

group. You cannot add groups from external identity sources to a vCenter Single Sign-On group.

Groups listed on the Groups tab in the vSphere Web Client are part of the vsphere.local domain. See

“Groups in the vsphere.local Domain,” on page 27.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Click Home, and browse to Administration > Single Sign-On > Users and Groups.

3 Click the Groups tab and click the group (for example, Administrators).

4 In the Group Members area, click the Add Members icon.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 57

5 Select the identity source that contains the member to add to the group.

6 (Optional) Enter a search term and click Search.

7 Select the member and click Add.

You can simultaneously add multiple members.

8 Click OK.

Remove Members from a vCenter Single Sign-On Group

You can remove members from a vCenter Single Sign-On group from the vSphere Web Client. When you

remove a member (user or group) from a local group, you do not delete the member from the system.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Click Home, and browse to Administration > Single Sign-On > Users and Groups.

3 Select the Groups tab and click the group.

4 In the list of group members, select the user or group that you want to remove and click the Remove

Member icon.

5 Click OK.

The user is removed from the group, but is still available in the system.

Delete vCenter Single Sign-On Solution Users

vCenter Single Sign-On displays solution users. A solution user is a collection of services. Several

vCenter Server solution users are predened and authenticate to vCenter Single Sign-On as part of

installation. In troubleshooting situations, for example, if an uninstall did not complete cleanly, you can

delete individual solution users from the vSphere Web Client.

When you remove the set of services associated with a vCenter Server solution user or a third-party solution

user from your environment, the solution user is removed from the vSphere Web Client display. If you

forcefully remove an application, or if the system becomes unrecoverable while the solution user is still in

the system, you can remove the solution user explicitly from the vSphere Web Client.

I If you delete a solution user, the corresponding services can no longer authenticate to vCenter

Single Sign-On.

Procedure

1 Log in to the vSphere Web Client as administrator@vsphere.local or as another user with vCenter Single

Sign-On administrator privileges.

Users with vCenter Single Sign-On administrator privileges are in the Administrators group in the

vsphere.local domain.

2 Click Home, and browse to Administration > Single Sign-On > Users and Groups.

3 Click the Solution Users tab, and click the solution user name.

4 Click the Delete Solution User icon.

5 Click Yes.

vSphere Security

58 VMware, Inc.

The services associated with the solution user no longer have access to vCenter Server and cannot function

as vCenter Server services.

Change Your vCenter Single Sign-On Password

Users in the vsphere.local domain can change their vCenter Single Sign-On passwords from the

vSphere Web Client. Users in other domains change their passwords following the rules for that domain.

You can change a vCenter Single Sign-On password from the vSphere Web Client.

The vCenter Single Sign-On lockout policy determines when your password expires. By default, vCenter

Single Sign-On user passwords expire after 90 days, but administrator passwords such as the password for

administrator@vsphere.local do not expire. vCenter Single Sign-On management interfaces show a warning

when your password is about to expire.

This procedure explains how you can change a password. If your password is expired, the administrator of

the local domain (vsphere.local by default) or another member of the Administrators group for the local

domain can reset the password by using the dir-cli password reset command.

Procedure

1 Log in to the vSphere Web Client using your vCenter Single Sign-On credentials.

2 In the upper navigation pane, to the left of the Help menu, click your user name to pull down the menu.

As an alternative, you can select Administration > Single Sign-On > Users and Groups and select Edit

User from the right-buon menu.

3 Select Change Password and type your current password.

4 Type a new password and conrm it.

The password must conform to the password policy.

5 Click OK.

vCenter Single Sign-On Security Best Practices

Follow vCenter Single Sign-On security best practices to protect your vSphere environment.

The vSphere 6.0 authentication and certicate infrastructure enhances security in your vSphere

environment. To make sure that infrastructure is not compromised, follow vCenter Single Sign-On Best

Practices.

Check password

expiration

The default vCenter Single Sign-On password policy has a password lifetime

of 90 days. After 90 days, the password is expired and the ability to log is

compromised. Check the expiration and refresh passwords in a timely

fashion.

Configure NTP Ensure that all systems use the same relative time source (including the

relevant localization oset), and that the relative time source can be

correlated to an agreed-upon time standard (such as Coordinated Universal

Time—UTC). Synchronized systems are essential for vCenter Single Sign-On

certicate validity, and for the validity of other vSphere certicates.

NTP also makes it easier to track an intruder in log les. Incorrect time

seings can make it dicult to inspect and correlate log les to detect

aacks, and can make auditing inaccurate.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 59

Troubleshooting vCenter Single Sign-On

Conguring vCenter Single Sign-On can be a complex process.

The following topics provide a starting point for troubleshooting vCenter Single Sign-On. Search this

documentation center and the VMware Knowledge Base system for additional pointers.

Determining the Cause of a Lookup Service Error

vCenter Single Sign-On installation displays an error referring to the vCenter Server or the vSphere Web

Client.

Problem

vCenter Server and Web Client installers show the error Could not contact Lookup Service. Please check

VM_ssoreg.log....

Cause

This problem has several causes, including unsynchronized clocks on the host machines, rewall blocking,

and services that must be started.

Solution

1 Verify that the clocks on the host machines running vCenter Single Sign-On, vCenter Server, and the

Web Client are synchronized.

2 View the specic log le found in the error message.

In the message, system temporary folder refers to %TEMP%.

3 Within the log le, search for the following messages.

The log le contains output from all installation aempts. Locate the last message that shows

Initializing registration provider...

Message Cause and solution

java.net.ConnectException:

Connection timed out: connect

The IP address is incorrect, a rewall is blocking access to vCenter Single

Sign-On, or vCenter Single Sign-On is overloaded.

Ensure that a rewall is not blocking the vCenter Single Sign-On port (by

default 7444) and that the machine on which vCenter Single Sign-On is

installed has adequate free CPU, I/O. and RAM capacity.

java.net.ConnectException:

Connection refused: connect

IThe IP address or FQDN is incorrect and the vCenter Single Sign-On

service has not started or has started within the past minute.

Verify that vCenter Single Sign-On is working by checking the status of

vCenter Single Sign-On service (Windows) and vmware-sso daemon

(Linux).

Restart the service. If this does not correct the problem, see the recovery

section of the vSphere troubleshooting guide.

vSphere Security

60 VMware, Inc.

Message Cause and solution

Unexpected status code: 404. SSO

Server failed during initialization

Restart vCenter Single Sign-On. If this does not correct the problem, see

the Recovery section of the vSphere Troubleshooting Guide.

The error shown in the UI begins

with Could not connect to

vCenter Single Sign-on.

You also see the return code SslHandshakeFailed. This is an uncommon

error. It indicates that the provided IP address or FQDN that resolves to

vCenter Single Sign-On host was not the one used when you installed

vCenter Single Sign-On.

In %TEMP%\VM_ssoreg.log, nd the line that contains the following

message.

host name in certificate did not match: <install-configured

FQDN or IP> != <A> or <B> or <C> where A was the FQDN you

entered during the vCenter Single Sign-On installation, and B and C are

system-generated allowable alternatives.

Correct the conguration to use the FQDN on the right of the != sign in the

log le. In most cases, use the FQDN that you specied during vCenter

Single Sign-On installation.

If none of the alternatives are possible in your network conguration,

recover your vCenter Single Sign-On SSL conguration.

Unable to Log In Using Active Directory Domain Authentication

You log in to a vCenter Server component from the vSphere Web Client. You use your Active Directory user

name and password. Authentication fails.

Problem

You add an Active Directory identity source to vCenter Single Sign-On, but users cannot log in to

vCenter Server.

Cause

Users use their user name and password to log in to the default domain. For all other domains, users must

include the domain name (user@domain or DOMAIN\user).

If you are using the vCenter Server Appliance, other problems might exist.

Solution

For all vCenter Single Sign-On deployments, you can change the default identity source. After that change,

users can log in to the default identity source with username and password only.

To congure your Integrated Windows Authentication identity source with a child domain within your

Active Directory forest, see VMware Knowledge Base article 2070433. By default, Integrated Windows

Authentication uses the root domain of your Active Directory forest.

If you are using the vCenter Server Appliance, and changing the default identity source does not resolve the

issue, perform the following additional troubleshooting steps.

1 Synchronize the clocks between the vCenter Server Appliance and the Active Directory domain

controllers.

2 Verify that each domain controller has a pointer record (PTR) in the Active Directory domain DNS

service and that the PTR record information matches the DNS name of the controller. When using the

vCenter Server Appliance, you can run the following commands to perform the task:

a To list the domain controllers run the following command:

# dig SRV _ldap._tcp.my-ad.com

The relevant addresses are in the answer section, as in the following example:

;; ANSWER SECTION:

_ldap._tcp.my-ad.com. (...) my-controller.my-ad.com

...

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 61

b For each domain controller, verify forward and reverse resolution by running the following

command:

# dig my-controller.my-ad.com

The relevant addresses are in the answer section, as in the following example:

;; ANSWER SECTION:

my-controller.my-ad.com (...) IN A controller IP address

...

# dig -x <controller IP address>

The relevant addresses are in the answer section, as in the following example:

;; ANSWER SECTION:

IP-in-reverse.in-addr.arpa. (...) IN PTR my-controller.my-ad.com

...

3 If that does not resolve the problem, remove the vCenter Server Appliance from the Active Directory

domain and then rejoin the domain. See the vCenter Server Appliance Conguration documentation.

4 Close all browser sessions connected to the vCenter Server Appliance and restart all services.

/bin/service-control --restart --all

vCenter Server Login Fails Because the User Account is Locked

When you log in to vCenter Server from the vSphere Web Client login page, an error indicates that the

account is locked.

Problem

After several failed aempts, you cannot log in to the vSphere Web Client using vCenter Single Sign-On.

You see the message that your account is locked.

Cause

You exceeded the maximum number of failed login aempts.

Solution

nIf you log in as a user from the system domain (vsphere.local), ask your vCenter Single Sign-On

administrator to unlock your account. As an alternative, you can wait until your account is unlocked, if

the lock is set to expire in the password policy. vCenter Single Sign-On administrators can use CLI

commands to unlock your account.

nIf you log in as a user from an Active Directory or LDAP domain, ask your Active Directory or LDAP

administrator to unlock your account.

VMware Directory Service Replication Can Take a Long Time

If your environment includes multiple Platform Services Controller instances, and if one of the

Platform Services Controller instances becomes unavailable, your environment continues to function. When

the Platform Services Controller becomes available again, user data and other information are usually

replicated within 60 seconds. In certain special circumstances, however, replication might take a long time.

Problem

In certain situations, for example, when your environment includes multiple Platform Services Controller

instances in dierent locations, and you make signicant changes while one Platform Services Controller is

unavailable, you do not see replication across VMware Directory Service instances right away. For example,

you do not see a new user that was added to the available Platform Services Controller instance in the other

instance until replication is complete.

vSphere Security

62 VMware, Inc.

Cause

During normal operation, changes to a VMware Directory Service (vmdir) instance in one

Platform Services Controller instance (node) show up in its direct replication partner within about 60

seconds. Depending on the replication topology, changes in one node might have to propagate through

intermediate nodes before they arrive at each vmdir instance in each node. Information that is replicated

includes user information, certicate information, license information for virtual machines that are created,

cloned, or migrated with VMware VMotion, and more.

When the replication link is broken, for example, because of a network outage or because a node becomes

unavailable, changes in the federation do not converge. After the unavailable node is restored, each node

tries to catch up with all changes. Eventually, all vmdir instances converge to a consistent state but it might

take a while to reach that consistent state if many changes occurred while one node was unavailable.

Solution

Your environment functions normally while replication happens. Do not aempt to solve the problem

unless it persists for over an hour.

Chapter 2 vSphere Authentication with vCenter Single Sign-On

VMware, Inc. 63

vSphere Security

64 VMware, Inc.

vSphere Security Certificates 3

vSphere components use SSL to communicate securely with each other and with ESXi. SSL communications

ensure data condentiality and integrity. Data is protected, and cannot be modied in transit without

detection.

Certicates are also used by vCenter Server services such as the vSphere Web Client for 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 Certicate Authority (VMCA) provisions each ESXi host and each

vCenter Server service with a certicate that is signed by VMCA by default.

You can replace the existing certicates with new VMCA-signed certicates, make VMCA a subordinate CA,

or replace all certicates with custom certicates. You have several options:

Table 3‑1. Different Approaches to Certificate Replacement

Option See

Use the Platform Services Controller web interface

(vSphere 6.0 Update 1 and later).

“Managing Certicates with the Platform Services

Controller Web Interface,” on page 76

Use the vSphere Certicate Manager utility from the

command line.

“Managing Certicates with the vSphere Certicate

Manager Utility,” on page 83

Use CLI commands for manual certicate replacement. “Managing Certicates and Services with CLI Commands,”

on page 118

vSphere Certicate Management

(hp://link.brightcove.com/services/player/bcpid2296383276001?

bctid=ref:video_vsphere6_cert_infrastructure)

This chapter includes the following topics:

n“Certicate Management Overview,” on page 66

n“Managing Certicates with the Platform Services Controller Web Interface,” on page 76

n“Managing Certicates with the vSphere Certicate Manager Utility,” on page 83

n“Manual Certicate Replacement,” on page 92

n“Managing Certicates and Services with CLI Commands,” on page 118

n“View vCenter Certicates with the vSphere Web Client,” on page 133

n“Set the Threshold for vCenter Certicate Expiration Warnings,” on page 133

VMware, Inc. 65

Certificate Management Overview

The impact of the new certicate infrastructure depends on the requirements in your environment, on

whether you are performing a fresh install or an upgrade, and on whether you are considering ESXi or

vCenter Server.

Administrators Who Do Not Replace VMware Certificates

If you are an administrator who does not currently replace VMware certicates, VMCA can handle all

certicate management for you. VMCA provisions vCenter Server components and ESXi hosts with

certicates that use VMCA as the root certicate authority. If you are upgrading to vSphere 6 from an earlier

version of vSphere, all self-signed certicates are replaced with certicates that are signed by VMCA.

Administrators Who Replace VMware Certificates with Custom Certificates

For a fresh installation, administrators have these choices if company policy requires certicates that are

signed by a third-party or enterprise certicate authority or requires custom certicate information.

nReplace the VMCA root certicate with a CA-signed certicate. In this scenario, the VMCA certicate is

an intermediate certicate of this third-party CA. VMCA provisions vCenter Server components and

ESXi hosts with certicates that include the full certicate chain.

nIf company policy does not allow intermediate certicates in the chain, you have to explicitly replace

certicates. You can use the vSphere Certicate Manager utility or perform manual certicate

replacement using the certicate management CLIs.

When upgrading an environment that uses custom certicates, you can retain some of the certicates.

nESXi hosts keep their custom certicates during upgrade. Make sure that the vCenter Server upgrade

process adds all the relevant root certicate to the TRUSTED_ROOTS store in VECS on the

vCenter Server.

After the vCenter Server upgrade, administrators can set the certicate mode to Custom (see “Change

the Certicate Mode,” on page 167). If certicate mode is VMCA, the default, and the user performs a

certicate refresh from the vSphere Web Client, the VMCA-signed certicates replace the custom

certicates.

nFor vCenter Server components, what happens depends on the existing environment.

nIf you upgrade a simple installation to an embedded deployment, vCenter Server custom

certicates are retained. After the upgrade, your environment will work as before.

nIf you upgrade a multi-site deployment where vCenter Single Sign-On is on a dierent machine

than other vCenter Server components, the upgrade process creates a multi-node deployment that

includes a Platform Services Controller node and one or more management nodes.

In this scenario, the existing vCenter Server and vCenter Single Sign-On certicates are retained

and used as machine SSL certicates. VMCA assigns a VMCA-signed certicate to each solution

user (collection of vCenter services). A solution user uses this certicate only to authenticate to

vCenter Single Sign-On, so it might be unnecessary to replace solution user certicates.

You can no longer use the vSphere 5.5 certicate replacement tool, which was available for vSphere 5.5

installations, because the new architecture results in a dierent service distribution and placement. A

new command-line utility, vSphere Certicate Manager, is available for most certicate management

tasks.

vSphere Security

66 VMware, Inc.

vCenter Certificate Interfaces

For vCenter Server, you can view and replace certicates with the following tools and interfaces.

vSphere Certificate

Manager utility

Perform all common certicate replacement tasks from the command-line.

Certificate management

CLIs

Perform all certicate management tasks with dir-cli, certool, and vecs-

cli.

vSphere Web Client

certificate management

View certicates, including expiration information.

For ESXi, you perform certicate management from the vSphere Web Client. Certicates are provisioned by

VMCA and are stored only locally on the ESXi host, not in vmdir or VECS. See “Certicate Management for

ESXi Hosts,” on page 160.

Supported vCenter Certificates

For vCenter Server, the Platform Services Controller, and related machines and services, the following

certicates are supported:

nCerticates that are generated and signed by VMware Certicate Authority (VMCA).

nCustom certicates.

nEnterprise certicates that are generated from your own internal PKI.

nThird-party CA-signed certicates that are generated by an external PKI such as Verisign,

GoDaddy, and so on.

Self-signed certicates that were created using OpenSSL in which no Root CA exists are not supported.

Certificate Replacement Overview

You can perform dierent types of certicate replacement depending on company policy and requirements

for the system that you are conguring. You can perform each replacement with the vSphere Certicate

Manager utility or manually by using the CLIs included with your installation.

You can replace the default certicates. For vCenter Server components, you can use a set of command-line

tools included in your installation. You have several options.

Replace With Certificates Signed by VMCA

If your VMCA certicate expires or you want to replace it for other reasons, you can use the certicate

management CLIs to perform that process. By default, the VMCA root certicate expires after ten years, and

all certicates that VMCA signs expire when the root certicate expires, that is, after a maximum of ten

years.

Chapter 3 vSphere Security Certificates

VMware, Inc. 67

Figure 3‑1. Certificates Signed by VMCA Are Stored in VECS

CA-Cert

VECS

Machine-Cert

Signed

VMCA

Make VMCA an Intermediate CA

You can replace the VMCA root certicate with a certicate that is signed by an enterprise CA or third-party

CA. VMCA signs the custom root certicate each time it provisions certicates, making VMCA an

intermediate CA.

N If you perform a fresh install that includes an external Platform Services Controller, install the

Platform Services Controller rst and replace the VMCA root certicate. Next, install other services or add

ESXi hosts to your environment. If you perform a fresh install with an embedded

Platform Services Controller, replace the VMCA root certicate before you add ESXi hosts. If you do, all

certicates are signed by the whole chain, and you do not have to generate new certicates.

Figure 3‑2. Certificates Signed by a Third-Party or Enterprise CA Use VMCA as an Intermediate CA

CA-Cert

VECS

Machine-Cert

Signed

VMware vSphere

VMCA

Root

CA-Cert

Enterprise

CA-Cert

Signed Signed

Do Not Use VMCA, Provision with Custom Certificates

You can replace the existing VMCA-signed certicates with custom certicates. If you use that approach,

you are responsible for all certicate provisioning and monitoring.

vSphere Security

68 VMware, Inc.

Figure 3‑3. External Certificates are Stored Directly in VECS

Unused

VECS

Machine-Cert

VMware vSphere

VMCA

External CA

(Commercial or

Enterprise)

Signed

Hybrid Deployment

You can have VMCA supply some of the certicates, but use custom certicates for other parts of your

infrastructure. For example, because solution user certicates are used only to authenticate to vCenter Single

Sign-On, consider having VMCA provision those certicates. Replace the machine SSL certicates with

custom certicates to secure all SSL trac.

ESXi Certificate Replacement

For ESXi hosts, you can change certicate provisioning behavior from the vSphere Web Client.

VMware Certificate

Authority mode (default)

When you renew certicates from the vSphere Web Client, VMCA issues the

certicates for the hosts. If you changed the VMCA root certicate to include

a certicate chain, the host certicates include the full chain.

Custom Certificate

Authority mode

Allows you to manually update and use certicates that are not signed or

issued by VMCA.

Thumbprint mode Can be used to retain 5.5 certicates during refresh. Use this mode only

temporarily in debugging situations.

Where vSphere 6.0 Uses Certificates

In vSphere 6.0 and later, the VMware Certicate Authority (VMCA) provisions your environment with

certicates. This includes machine SSL certicates for secure connections, solution user certicates for

authentication to vCenter Single Sign-On, and certicates for ESXi hosts that are added to vCenter Server.

The following certicates are in use.

Table 3‑2. Certificates in vSphere 6.0

Certificate Provisioned by Stored

ESXi certicates VMCA (default) Locally on ESXi host

Machine SSL certicates VMCA (default) VECS

Solution user certicates VMCA (default) VECS

Chapter 3 vSphere Security Certificates

VMware, Inc. 69

Table 3‑2. Certificates in vSphere 6.0 (Continued)

Certificate Provisioned by Stored

vCenter Single Sign-On SSL

signing certicate

Provisioned during installation. Manage this certicate from the

vSphere Web Client.

Do not change this certicate in the lesystem or

unpredictable behavior results.

VMware Directory Service

(vmdir) SSL certicate

Provisioned during installation. In certain corner cases, you might have to replace

this certicate. See “Replace the VMware

Directory Service Certicate,” on page 110.

ESXi

ESXi certicates are stored locally on each host in the /etc/vmware/ssl directory. ESXi certicates are

provisioned by VMCA by default, but you can use custom certicates instead. ESXi certicates are

provisioned when the host is rst added to vCenter Server and when the host reconnects.

Machine SSL Certificates

The machine SSL certicate for each node is used to create an SSL socket on the server side to which SSL

clients connect. The certicate is used for server verication and for secure communication such as HTTPS

or LDAPS.

All services communicate through the reverse proxy. For compatibility, services that were available in earlier

versions of vSphere also use specic ports. For example, the vpxd service uses the MACHINE_SSL_CERT to

expose its endpoint.

Every node (embedded deployment, management node, or Platform Services Controller), has its own

machine SSL certicate. All services that are running on that node use this machine SSL certicate to expose

their SSL endpoints.

The machine SSL certicate is used as follows:

nBy the reverse proxy service on each Platform Services Controller node. SSL connections to individual

vCenter services always go to the reverse proxy. Trac does not go to the services themselves.

nBy the vCenter service (vpxd) on management nodes and embedded nodes.

nBy the VMware Directory Service (vmdir) on infrastructure nodes and embedded nodes.

VMware products use standard X.509 version 3 (X.509v3) certicates to encrypt session information that is

sent over SSL between components.

Solution User Certificates

A solution user encapsulates one or more vCenter Server services and uses the certicates to authenticate to

vCenter Single Sign-On through SAML token exchange. Each solution user must be authenticated to

vCenter Single Sign-On.

Solution user certicates are used for authentication tovCenter Single Sign-On. A solution user presents the

certicate to vCenter Single Sign-On when it rst has to authenticate, after a reboot, and after a timeout has

elapsed. The timeout (Holder-of-Key Timeout) can be set from the vSphere Web Client and defaults to

2592000 seconds (30 days).

For example, the vpxd solution user presents its certicate to vCenter Single Sign-On when it connects to

vCenter Single Sign-On. The vpxd solution user receives a SAML token from vCenter Single Sign-On and

can then use that token to authenticate to other solution users and services.

vSphere Security

70 VMware, Inc.

The following solution user certicate stores are included in VECS on each management node and each

embedded deployment:

nmachine: Used by component manager, license server, and the logging service.

N The machine solution user certicate has nothing to do with the machine SSL certicate. The

machine solution user certicate is used for the SAML token exchange; the machine SSL certicate is

used for secure SSL connections for a machine.

nvpxd: vCenter service daemon (vpxd) store on management nodes and embedded deployments. vpxd

uses the solution user certicate that is stored in this store to authenticate to vCenter Single Sign-On.

nvpxd-extensions: vCenter extensions store. Includes the Auto Deploy service, inventory service, and

other services that are not part of other solution users.

nvsphere-webclient: vSphere Web Client store. Also includes some additional services such as the

performance chart service.

The machine store is also included on each Platform Services Controller node.

vCenter Single Sign-On Certificates

vCenter Single Sign-On certicates are not stored in VECS and are not managed with certicate

management tools. As a rule, changes are not necessary, but in special situations, you can replace these

certicates.

vCenter Single Sign-On

Signing Certificate

The vCenter Single Sign-On service includes an identity provider service

which issues SAML tokens that are used for authentication throughout

vSphere. A SAML token represents the user's identity, and also contains

group membership information. When vCenter Single Sign-On issues SAML

tokens, it signs each token with its signing certicate so that clients of

vCenter Single Sign-On can verify that the SAML token comes from a trusted

source.

vCenter Single Sign-On issues holder-of-key SAML tokens to solution users

and bearer tokens other users, which log in with a user name and password.

You can replace this certicate from the vSphere Web Client. See “Refresh the

STS Root Certicate,” on page 50.

VMware Directory

Service SSL Certificate

If you are using custom certicates, you might have to replace the VMware

Directory Service SSL certicate explicitly. See “Replace the VMware

Directory Service Certicate,” on page 110.

Certificate Requirements

When you want to use third-party certicates in your environment, you must make sure that they meet

requirements. Certicates that VMCA provisions already meet these requirements.

nKey size: 2048 bits or more (PEM encoded)

nPEM format. VMware supports PKCS8 and PKCS1 (RSA keys). When keys are added to VECS, they are

converted to PKCS8

nx509 version 3

nFor root certicates, the CA extension must be set to true, and the cert sign must be in the list of

requirements.

nSubjectAltName must contain DNS Name=<machine_FQDN>

nCRT format

Chapter 3 vSphere Security Certificates

VMware, Inc. 71

nContains the following Key Usages: Digital Signature, Non Repudiation, Key Encipherment

N The algorithms md2WithRSAEncryption 1.2.840.113549.1.1.2, md5WithRSAEncryption

1.2.840.113549.1.1.4 , and sha1WithRSAEncryption 1.2.840.113549.1.1.5 are not recommended. The algorithm

RSASSA-PSS with OID 1.2.840.113549.1.1.10 is not supported.

VMCA and VMware Core Identity Services

Core identity services are part of every embedded deployment and every platform services node. VMCA is

part of every VMware core identity services group. Use the management CLIs and the vSphere Web Client

to interact with these services.

VMware core identity services include several components.

Table 3‑3. Core Identity Services

Service Description Included in

VMware Directory Service

(vmdir)

Handles SAML certicate management for

authentication in conjunction with vCenter

Single Sign-On.

Platform Services Controller

Embedded deployment

VMware Certicate Authority

(VMCA)

Issues certicates for VMware solution users,

machine certicates for machines on which

services are running, and ESXi host certicates.

VMCA can be used as is, or as an intermediary

certicate authority.

VMCA issues certicates only to clients that can

authenticate to vCenter Single Sign-On in the

same domain.

Platform Services Controller

Embedded deployment

VMware Authentication

Framework Daemon (VMAFD)

Includes the VMware Endpoint Certicate Store

(VECS) and several other authentication services.

VMware administrators interact with VECS; the

other services are used internally.

Platform Services Controller

vCenter Server

Embedded deployment

VMware Endpoint Certificate Store Overview

VMware Endpoint Certicate Store (VECS) serves as a local (client-side) repository for certicates, private

keys, and other certicate information that can be stored in a keystore. You can decide not to use VMCA as

your certicate authority and certicate signer, but you must use VECS to store all vCenter certicates, keys,

and so on. ESXi certicates are stored locally on each host and not in VECS.

VECS runs as part of the VMware Authentication Framework Daemon (VMAFD). VECS runs on every

embedded deployment, Platform Services Controller node, and management node and holds the keystores

that contain the certicates and keys.

VECS polls VMware Directory Service (vmdir) periodically for updates to the TRUSTED_ROOTS store. You

can also explicitly manage certicates and keys in VECS using vecs-cli commands. See “vecs-cli Command

Reference,” on page 125.

VECS includes the following stores.

vSphere Security

72 VMware, Inc.

Table 3‑4. Stores in VECS

Store Description

Machine SSL store (MACHINE_SSL_CERT) nUsed by the reverse proxy service on every vSphere

node.

nUsed by the VMware Directory Service (vmdir) on

embedded deployments and on each

Platform Services Controller node.

All services in vSphere 6.0 communicate through a reverse

proxy, which uses the machine SSL certicate. For

backward compatibility, the 5.x services still use specic

ports. As a result, some services such as vpxd still have

their own port open.

Trusted root store (TRUSTED_ROOTS) Contains all trusted root certicates.

Solution user stores

nmachine

nvpxd

nvpxd-extensions

nvsphere-webclient

VECS includes one store for each solution user. The subject

of each solution user certicate must be unique, for

example, the machine certicate cannot have the same

subject as the vpxd certicate.

Solution user certicates are used for authentication with

vCenter Single Sign-On. vCenter Single Sign-On checks

that the certicate is valid, but does not check other

certicate aributes. In an embedded deployment, all

solution user certicates are on the same system.

The following solution user certicate stores are included

in VECS on each management node and each embedded

deployment:

nmachine: Used by component manager, license server,

and the logging service.

N The machine solution user certicate has

nothing to do with the machine SSL certicate. The

machine solution user certicate is used for the SAML

token exchange; the machine SSL certicate is used for

secure SSL connections for a machine.

nvpxd: vCenter service daemon (vpxd) store on

management nodes and embedded deployments. vpxd

uses the solution user certicate that is stored in this

store to authenticate to vCenter Single Sign-On.

nvpxd-extensions: vCenter extensions store. Includes

the Auto Deploy service, inventory service, and other

services that are not part of other solution users.

nvsphere-webclient: vSphere Web Client store. Also

includes some additional services such as the

performance chart service.

The machine store is also included on each

Platform Services Controller node.

vSphere Certicate Manager Utility backup store

(BACKUP_STORE)

Used by VMCA (VMware Certicate Manager) to support

certicate revert. Only the most recent state is stored as a

backup, you cannot go back more than one step.

Other stores Other stores might be added by solutions. For example, the

Virtual Volumes solution adds an SMS store. Do not

modify the certicates in those stores unless VMware

documentation or a VMware Knowledge Base artoc;e

instructs you to do so.

N CRLS are not supported in vSphere 6.0

Nevertheless, deleting the TRUSTED_ROOTS_CRLS store

can damage your certicate infrastructure. Do not delete or

modify the TRUSTED_ROOTS_CRLS store.

Chapter 3 vSphere Security Certificates

VMware, Inc. 73

The vCenter Single Sign-On service stores the token signing certicate and its SSL certicate on disk. You

can change the token signing certicate from the vSphere Web Client.

N Do not change any certicate les on disk unless instructed by VMware documentation or

Knowledge Base Articles. Unpredictable behavior might result otherwise.

Some certicates are stored on the lesystem, either temporarily during startup or permanently. Do not

change the certicates on the le system. Use vecs-cli to perform operations on certicates that are stored

in VECS.

Managing Certificate Revocation

If you suspect that one of your certicates has been compromised, replace all existing certicates, including

the VMCA root certicate.

vSphere 6.0 supports replacing certicates but does not enforce certicate revocation for ESXi hosts or for

vCenter Server systems.

Remove revoked certicates from all nodes. If you do not remove revoked certicates, a man-in-the-middle

aack might enable compromise through impersonation with the account's credentials.

Certificate Replacement in Large Deployments

Certicate replacement in deployments that include multiple management nodes and one or more

Platform Services Controller node is similar to replacement in embedded deployments. In both cases, you

can use the vSphere Certicate Management utility or replace certicates manually. Some best practices

guide the replacement process.

Certificate Replacement in High Availability Environments that Include a Load

Balancer

In environments with less than eight vCenter Server systems, VMware typically recommends a single

Platform Services Controller instance and associated vCenter Single Sign-On service. In larger

environments, consider using multiple Platform Services Controller instances, protected by a network load

balancer. The white paper vCenter Server 6.0 Deployment Guide on the VMware website discusses this setup.

Replacement of Machine SSL Certificates in Environments with Multiple

Management Nodes

If your environment includes multiple management nodes and a single Platform Services Controller, you

can replace certicates with the vSphere Certicate Manager utility, or manually with vSphere CLI

commands.

vSphere Certificate

Manager

You run vSphere Certicate Manager on each machine. On management

nodes, you are prompted for the IP address of the

Platform Services Controller. Depending on the task you perform, you are

also prompted for certicate information.

Manual Certificate

Replacement

For manual certicate replacement, you run the certicate replacement

commands on each machine. On management nodes, you must specify the

Platform Services Controller with the --server parameter. See the following

topics for details:

n“Replace Machine SSL Certicates with VMCA-Signed Certicates,” on

page 94

n“Replace Machine SSL Certicates (Intermediate CA),” on page 104

vSphere Security

74 VMware, Inc.

n“Replace Machine SSL Certicates With Custom Certicates,” on

page 114

Replacement of Solution User Certificates in Environments with Multiple

Management Nodes

If your environment includes multiple management nodes and a single Platform Services Controller, follow

these steps for certicate replacement.

N When you list solution user certicates in large deployments, the output of dir-cli list includes all

solution users from all nodes. Run vmafd-cli get-machine-id --server-name localhost to nd the local

machine ID for each host. Each solution user name includes the machine ID.

vSphere Certificate

Manager

You run vSphere Certicate Manager on each machine. On management

nodes, you are prompted for the IP address of the

Platform Services Controller. Depending on the task you perform, you are

also prompted for certicate information.

Manual Certificate

Replacement

1 Generate or request a certicate. You need the following certicates:

nA certicate for the machine solution user on the

Platform Services Controller.

nA certicate for the machine solution user on each management

node.

nA certicate for each of the following solution users on each

management node:

nvpxd solution user

nvpxd-extension solution user

nvsphere-webclient solution user

2 Replace the certicates on each node. The precise process depends on

the type of certicate replacement that you are performing. See

“Managing Certicates with the vSphere Certicate Manager Utility,” on

page 83

See the following topics for details:

n“Replace Solution User Certicates With New VMCA-Signed

Certicates,” on page 97

n“Replace Solution User Certicates (Intermediate CA),” on page 106

n“Replace Solution User Certicates With Custom Certicates,” on

page 115

If company policy requires that you replace all certicates, you also have to replace the VMware Directory

Service (vmdir) certicate on the Platform Services Controller. See “Replace the VMware Directory Service

Certicate,” on page 110.

Chapter 3 vSphere Security Certificates

VMware, Inc. 75

Certificate Replacement in Environments that Include External Solutions

Some solutions, such as VMware vCenter Site Recovery Manager or VMware vSphere Replication are

always installed on a dierent machine than the vCenter Server system or Platform Services Controller. If

you replace the default machine SSL certicate on the vCenter Server system or the

Platform Services Controller, a connection error results if the solution aempts to connect to the

vCenter Server system.

You can run the ls_update_certs script to resolve the issue. See VMware Knowledge Base article 2109074 for

details.

Managing Certificates with the Platform Services Controller Web

Interface

You can view and manage certicates by logging in to the Platform Services Controller web interface. You

can perform many certicate management tasks either with the vSphere Certicate Manager utility or by

using this web interface.

The Platform Services Controller web interface allows you to perform these management tasks.

nView the current certicate stores and add and remove certicate store entries.

nView the VMware Certicate Authority (VMCA) instance associated with this

Platform Services Controller.

nView certicates that are generated by VMware Certicate Authority.

nRenew existing certicates or replace certicates.

Most parts of the certicate replacement workows are supported fully from the

Platform Services Controller web interface. For generating CSRs, you can use the vSphere Certicate

Manage utility.

Supported Workflows

After you install a Platform Services Controller, the VMware Certicate Authority on that node provisions

all other nodes in the environment with certicates by default. You can use one of the following workows

to renew or replace certicates.

Renew Certificates You can have VMCA generate a new root certicate and renew all certicates

in your environment from the Platform Services Controller web interface.

Make VMCA an

Intermediate CA

You can generate a CSR using the vSphere Certicate Manager utility, edit

the certicate you receive from the CSR to add VMCA to the chain, and then

add the certicate chain and private key to your environment. When you

then renew all certicates, VMCA provisions all machines and solution users

with certicates that are signed by the full chain.

Replace Certificates

with Custom

Certificates

If you do not want to use VMCA, you can generate CSRs for the certicates

that you want to replace. The CA returns a root certicate and a signed

certicate for each CSR. You can upload the root certicate and the custom

certicates from the Platform Services Controller.

If you have to replace the VMware Directory Service (vmdir) root certicate, or if company policy requires

that you replace the vCenter Single Sign-On certicate in a mixed-mode environment, you can use CLI

commands to replace those certicates after replacing the other certicates. See “Replace the VMware

Directory Service Certicate,” on page 110 and “Replace the VMware Directory Service Certicate in Mixed

Mode Environments,” on page 101.

vSphere Security

76 VMware, Inc.

Explore Certificate Stores from the Platform Services Controller Web Interface

A VMware Endpoint Certicate Store (VECS) instance is included on each Platform Services Controller node

and each vCenter Server node. You can explore the dierent stores inside the VMware Endpoint Certicate

Store from the Platform Services Controller web interface.

See “VMware Endpoint Certicate Store Overview,” on page 72 for details on the dierent stores inside

VECS.

Prerequisites

For most management tasks, you must have the password for the administrator for the local domain

account, administrator@vsphere.local or a dierent domain if you changed the domain during installation.

Procedure

1 From a Web browser, connect to the Platform Services Controller by specifying the following URL:

https://psc_hostname_or_IP/psc

In an embedded deployment, the Platform Services Controller host name or IP address is the same as

the vCenter Server host name or IP address.

2 Specify the user name and password for administrator@vsphere.local or another member of the vCenter

Single Sign-On Administrators group.

If you specied a dierent domain during installation, log in as administrator@mydomain.

3 Under Certicates, click  Store and explore the store.

4 Select the store inside the VMware Endpoint Certicate Store (VECS) that you want to explore from the

pulldown menu.

“VMware Endpoint Certicate Store Overview,” on page 72 explains what's in the individual stores.

5 To view details for a certicate, select the certicate and click the Show Details icon.

6 To delete an entry from the selected store, click the Delete Entry icon.

For example, if you replace the existing certicate, you can later remove the old root certicate. Remove

certicates only if you are sure that they are no longer in use.

Replace Certificates with New VMCA-Signed Certificates from the

Platform Services Controller Web Interface

You can replace all VMCA-signed certicates with new VMCA-signed certicates; this process is called

renewing certicates. You can renew selected certicates or all certicates in your environment from the

Platform Services Controller web interface.

Prerequisites

For certicate management, you have to supply the password of the administrator of the local domain

(administrator@vsphere.local by default). If you are renewing certicates for a vCenter Server system, you

also have to supply the vCenter Single Sign-On credentials for a user with administrator privileges on the

vCenter Server system.

Procedure

1 From a Web browser, connect to the Platform Services Controller by specifying the following URL:

https://psc_hostname_or_IP/psc

In an embedded deployment, the Platform Services Controller host name or IP address is the same as

the vCenter Server host name or IP address.

Chapter 3 vSphere Security Certificates

VMware, Inc. 77

2 Specify the user name and password for administrator@vsphere.local or another member of the vCenter

Single Sign-On Administrators group.

If you specied a dierent domain during installation, log in as administrator@mydomain.

3 Under Certicates, select  Management and specify the IP address or host name for the

Platform Services Controller and the user name and password of the administrator of the local domain

(administrator@vsphere.local by default), and click Submit.

4 Renew the machine SSL certicate for the local system.

a Click the Machine  tab.

b Select the certicate, click Renew, and answer Yes to the prompt.

5 (Optional) Renew the solution user certicates for the local system.

a Click the Solution User  tab.

b Select a certicate and click Renew to renew individual selected certicates, or click Renew All to

renew all solution user certicates.

c Answer Yes at the prompt.

6 If your environment includes an external Platform Services Controller, you can then renew the

certicates for each of the vCenter Server system.

a Click the Logout buon in the Certicate Management panel.

b When prompted, specify the IP address or FQDN of the vCenter Server system and user name and

password of a vCenter Server administrator who can authenticate to vCenter Single Sign-On.

c Renew the machine SSL certicate on the vCenter Server and, optionally, each solution user

certicate.

d If you have multiple vCenter Server systems in your environment, repeat the process for each

system.

What to do next

Restart services on the Platform Services Controller. You can either restart the Platform Services Controller,

or run the following commands from the command line:

Windows On Windows, the service-control command is located at

VCENTER_INSTALL_PATH\bin.

service-control --stop --all

service-control --start VMWareAfdService

service-control --start VMWareDirectoryService

service-control --start VMWareCertificateService

vCenter Server

Appliance

service-control --stop --all

service-control --start vmafdd

service-control --start vmdird

service-control --start vmcad

Make VMCA an Intermediate Certificate Authority from the

Platform Services Controller Web Interface

You can have the VMCA certicate signed by another CA so that VMCA becomes an intermediate CA

Going forward, all certicates that VMCA generates include the full chain.

You can perform this setup by using the vSphere Certicate Manager utility, by using CLIs, or from the

Platform Services Controller web interface.

vSphere Security

78 VMware, Inc.

Prerequisites

1 Generate the CSR.

2 Edit the certicate that you receive, and place the current VMCA root certicate at the boom.

“Generate Certicate Signing Requests with vSphere Certicate Manager (Intermediate CA),” on page 85

explains both steps.

Procedure

1 From a Web browser, connect to the Platform Services Controller by specifying the following URL:

https://psc_hostname_or_IP/psc

In an embedded deployment, the Platform Services Controller host name or IP address is the same as

the vCenter Server host name or IP address.

2 Specify the user name and password for administrator@vsphere.local or another member of the vCenter

Single Sign-On Administrators group.

If you specied a dierent domain during installation, log in as administrator@mydomain.

3 To replace the existing certicate with the chained certicate, follow these steps:

a Under Certicates, click  Authority and select the Root  tab.

b Click Replace . add the private key le and the certicate le (full chain) and click OK.

c In the Replace Root  dialog, click Browse and select the private key, click Browse again

and select the certicate, and click OK.

Going forward, VMCA signs all certicates that it issues with the new chained root certicate.

4 Renew the machine SSL certicate for the local system.

a Under Certicates, click  Management and click the Machine  tab.

b Select the certicate, click Renew, and answer Yes to the prompt.

VMCA replaces the machine SSL certicate with the certicate that is signed by the new CA.

5 (Optional) Renew the solution user certicates for the local system.

a Click the Solution User  tab.

b Select a certicate and click Renew to renew individual selected certicates, or click Renew All to

replace all certicates and answer Yes to the prompt.

VMCA replaces the solution user certicate or all solution user certicates with certicates that are

signed by the new CA.

6 If your environment includes an external Platform Services Controller, you can then renew the

certicates for each of the vCenter Server system.

a Click the Logout buon in the Certicate Management panel.

b When prompted, specify the IP address or FQDN of the vCenter Server system and user name and

password of a vCenter Server administrator who can authenticate to vCenter Single Sign-On.

c Renew the machine SSL certicate on the vCenter Server and, optionally, each solution user

certicate.

d If you have multiple vCenter Server systems in your environment, repeat the process for each

system.

Chapter 3 vSphere Security Certificates

VMware, Inc. 79

What to do next

Restart services on the Platform Services Controller. You can either restart the Platform Services Controller,

or run the following commands from the command line:

Windows On Windows, the service-control command is located at

VCENTER_INSTALL_PATH\bin.

service-control --stop --all

service-control --start VMWareAfdService

service-control --start VMWareDirectoryService

service-control --start VMWareCertificateService

vCenter Server

Appliance

service-control --stop --all

service-control --start vmafdd

service-control --start vmdird

service-control --start vmcad

Set up Your System to Use Custom Certificates from the Platform Services

Controller

You can use the Platform Services Controller to set up your environment to use custom certicates.

You can generate Certicate Signing Requests (CSRs) for each machine and for each solution user using the

Certicate Manager utility. When you submit the CSRs to your internal or third-party CA, the CA returns

signed certicates and the root certicate. You can upload both the root certicate and the signed certicates

from the Platform Services Controller UI.

Generate Certificate Signing Requests with vSphere Certificate Manager (Custom

Certificates)

You can use vSphere Certicate Manager to generate Certicate Signing Requests (CSRs) that you can then

use with your enterprise CA or send to an external certicate authority. You can use the certicates with the

dierent supported certicate replacement processes.

You can run the Certicate Manager tool from the command line as follows:

Windows C:\Program Files\VMware\vCenter Server\vmcad\certificate-manager.bat

Linux /usr/lib/vmware-vmca/bin/certificate-manager

Prerequisites

vSphere Certicate Manager prompts you for information. The prompts depend on your environment and

on the type of certicate you want to replace.

nFor any CSR generation, you are prompted for the password of the administrator@vsphere.local user, or

for the administrator of the vCenter Single Sign-On domain that you are connecting to.

nIf you are generating a CSR in an environment with an external Platform Services Controller, you are

prompted for the host name or IP address of the Platform Services Controller.

nTo generate a CSR for a machine SSL certicate, you are prompted for certicate properties, which are

stored in the certool.cfg le. For most elds, you can accept the default or provide site-specic values.

The FQDN of the machine is required.

Procedure

1 On each machine in your environment, start vSphere Certicate Manager and select option 1.

2 Supply the password and the Platform Services Controller IP address or host name if prompted.

vSphere Security

80 VMware, Inc.

3 Select option 1 to generate the CSR, answer the prompts and exit Certicate Manager.

As part of the process, you have to provide a directory. Certicate Manager places the certicate and

key les in the directory.

4 If you also want to replace all solution user certicates, restart Certicate Manager.

5 Select option 5.

6 Supply the password and the Platform Services Controller IP address or host name if prompted.

7 Select option 1 to generate the CSRs, answer the prompts and exit Certicate Manager.

As part of the process, you have to provide a directory. Certicate Manager places the certicate and

key les in the directory.

On each Platform Services Controller node, Certicate Manager generates one certicate and key pair.

On each vCenter Server node, Certicate Manager generates four certicate and key pairs.

What to do next

Perform certicate replacement.

Add a Trusted Root Certificate to the Certificate Store

If you want to use third-party certicates in your environment, you must add a trusted root certicate to the

certicate store.

Prerequisites

Obtain the custom root certicate from your third-party or in-house CA.

Procedure

1 From a Web browser, connect to the Platform Services Controller by specifying the following URL:

https://psc_hostname_or_IP/psc

In an embedded deployment, the Platform Services Controller host name or IP address is the same as

the vCenter Server host name or IP address.

2 Specify the user name and password for administrator@vsphere.local or another member of the vCenter

Single Sign-On Administrators group.

If you specied a dierent domain during installation, log in as administrator@mydomain.

3 Under Certicates, select  Management and specify the IP address or host name for the

Platform Services Controller and the user name and password of the administrator of the local domain

(administrator@vsphere.local by default), and click Submit.

4 Select Trusted Root , and click Add .

5 Click Browse and select the location of the certicate chain.

You can use a le of type CER, PEM, or CRT.

What to do next

Replace the Machine SSL certicates and, optionally, the Solution User certicates with certicates that are

signed by this CA.

Chapter 3 vSphere Security Certificates

VMware, Inc. 81

Add Custom Certificates from the Platform Services Controller

You can add custom Machine SSL certicates and custom solution user certicates to the certicate store

from the Platform Services Controller.

In most cases, replacing the machine SSL certicate for each component is sucient. The solution user

certicate remains behind a proxy.

Prerequisites

Generate certicate signing requests (CSRs) for each certicate that you want to replace. You can generate

the CSRs with the Certicate Manager utility. Place the certicate and private key in a location that the

Platform Services Controller can access.

Procedure

1 From a Web browser, connect to the Platform Services Controller by specifying the following URL:

https://psc_hostname_or_IP/psc

In an embedded deployment, the Platform Services Controller host name or IP address is the same as

the vCenter Server host name or IP address.

2 Specify the user name and password for administrator@vsphere.local or another member of the vCenter

Single Sign-On Administrators group.

If you specied a dierent domain during installation, log in as administrator@mydomain.

3 Under Certicates, select  Management and specify the IP address or host name for the

Platform Services Controller and the user name and password of the administrator of the local domain

(administrator@vsphere.local by default), and click Submit.

4 To replace a machine certicate follow these steps:

a Select the Machine  tab and click the certicate that you want to replace.

b Click Replace, and click Browse to replace the certicate chain, then click Browse to replace the

private key.

5 To replace the solution user certicates, follow these steps:

a Select the Solution User  tab and click the rst of the four certicates for a component,

for example, machine.

b Click Replace, and click Browse to replace the certicate chain, then click Browse to replace the

private key.

c Repeat the process for the other three certicates for the same component.

vSphere Security

82 VMware, Inc.

What to do next

Restart services on the Platform Services Controller. You can either restart the Platform Services Controller,

or run the following commands from the command line:

Windows On Windows, the service-control command is located at

VCENTER_INSTALL_PATH\bin.

service-control --stop --all

service-control --start VMWareAfdService

service-control --start VMWareDirectoryService

service-control --start VMWareCertificateService

vCenter Server

Appliance

service-control --stop --all

service-control --start vmafdd

service-control --start vmdird

service-control --start vmcad

Managing Certificates with the vSphere Certificate Manager Utility

The vSphere Certicate Manager utility allows you to perform most certicate management tasks

interactively from the command line. vSphere Certicate Manager prompts you for the task to perform, for

certicate locations and other information as needed, and then stops and starts services and replaces

certicates for you.

If you use vSphere Certicate Manager, you are not responsible for placing the certicates in VECS

(VMware Endpoint Certicate Store) and you are not responsible for starting and stopping services.

Before you run vSphere Certicate Manager, be sure you understand the replacement process and procure

the certicates that you want to use.

C vSphere Certicate Manager supports one level of revert. If you run vSphere Certicate Manager

twice and notice that you unintentionally corrupted your environment, the tool cannot revert the rst of the

two runs.

You can run the tool on the command line as follows:

Windows C:\Program Files\VMware\vCenter Server\vmcad\certificate-manager.bat

Linux /usr/lib/vmware-vmca/bin/certificate-manager

1Revert Last Performed Operation by Republishing Old Certicates on page 84

When you perform a certicate management operation by using vSphere Certicate Manager, the

current certicate state is stored in the BACKUP_STORE store in VECS before certicates are replaced.

You can revert the last performed operation and return to the previous state.

2Reset All Certicates on page 84

Use the Reset All Certificates option if you want to replace all existing vCenter certicates with

certicates that are signed by VMCA.

3Regenerate a New VMCA Root Certicate and Replace All Certicates on page 84

You can regenerate the VMCA root certicate, and replace the local machine SSL certicate, and the

local solution user certicates with VMCA-signed certicates. In multi-node deployments, run

vSphere Certicate Manager with this option on the Platform Services Controller and then run the

utility again on all other nodes and select

Replace Machine SSL certificate with VMCA Certificate and

Replace Solution user certificates with VMCA certificates.

Chapter 3 vSphere Security Certificates

VMware, Inc. 83

4Make VMCA an Intermediate Certicate Authority (Certicate Manager) on page 85

You can make VMCA an Intermediate CA by following the prompts from Certicate Manager utility.

After you complete the process, VMCA signs all new certicates with the full chain. If you want, you

can use Certicate Manager to replace all existing certicates with new VMCA-signed certicates.

5Replace All Certicates with Custom Certicate (Certicate Manager) on page 89

You can use the vSphere Certicate Manager utility to replace all certicates with custom certicates.

Before you start the process, you must send CSRs to your CA. You can use Certicate Manager to

generate the CSRs.

Revert Last Performed Operation by Republishing Old Certificates

When you perform a certicate management operation by using vSphere Certicate Manager, the current

certicate state is stored in the BACKUP_STORE store in VECS before certicates are replaced. You can

revert the last performed operation and return to the previous state.

N The revert operation restores what is currently in the BACKUP_STORE. If you run vSphere

Certicate Manager with two dierent options and you then aempt to revert, only the last operation is

reverted.

Reset All Certificates

Use the Reset All Certificates option if you want to replace all existing vCenter certicates with

certicates that are signed by VMCA.

When you use this option, you overwrite all custom certicates that are currently in VECS.

nOn a Platform Services Controller node, vSphere Certicate Manager can regenerate the root certicate

and replace the machine SSL certicate and the machine solution user certicate.

nOn a management node, vSphere Certicate Manager can replace the machine SSL certicate and all

solution user certicates.

nIn an embedded deployment, vSphere Certicate Manager can replace all certicates.

Which certicates are replaced depends on which options you select.

Regenerate a New VMCA Root Certificate and Replace All Certificates

You can regenerate the VMCA root certicate, and replace the local machine SSL certicate, and the local

solution user certicates with VMCA-signed certicates. In multi-node deployments, run vSphere

Certicate Manager with this option on the Platform Services Controller and then run the utility again on all

other nodes and select Replace Machine SSL certificate with VMCA Certificate and

Replace Solution user certificates with VMCA certificates.

When you run this command, vSphere Certicate Manager prompts you for the password and for certicate

information and stores all information, except for the password, in the certool.cfg le. After that, stopping

services, replacing all certicates, and restarting processes is automatic. You are prompted for the following

information:

nPassword for administrator@vsphere.local.

nTwo-leer country code

nCompany name

nOrganization name

nOrganization unit

nState

vSphere Security

84 VMware, Inc.

nLocality

nIP address (optional)

nEmail

nHost name, that is, the fully qualied domain name of the machine for which you want to replace the

certicate

nIP address of Platform Services Controller if you are running the command on a management node

Prerequisites

You must know the FQDN of the machine for which you want to generate a new VMCA-signed certicate.

All other properties default to the predened values. The IP address is optional.

What to do next

After replacing the root certicate in a multi-node deployment, you must restart services on all

vCenter Server with external Platform Services Controller nodes.

Make VMCA an Intermediate Certificate Authority (Certificate Manager)

You can make VMCA an Intermediate CA by following the prompts from Certicate Manager utility. After

you complete the process, VMCA signs all new certicates with the full chain. If you want, you can use

Certicate Manager to replace all existing certicates with new VMCA-signed certicates.

Generate Certificate Signing Requests with vSphere Certificate Manager

(Intermediate CA)

You can use vSphere Certicate Manager to generate Certicate Signing Requests (CSRs). Submit those

CSRs to your enterprise CA or to an external certicate authority for signing. You can use the signed

certicates with the dierent supported certicate replacement processes.

Prerequisites

vSphere Certicate Manager prompts you for information. The prompts depend on your environment and

on the type of certicate you want to replace.

nFor any CSR generation, you are prompted for the password of the administrator@vsphere.local user, or

for the administrator of the vCenter Single Sign-On domain that you are connecting to.

nIf you are generating a CSR in an environment with an external Platform Services Controller, you are

prompted for the host name or IP address of the Platform Services Controller.

nTo generate a CSR for a machine SSL certicate, you are prompted for certicate properties, which are

stored in the certool.cfg le. For most elds, you can accept the default or provide site-specic values.

The FQDN of the machine is required.

Procedure

1 Start vSphere Certicate Manager and select option 2.

2 Supply the password and the Platform Services Controller IP address or host name if prompted.

3 Select option 1 to generate the CSR and answer the prompts.

As part of the process, you have to provide a directory. Certicate Manager places the les

root_signing_cert.csr and root_signing_cert.key in the directory.

4 Request or generate a certicate and name the le root_signing_cert.cer.

Chapter 3 vSphere Security Certificates

VMware, Inc. 85

5 In a text editor, combine the certicates to have the initial VMCA root certicate at the top and the CA

root certicate at the boom.

-----BEGIN CERTIFICATE-----

VMCA Certificate

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

CA intermediate certificates

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

Root CA certificate

-----END CERTIFICATE-----

6 Save the le as root_signing_chain.cer.

What to do next

Replace the existing root certicate with the chained root certicate. See “Replace VMCA Root Certicate

with Custom Signing Certicate and Replace All Certicates,” on page 86.

Replace VMCA Root Certificate with Custom Signing Certificate and Replace All

Certificates

You can replace the VMCA root certicate with a CA-signed certicate that includes VMCA as an

intermediate certicate in the certicate chain. Going forward, all certicates that VMCA generates include

the full chain.

You run vSphere Certicate Manager on an embedded installation or on an external

Platform Services Controller to replace the VMCA root certicate with a custom signing certicate.

vSphere Certicate Manager prompts you for the following information:

Prerequisites

nGenerate the CSR.

nYou can use vSphere Certicate Manager to create the CSR. See “Generate Certicate Signing

Requests with vSphere Certicate Manager (Intermediate CA),” on page 85

nIf you prefer to create the CSR manually, the certicate that you send to be signed must meet the

following requirements:

nKey size: 2048 bits or more

nPEM format. VMware supports PKCS8 and PKCS1 (RSA keys). When keys are added to VECS,

they are converted to PKCS8

nx509 version 3

nFor root certicates CA extension must be set to true, and cert sign must be in the list of

requirements.

nMake sure that all nodes in your environment are time synchronized.

nNo explicit limit to the length of the certicate chain. VMCA uses the OpenSSL default, which

is ten certicates.

nVMCA does not support using certicates with wildcards or more than one DNS name.

nYou cannot create subsidiary CAs of VMCA.

nAfter you receive the certicate from your third-party or enterprise CA, combine it with the initial

VMCA root certicate to generate a full chain with the VMCA root certicate at the boom. See

“Generate Certicate Signing Requests with vSphere Certicate Manager (Intermediate CA),” on

page 85.

vSphere Security

86 VMware, Inc.

nGather the information you will need.

nPassword for administrator@vsphere.local.

nValid custom certicate for Root (.crt le).

nValid custom key for Root (.key le).

Procedure

1 Start vSphere Certicate Manager on an embedded installation or on an external

Platform Services Controller and select option 2.

2 Select option 2 to start certicate replacement and respond to the prompts.

a Specify the full path to the root certicate when prompted.

b If you are replacing certicates for the rst time, you are prompted for information to be used for

the machine SSL certicate.

This information includes the required FQDN of the machine and is stored in the certool.cfg le.

3 If you replace the root certicate in a multi-node deployment, you must restart services on all

vCenter Server.

4 In multi-node deployments, regenerate all certicates on each vCenter Server instances by using

options 3 (Replace Machine SSL certicate with VMCA Certicate) and 6 ( Replace Solution user

certicates with VMCA certicates).

When you replace the certicates, VMCA signs with the full chain.

What to do next

Depending on your environment, you might have to replace additional certicates explicitly.

nIf company policy requires that you replace all certicates, replace the vmdir root certicate. See

“Replace the VMware Directory Service Certicate,” on page 110

nIf you are upgrading from a vSphere 5.x environment, you might have to replace the vCenter Single

Sign-On certicate inside vmdir. See “Replace the VMware Directory Service Certicate in Mixed Mode

Environments,” on page 101

Replace Machine SSL Certificate with VMCA Certificate (Intermediate CA)

In a multi-node deployment that uses VMCA as an intermediate CA, you have to replace the machine SSL

certicate explicitly. First you replace the VMCA root certicate on the Platform Services Controller node,

and then you can replace the certicates on the vCenter Server nodes to have the certicates signed by the

full chain. You can also use this option to replace machine SSL certicates that are corrupt or about to expire.

When you replace the existing machine SSL certicate with a new VMCA-signed certicate, vSphere

Certicate Manager prompts you for information and enters all values, except for the password and the IP

address of the Platform Services Controller, into the certool.cfg le.

nPassword for administrator@vsphere.local.

nTwo-leer country code

nCompany name

nOrganization name

nOrganization unit

nState

nLocality

Chapter 3 vSphere Security Certificates

VMware, Inc. 87

nIP address (optional)

nEmail

nHost name, that is, the fully qualied domain name of the machine for which you want to replace the

certicate. If the host name does not match the FQDN, certicate replacement does not complete

correctly and your environment might end up in an unstable state.

nIP address of Platform Services Controller if you are running the command on a management node

Prerequisites

nRestart all vCenter Server nodes explicitly if you replaced the VMCA root certicate in a multi-node

deployment.

nYou must know the following information to run Certicate Manager with this option.

nPassword for administrator@vsphere.local.

nThe FQDN of the machine for which you want to generate a new VMCA-signed certicate. All

other properties default to the predened values but can be changed.

nHost name or IP address of the Platform Services Controller if you are running on a vCenter Server

system with an external Platform Services Controller.

Procedure

1 Start vSphere Certicate Manager and select option 3.

2 Respond to the prompts.

Certicate Manager stores the information in the certool.cfg le.

vSphere Certicate Manager replaces the machine SSL certicate.

Replace Solution User Certificates with VMCA Certificates (Intermediate CA)

In a multi-node that uses VMCA as an intermediate CA, you must replace the solution user certicates

explicitly. First you replace the VMCA root certicate on the Platform Services Controller node, and then

you can replace the certicates on the vCenter Server nodes to have the certicates signed by the full chain.

You can also use this option to replace solution user certicates that are corrupt or about to expire.

Prerequisites

nRestart all vCenter Server nodes explicitly if you replaced the VMCA root certicate in a multi-node

deployment.

nYou must know the following information to run Certicate Manager with this option.

nPassword for administrator@vsphere.local.

nHost name or IP address of the Platform Services Controller if you are running on a vCenter Server

system with an external Platform Services Controller.

Procedure

1 Start vSphere Certicate Manager and select option 6.

2 Respond to the prompts.

vSphere Certicate Manager replaces all solution user certicates.

vSphere Security

88 VMware, Inc.

Replace All Certificates with Custom Certificate (Certificate Manager)

You can use the vSphere Certicate Manager utility to replace all certicates with custom certicates. Before

you start the process, you must send CSRs to your CA. You can use Certicate Manager to generate the

CSRs.

One option is to only replace the machine SSL certicate, and to use the solution user certicates that are

provisioned by VMCA. Solution user certicates are used only for communication between vSphere

Components.

When you use custom certicates, you are responsible for provisioning each node that you add to your

environment with custom certicates. VMCA still provisions with VMCA-signed certicates, and you are

responsible for replacing those certicates. You can use the vSphere Certicate Manager utility or use CLIs

for manual certicate replacement. Certicates are stored in VECS.

Generate Certificate Signing Requests with vSphere Certificate Manager (Custom

Certificates)

You can use vSphere Certicate Manager to generate Certicate Signing Requests (CSRs) that you can then

use with your enterprise CA or send to an external certicate authority. You can use the certicates with the

dierent supported certicate replacement processes.

You can run the Certicate Manager tool from the command line as follows:

Windows C:\Program Files\VMware\vCenter Server\vmcad\certificate-manager.bat

Linux /usr/lib/vmware-vmca/bin/certificate-manager

Prerequisites

vSphere Certicate Manager prompts you for information. The prompts depend on your environment and

on the type of certicate you want to replace.

nFor any CSR generation, you are prompted for the password of the administrator@vsphere.local user, or

for the administrator of the vCenter Single Sign-On domain that you are connecting to.

nIf you are generating a CSR in an environment with an external Platform Services Controller, you are

prompted for the host name or IP address of the Platform Services Controller.

nTo generate a CSR for a machine SSL certicate, you are prompted for certicate properties, which are

stored in the certool.cfg le. For most elds, you can accept the default or provide site-specic values.

The FQDN of the machine is required.

Procedure

1 On each machine in your environment, start vSphere Certicate Manager and select option 1.

2 Supply the password and the Platform Services Controller IP address or host name if prompted.

3 Select option 1 to generate the CSR, answer the prompts and exit Certicate Manager.

As part of the process, you have to provide a directory. Certicate Manager places the certicate and

key les in the directory.

4 If you also want to replace all solution user certicates, restart Certicate Manager.

5 Select option 5.

6 Supply the password and the Platform Services Controller IP address or host name if prompted.

Chapter 3 vSphere Security Certificates

VMware, Inc. 89

7 Select option 1 to generate the CSRs, answer the prompts and exit Certicate Manager.

As part of the process, you have to provide a directory. Certicate Manager places the certicate and

key les in the directory.

On each Platform Services Controller node, Certicate Manager generates one certicate and key pair.

On each vCenter Server node, Certicate Manager generates four certicate and key pairs.

What to do next

Perform certicate replacement.

Replace Machine SSL Certificate with Custom Certificate

The machine SSL certicate is used by the reverse proxy service on every management node,

Platform Services Controller, and embedded deployment. Each machine must have a machine SSL certicate

for secure communication with other services. You can replace the certicate on each node with a custom

certicate.

Prerequisites

Before you start, you need a CSR for each machine in your environment. You can generate the CSR using

vSphere Certicate Manager or explicitly.

1 To generate the CSR using vSphere Certicate Manager, see “Generate Certicate Signing Requests

with vSphere Certicate Manager (Custom Certicates),” on page 89.

2 To generate the CSR explicitly, request a certicate for each machine from your third-party or enterprise

CA. The certicate must meet the following requirements:

nKey size: 2048 bits or more (PEM encoded)

nCRT format

nx509 version 3

nSubjectAltName must contain DNS Name=<machine_FQDN>

nContains the following Key Usages: Digital Signature, Non Repudiation, Key Encipherment

See also VMware Knowledge Base article 2112014, Obtaining vSphere certicates from a Microsoft

Certicate Authority.

Procedure

1 Start vSphere Certicate Manager and select option 1.

2 Select option 2 to start certicate replacement and respond to the prompts.

vSphere Certicate Manager prompts you for the following information:

nPassword for administrator@vsphere.local.

nValid Machine SSL custom certicate (.crt le).

nValid Machine SSL custom key (.key le).

nValid signing certicate for the custom machine SSL certicate (.crt le).

nIf you are running the command on a management node in a multi-node deployment, IP address of

the Platform Services Controller.

What to do next

Depending on your environment, you might have to replace additional certicates explicitly.

nIf company policy requires that you replace all certicates, replace the vmdir root certicate. See

“Replace the VMware Directory Service Certicate,” on page 110

vSphere Security

90 VMware, Inc.

nIf you are upgrading from a vSphere 5.x environment, you might have to replace the vCenter Single

Sign-On certicate inside vmdir. See “Replace the VMware Directory Service Certicate in Mixed Mode

Environments,” on page 101

Replace Solution User Certificates with Custom Certificates

When you select this option, vSphere Certicate Manager prompts you for replacement certicates for the

existing solution user certicates. In multi-node deployments, run vSphere Certicate Manager with this

option to replace the machine solution user certicate on the Platform Services Controller and the full set of

solution users on each management node.

Prerequisites

Before you start, you need a CSR for each machine in your environment. You can generate the CSR using

vSphere Certicate Manager or explicitly.

1 To generate the CSR using vSphere Certicate Manager, see “Generate Certicate Signing Requests

with vSphere Certicate Manager (Custom Certicates),” on page 89.

2 To generate the CSR explicitly, request a certicate for each solution user on each node from your third-

party or enterprise CA. The certicate must meet the following requirements:

nKey size: 2048 bits or more (PEM encoded)

nCRT format

nx509 version 3

nSubjectAltName must contain DNS Name=<machine_FQDN>

nEach solution user certicate must have a dierent Subject. Consider, for example, including the

solution user name (such as vpxd) or other unique identier.

nContains the following Key Usages: Digital Signature, Non Repudiation, Key Encipherment

See also VMware Knowledge Base article 2112014, Obtaining vSphere certicates from a Microsoft

Certicate Authority.

Procedure

1 Start vSphere Certicate Manager and select option 5.

2 Select option 2 to start certicate replacement and respond to the prompts.

vSphere Certicate Manager prompts you for the following information:

nPassword for administrator@vsphere.local.

nCerticate and key for machine solution user

nIf you run vSphere Certicate Manager on a Platform Services Controller node, you are prompted

for the certicate and key (vpxd.crt and vpxd.key) for the machine solution user.

nIf you run vSphere Certicate Manager on a management node or an embedded deployment, you

are prompted for the full set of certicates and keys (vpxd.crt and vpxd.key) for all solution users.

What to do next

Depending on your environment, you might have to replace additional certicates explicitly.

nIf company policy requires that you replace all certicates, replace the vmdir root certicate. See

“Replace the VMware Directory Service Certicate,” on page 110

nIf you are upgrading from a vSphere 5.x environment, you might have to replace the vCenter Single

Sign-On certicate inside vmdir. See “Replace the VMware Directory Service Certicate in Mixed Mode

Environments,” on page 101

Chapter 3 vSphere Security Certificates

VMware, Inc. 91

Manual Certificate Replacement

For some special cases, for example, if you want to replace only one type of solution user certicate, you

cannot use the vSphere Certicate Manager utility. In that case, you can use the CLIs included with your

installation for certicate replacement.

Understanding Starting and Stopping of Services

For certain parts of manual certicate replacement, you must stop all services and then start only the

services that manage the certicate infrastructure. If you stop services only when needed, you can minimize

downtime.

Follow these rules of thumb.

nDo not stop services to generate new public/private key pairs or new certicates.

nIf you are the only administrator, you do not have to stop services when you add a new root certicate.

The old root certicate remains available, and all services can still authenticate with that certicate. Stop

and immediately restart all services after you add the root certicate to avoid problems with your hosts.

nIf your environment includes multiple administrators, stop services before you add a new root

certicate and restart services after you add a new certicate.

nStop services right before you perform these tasks:

nDelete a machine SSL certicate or any solution user certicate in VECS.

nReplace a solution user certicate in vmdir (VMware Directory Service).

Replace Existing VMCA-Signed Certificates With New VMCA-Signed Certificates

If the VMCA root certicate expires in the near future, or if you want to replace it for other reasons, you can

generate a new root certicate and add it to the VMware Directory Service. You can then generate new

machine SSL certicates and solution user certicates using the new root certicate.

Use the vSphere Certicate Manager utility to replace certicates for most cases.

If you need ne-grained control, this scenario gives detailed step-by-step instructions for replacing the

complete set of certicates using CLI commands. You can instead replace only individual certicates using

the procedure in the corresponding task.

Prerequisites

Only administrator@vsphere.local or other users in the CAAdmins group can perform certicate

management tasks. See “Add Members to a vCenter Single Sign-On Group,” on page 57.

Procedure

1Generate a New VMCA-Signed Root Certicate on page 93

You generate new VMCA-signed certicates with the certool CLI and publish them to vmdir.

2Replace Machine SSL Certicates with VMCA-Signed Certicates on page 94

After you generate a new VMCA-signed root certicate, you can replace all machine SSL certicates in

your environment.

3Replace Solution User Certicates With New VMCA-Signed Certicates on page 97

After you replace the machine SSL certicates, you can replace all solution user certicates. Solution

user certicates must be valid, that is, not expired, but none of the other information in the certicate is

used by the certicate infrastructure.

vSphere Security

92 VMware, Inc.

4Replace the VMware Directory Service Certicate in Mixed Mode Environments on page 101

During upgrade, your environment might temporarily include both vCenter Single Sign-On version

5.5 and vCenter Single Sign-On version 6.0, you have to perform additional steps to replace the

VMware Directory Service SSL certicate if you replace the SSL certicate of the node on which the

vCenter Single Sign-On service is running.

Generate a New VMCA-Signed Root Certificate

You generate new VMCA-signed certicates with the certool CLI and publish them to vmdir.

In a multi-node deployment, you run root certicate generation commands on the

Platform Services Controller.

Procedure

1 Generate a new self-signed certicate and private key.

certool --genselfcacert --outprivkey <key_file_path> --outcert <cert_file_path> --config

<config_file>

2 Replace the existing root certicate with the new certicate.

certool --rootca --cert <cert_file_path> --privkey <key_file_path>

The command generates the certicate, adds it to vmdir, and adds it to VECS.

3 Stop all services and start the services that handle certicate creation, propagation, and storage.

The service names dier on Windows and the vCenter Server Appliance.

Windows service-control --stop --all

service-control --start VMWareAfdService

service-control --start VMWareDirectoryService

service-control --start VMWareCertificateService

vCenter Server

Appliance

service-control --stop --all

service-control --start vmafdd

service-control --start vmdird

service-control --start vmcad

4 (Optional) Publish the new root certicate to vmdir.

dir-cli trustedcert publish --cert newRoot.crt

When you run this command, all instances of vmdir are updated immediately. Otherwise, propagation

to all instances might take a while.

5 Restart all services.

service-control --start --all

Example: Generate a New VMCA-Signed Root Certificate

The following example shows the full set of steps for verifying the current root CA information, and

regenerating the root certicate.

1 (Optional) List the VMCA root certicate to make sure it is in the certicate store.

nOn a Platform Services Controller node or embedded installation:

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --getrootca

Chapter 3 vSphere Security Certificates

VMware, Inc. 93

nOn a management node (external installation):

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --getrootca --server=<psc-ip-

or-fqdn>

The output looks similar to this:

output:

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

cf:2d:ff:49:88:50:e5:af

...

2 (Optional) List the VECS TRUSTED_ROOTS store and compare the certicate serial number there with

the output from Step 1.

This command works on both Platform Services Controller and management nodes because VECS polls

vmdir.

"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry list --store TRUSTED_ROOTS --

text

In the simplest case with only one root certicate, the output looks like this:

Number of entries in store : 1

Alias : 960d43f31eb95211ba3a2487ac840645a02894bd

Entry type : Trusted Cert

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

cf:2d:ff:49:88:50:e5:af

3 Generate a new VMCA root certicate. The certicate is added to the TRUSTED_ROOTS store in VECS

and in vmdir (VMware Directory Service).

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --selfca --config="C:\Program

Files\VMware\vCenter Server\vmcad\certool.cfg"

On Windows, --config is optional because the command uses the default certool.cfg le.

Replace Machine SSL Certificates with VMCA-Signed Certificates

After you generate a new VMCA-signed root certicate, you can replace all machine SSL certicates in your

environment.

Each machine must have a machine SSL certicate for secure communication with other services. In a multi-

node deployment, you must run the Machine SSL certicate generation commands on each node. Use the --

server parameter to point to the Platform Services Controller from a vCenter Server with external

Platform Services Controller.

Prerequisites

Be prepared to stop all services and start the services that handle certicate propagation and storage.

vSphere Security

94 VMware, Inc.

Procedure

1 Make one copy of certool.cfg for each machine that needs a new certicate.

You can nd certool.cfg in the following locations:

Windows C:\Program Files\VMware\vCenter Server\vmcad

Linux /usr/lib/vmware-vmca/share/config/

2 Edit the custom conguration le for each machine to include that machine's FDQN.

Run NSLookup against the machine’s IP address to see the DNS listing of the name, and use that name for

the Hostname eld in the le.

3 Generate a public/private key le pair and a certicate for each le, passing in the conguration le that

you just customized.

For example:

certool --genkey --privkey=machine1.priv --pubkey=machine1.pub

certool --gencert --privkey=machine1.priv --cert machine1.crt --Name=Machine1_Cert --config

machine1.cfg

4 Stop all services and start the services that handle certicate creation, propagation, and storage.

The service names dier on Windows and the vCenter Server Appliance.

Windows service-control --stop --all

service-control --start VMWareAfdService

service-control --start VMWareDirectoryService

service-control --start VMWareCertificateService

vCenter Server

Appliance

service-control --stop --all

service-control --start vmafdd

service-control --start vmdird

service-control --start vmcad

5 Add the new certicate to VECS.

All machines need the new certicate in the local certicate store to communicate over SSL. You rst

delete the existing entry, then add the new entry.

vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CERT

vecs-cli entry create --store MACHINE_SSL_CERT --alias __MACHINE_CERT --cert machine1.cert

--key machine1.priv

6 Restart all services.

service-control --start --all

Example: Replacing Machine Certificates With VMCA-Signed Certificates

1 Create a conguration le for the SSL certicate and save it as ssl-config.cfg in the current directory.

Country = US

Name = vmca-<PSC-FQDN-example>

Organization = <my_company>

OrgUnit = <my_company Engineering>

State = <my_state>

Locality = <mytown>

Hostname = <FQDN>

Chapter 3 vSphere Security Certificates

VMware, Inc. 95

2 Generate a key pair for the machine SSL certicate. Run this command on each management node and

Platform Services Controller node; it does not require a --server option.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --genkey --privkey=ssl-key.priv --

pubkey=ssl-key.pub

The ssl-key.priv and ssl-key.pub les are created in the current directory.

3 Generate the new machine SSL certicate. This certicate is signed by VMCA. If you replaced the

VMCA root certicate with custom certicate, VMCA signs all certicates with the full chain.

nOn a Platform Services Controller node or embedded installation:

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-vmca-

ssl.crt --privkey=ssl-key.priv --config=ssl-config.cfg

nOn a vCenter Server (external installation):

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-vmca-

ssl.crt --privkey=ssl-key.priv --config=ssl-config.cfg --server=<psc-ip-or-fqdn>

The new-vmca-ssl.crt le is created in the current directory.

4 (Optional) List the content of VECS.

"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli store list

nOutput on Platform Services Controller:

MACHINE_SSL_CERT

TRUSTED_ROOTS

TRUSTED_ROOT_CRLS

machine

nOutput on vCenter Server:

output (on vCenter):

MACHINE_SSL_CERT

TRUSTED_ROOTS

TRUSTED_ROOT_CRLS

machine

vpxd

vpxd-extension

vsphere-webclient

sms

5 Replace the Machine SSL certicate in VECS with the new Machine SSL certicate. The --store and --

alias values have to exactly match with the default names.

nOn the Platform Services Controller, run the following command to update the Machine SSL

certicate in the MACHINE_SSL_CERT store.

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store

MACHINE_SSL_CERT --alias __MACHINE_CERT

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store

MACHINE_SSL_CERT --alias __MACHINE_CERT --cert new-vmca-ssl.crt --key ssl-key.priv

nOn each management node or embedded deployment, run the following command to update the

Machine SSL certicate in the MACHINE_SSL_CERT store. You must update the certicate for

each machine separately because each has a dierent FQDN.

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store

MACHINE_SSL_CERT --alias __MACHINE_CERT

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store

MACHINE_SSL_CERT --alias __MACHINE_CERT --cert new-vmca-ssl.crt --key ssl-key.priv

vSphere Security

96 VMware, Inc.

What to do next

You can also replace the certicates for your ESXi hosts. See “Certicate Management for ESXi Hosts,” on

page 160.

After replacing the root certicate in a multi-node deployment, you must restart services on all

vCenter Server with external Platform Services Controller nodes.

Replace Solution User Certificates With New VMCA-Signed Certificates

After you replace the machine SSL certicates, you can replace all solution user certicates. Solution user

certicates must be valid, that is, not expired, but none of the other information in the certicate is used by

the certicate infrastructure.

You replace the machine solution user certicate on each management node and on each

Platform Services Controller node. You replace the other solution user certicates only on each management

node. Use the --server parameter to point to the Platform Services Controller when you run commands on

a management node with an external Platform Services Controller.

N When you list solution user certicates in large deployments, the output of dir-cli list includes all

solution users from all nodes. Run vmafd-cli get-machine-id --server-name localhost to nd the local

machine ID for each host. Each solution user name includes the machine ID.

Prerequisites

Be prepared to stop all services and start the services that handle certicate propagation and storage.

Procedure

1 Make one copy of certool.cfg, remove the Name, IP address, DNS name, and email elds, and rename

the le, for example, to sol_usr.cfg.

You can name the certicates from the command line as part of generation. The other information is not

needed for solution users. If you leave the default information, the certicates that are generated are

potentially confusing.

2 Generate a public/private key le pair and a certicate for each solution user, passing in the

conguration le that you just customized.

For example:

certool --genkey --privkey=vpxd.priv --pubkey=vpxd.pub

certool --gencert --privkey=vpxd.priv --cert vpxd.crt --Name=VPXD_1 --config sol_usr.cfg

3 Find the name for each solution user.

dir-cli service list

You can use the unique ID that is returned when you replace the certicates. The input and output

might look as follows.

C:\Program Files\VMware\vCenter Server\vmafdd>dir-cli service list

Enter password for administrator@vsphere.local:

1. machine-1d364500-4b45-11e4-96c2-020011c98db3

2. vpxd-1d364500-4b45-11e4-96c2-020011c98db3

3. vpxd-extension-1d364500-4b45-11e4-96c2-020011c98db3

4. vsphere-webclient-1d364500-4b45-11e4-96c2-020011c98db3

When you list solution user certicates in multi-node deployments, the output of dir-cli list includes

all solution users from all nodes. Run vmafd-cli get-machine-id --server-name localhost to nd the

local machine ID for each host. Each solution user name includes the machine ID.

Chapter 3 vSphere Security Certificates

VMware, Inc. 97

4 Stop all services and start the services that handle certicate creation, propagation, and storage.

The service names dier on Windows and the vCenter Server Appliance.

Windows service-control --stop --all

service-control --start VMWareAfdService

service-control --start VMWareDirectoryService

service-control --start VMWareCertificateService

vCenter Server

Appliance

service-control --stop --all

service-control --start vmafdd

service-control --start vmdird

service-control --start vmcad

5 For each solution user, replace the existing certicate in vmdir and then in VECS.

The following example shows how to replace the certicates for the vpxd service.

dir-cli service update --name <vpxd-xxxx-xxx-7c7b769cd9f4> --cert ./vpxd.crt

vecs-cli entry delete --store vpxd --alias vpxd

vecs-cli entry create --store vpxd --alias vpxd --cert vpxd.crt --key vpxd.priv

N Solution users cannot authenticate to vCenter Single Sign-On if you do not replace the certicate

in vmdir.

6 Restart all services.

service-control --start --all

Example: Using VMCA-Signed Solution User Certificates

1 Generate a public/private key pair for each solution user. That includes a pair for the machine solution

user on each Platform Services Controller and each management node and a pair for each additional

solution user (vpxd, vpxd-extension, vsphere-webclient) on each management node.

a Generate a key pair for the machine solution user of an embedded deployment or for the machine

solution user of the Platform Services Controller.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --genkey --privkey=machine-

key.priv --pubkey=machine-key.pub

b (Optional) For deployments with an external Platform Services Controller, generate a key pair for

the machine solution user on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --genkey --privkey=machine-

key.priv --pubkey=machine-key.pub

c Generate a key pair for the vpxd solution user on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --genkey --privkey=vpxd-

key.priv --pubkey=vpxd-key.pub

d Generate a key pair for the vpxd-extension solution user on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --genkey --privkey=vpxd-

extension-key.priv --pubkey=vpxd-extension-key.pub

e Generate a key pair for the vsphere-webclient solution user on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --genkey --privkey=vsphere-

webclient-key.priv --pubkey=vsphere-webclient-key.pub

vSphere Security

98 VMware, Inc.

2 Generate solution user certicates that are signed by the new VMCA root certicate for the machine

solution user on each Platform Services Controller and each management node and for each additional

solution user (vpxd, vpxd-extension, vsphere-webclient) on each management node.

N The --Name parameter has to be unique. Including the name of the solution user store, for

example vpxd or vpxd-extension makes it easy to see which certicate maps to which solution user.

a Run the following command on the Platform Services Controller node to generate a solution user

certicate for the machine solution user on that node.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-

machine.crt --privkey=machine-key.priv --Name=machine

b Generate a certicate for the machine solution user on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-

machine.crt --privkey=machine-key.priv --Name=machine --server=<psc-ip-or-fqdn>

c Generate a certicate for the vpxd solution user on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-vpxd.crt

--privkey=vpxd-key.priv --Name=vpxd --server=<psc-ip-or-fqdn>

d Generate a certicate for the vpxd-extensions solution user on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-vpxd-

extension.crt --privkey=vpxd-extension-key.priv --Name=vpxd-extension --server=<psc-ip-

or-fqdn>

e Generate a certicate for the vsphere-webclient solution user on each management node by

running the following command.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-vsphere-

webclient.crt --privkey=vsphere-webclient-key.priv --Name=vsphere-webclient --

server=<psc-ip-or-fqdn>

3 Replace the solution user certicates in VECS with the new solution user certicates.

N The --store and --alias parameters have to exactly match the default names for services.

a On the Platform Services Controller node, run the following command to replace the machine

solution user certicate:

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store

machine --alias machine

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store

machine --alias machine --cert new-machine.crt --key machine-key.priv

b Replace the machine solution user certicate on each management node:

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store

machine --alias machine

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store

machine --alias machine --cert new-machine-vc.crt --key machine-vc-key.priv

c Replace the vpxd solution user certicate on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store vpxd --

alias vpxd

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store vpxd --

alias vpxd --cert new-vpxd.crt --key vpxd-key.priv

Chapter 3 vSphere Security Certificates

VMware, Inc. 99

d Replace the vpxd-extension solution user certicate on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store vpxd-

extension --alias vpxd-extension

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store vpxd-

extension --alias vpxd-extension --cert new-vpxd-extension.crt --key vpxd-extension-

key.priv

e Replace the vsphere-webclient solution user certicate on each management node.

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store

vsphere-webclient --alias vsphere-webclient

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store

vsphere-webclient --alias vsphere-webclient --cert new-vsphere-webclient.crt --key

vsphere-webclient-key.priv

4 Update VMware Directory Service (vmdir) with the new solution user certicates. You are prompted

for a vCenter Single Sign-On administrator password.

a Run dir-cli service list to get the unique service ID sux for each solution user. You can run

this command on a Platform Services Controller or a vCenter Server system.

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"dir-cli>dir-cli service list

output:

1. machine-29a45d00-60a7-11e4-96ff-00505689639a

2. machine-6fd7f140-60a9-11e4-9e28-005056895a69

3. vpxd-6fd7f140-60a9-11e4-9e28-005056895a69

4. vpxd-extension-6fd7f140-60a9-11e4-9e28-005056895a69

5. vsphere-webclient-6fd7f140-60a9-11e4-9e28-005056895a69

N When you list solution user certicates in large deployments, the output of dir-cli list

includes all solution users from all nodes. Run vmafd-cli get-machine-id --server-name

localhost to nd the local machine ID for each host. Each solution user name includes the machine

ID.

b Replace the machine certicate in vmdir on the Platform Services Controller. For example, if

machine-29a45d00-60a7-11e4-96-00505689639a is the machine solution user on the

Platform Services Controller, run this command:

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"dir-cli service update --name

machine-29a45d00-60a7-11e4-96ff-00505689639a --cert new-machine-1.crt

c Replace the machine certicate in vmdir on each management node. For example, if

machine-6fd7f140-60a9-11e4-9e28-005056895a69 is the machine solution user on the vCenter Server,

run this command:

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"dir-cli service update --name

machine-6fd7f140-60a9-11e4-9e28-005056895a69 --cert new-machine-2.crt

d Replace the vpxd solution user certicate in vmdir on each management node. For example, if

vpxd-6fd7f140-60a9-11e4-9e28-005056895a69 is the vpxd solution user ID, run this command:

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"dir-cli service update --name

vpxd-6fd7f140-60a9-11e4-9e28-005056895a69 --cert new-vpxd.crt

e Replace the vpxd-extension solution user certicate in vmdir on each management node. For

example, if vpxd-extension-6fd7f140-60a9-11e4-9e28-005056895a69 is the vpxd-extension solution

user ID, run this command:

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"dir-cli service update --name vpxd-

extension-6fd7f140-60a9-11e4-9e28-005056895a69 --cert new-vpxd-extension.crt

vSphere Security

100 VMware, Inc.

f Replace the vsphere-webclient solution user certicate on each management node. For example, if

vsphere-webclient-6fd7f140-60a9-11e4-9e28-005056895a69 is the vsphere-webclient solution user

ID, run this command:

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"dir-cli service update --name

vsphere-webclient-6fd7f140-60a9-11e4-9e28-005056895a69 --cert new-vsphere-webclient.crt

What to do next

Restart all services on each Platform Services Controller node and each management node.

Replace the VMware Directory Service Certificate in Mixed Mode Environments

During upgrade, your environment might temporarily include both vCenter Single Sign-On version 5.5 and

vCenter Single Sign-On version 6.0, you have to perform additional steps to replace the VMware Directory

Service SSL certicate if you replace the SSL certicate of the node on which the vCenter Single Sign-On

service is running.

The VMware Directory Service SSL certicate is used by vmdir to perform handshakes between

Platform Services Controller nodes that perform vCenter Single Sign-On replication

These steps are required only if:

nYour environment includes both vCenter Single Sign-On 5.5 and vCenter Single Sign-On 6.0 services.

nThe vCenter Single Sign-On services are set up to replicate vmdir data.

nYou plan to replace the default VMCA-signed certicates with custom certicates for the node on which

the vCenter Single Sign-On 6.0 service runs.

N In most other cases, upgrading the complete environment before restarting the services is best

practice. Teplacing the VMware Directory Service certicate is not usually recommended.

Procedure

1 On the node on which the vCenter Single Sign-On 6.0 service runs, replace the vmdird SSL certicate

and key.

See “Replace the VMware Directory Service Certicate,” on page 110.

2 On the node on which the vCenter Single Sign-On 5.5 service runs, set up the environment so the

vCenter Single Sign-On 6.0 service is known.

a Back up all les C:\ProgramData\VMware\CIS\cfg\vmdird.

b Make a copy of the vmdircert.pem le on the 6.0 node, and rename it to

<sso_node2.domain.com>.pem, where <sso_node2.domain.com> is the FQDN of the 6.0 node.

c Copy the renamed certicate to C:\ProgramData\VMware\CIS\cfg\vmdird to replace the existing

replication certicate.

3 Restart the VMware Directory Service on all machines where you replaced certicates.

You can restart the service from the vSphere Web Client or use the service-control command.

Chapter 3 vSphere Security Certificates

VMware, Inc. 101

Use VMCA as an Intermediate Certificate Authority

You can replace the VMCA root certicate with a third-party CA-signed certicate that includes VMCA in

the certicate chain. Going forward, all certicates that VMCA generates include the full chain. You can

replace existing certicates with newly generated certicates. This approach combines the security of third-

party CA-signed certicate with the convenience of automated certicate management.

Procedure

1Replace the Root Certicate (Intermediate CA) on page 102

The rst step in replacing the VMCA certicates with custom certicates is generating a CSR and

adding the certicate that is returned to VMCA as a root certicate.

2Replace Machine SSL Certicates (Intermediate CA) on page 104

After you have received the signed certicate from the CA and made it the VMCA root certicate, you

can replace all machine SSL certicates.

3Replace Solution User Certicates (Intermediate CA) on page 106

After you replace the machine SSL certicates, you can replace the solution user certicates.

4Replace the VMware Directory Service Certicate on page 110

If you decide to use a new VMCA root certicate, and you unpublish the VMCA root certicate that

was used when you provisioned your environment, you must replace the machine SSL certicates,

solution user certicates, and certicates for some internal services.

5Replace the VMware Directory Service Certicate in Mixed Mode Environments on page 111

During upgrade, your environment might temporarily include both vCenter Single Sign-On version

5.5 and vCenter Single Sign-On version 6.0, you have to perform additional steps to replace the

VMware Directory Service SSL certicate if you replace the SSL certicate of the node on which the

vCenter Single Sign-On service is running.

Replace the Root Certificate (Intermediate CA)

The rst step in replacing the VMCA certicates with custom certicates is generating a CSR and adding the

certicate that is returned to VMCA as a root certicate.

The certicate that you send to be signed must meet the following requirements:

nKey size: 2048 bits or more

nPEM format. VMware supports PKCS8 and PKCS1 (RSA keys). When keys are added to VECS, they are

converted to PKCS8

nx509 version 3

nFor root certicates CA extension must be set to true, and cert sign must be in the list of requirements.

nMake sure that all nodes in your environment are time synchronized.

nNo explicit limit to the length of the certicate chain. VMCA uses the OpenSSL default, which is ten

certicates.

nVMCA does not support using certicates with wildcards or more than one DNS name.

nYou cannot create subsidiary CAs of VMCA.

VMCA validates the following certicate aributes when you replace the root certicate:

nKey size 2048 bits or more

nKey Usage: Cert Sign

nBasic Constraint: Subject Type CA

vSphere Security

102 VMware, Inc.

Procedure

1 Generate a CSR and send it to your CA.

Follow your CA's instructions.

2 Prepare a certicate le that includes the signed VMCA certicate along with the full CA chain of your

third party CA or enterprise CA, and save the le, for example, as rootca1.crt.

You can accomplish this by copying all CA certicates in PEM format into a single le. You have to start

with the VMCA certicate root and end with the root CA PEM certicate. For example:

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

3 Stop all services and start the services that handle certicate creation, propagation, and storage.

The service names dier on Windows and the vCenter Server Appliance.

Windows service-control --stop --all

service-control --start VMWareAfdService

service-control --start VMWareDirectoryService

service-control --start VMWareCertificateService

vCenter Server

Appliance

service-control --stop --all

service-control --start vmafdd

service-control --start vmdird

service-control --start vmcad

4 Replace the existing VMCA root CA.

certool --rootca --cert=rootca1.crt --privkey=root1.key

When you run this command, it:

nAdds the new custom root certicate to the certicate location in the le system.

nAppends the custom root certicate to the TRUSTED_ROOTS store in VECS (after a delay).

nAdds the custom root certicate to vmdir (after a delay).

5 (Optional) To propagate the change to all instances of vmdir (VMware Directory Service), publish the

new root certicate to vmdir, supplying the full le path for each le.

For example:

dir-cli trustedcert publish --cert rootca1.crt

Replication between vmdir nodes happens every 30 seconds. You do not have to add the root certicate

to VECS explicitly because VECS polls vmdir for new root certicate les every 5 minutes.

6 (Optional) If necessary, you can force a refresh of VECS.

vecs-cli force-refresh

7 Restart all services.

service-control --start --all

Chapter 3 vSphere Security Certificates

VMware, Inc. 103

Example: Replacing the Root Certificate

Replace the VMCA root certicate with the custom CA root certicate using the certool command with the

--rootca option.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\certool" --rootca --cert=C:\custom-

certs\root.pem -–privkey=C:\custom-certs\root.key

When you run this command, it:

nAdds the new custom root certicate to the certicate location in the le system.

nAppends the custom root certicate to the TRUSTED_ROOTS store in VECS.

nAdds the custom root certicate to vmdir.

What to do next

You can remove the original VMCA root certicate from the certicate store if company policy requires it. If

you do, you have to refresh these internal certicates:

nReplace the vCenter Single Sign-On Signing certicate. See “Refresh the STS Root Certicate,” on

page 50.

nReplace the VMware Directory Service certicate. See “Replace the VMware Directory Service

Certicate,” on page 110.

Replace Machine SSL Certificates (Intermediate CA)

After you have received the signed certicate from the CA and made it the VMCA root certicate, you can

replace all machine SSL certicates.

These steps are essentially the same as the steps for replacing with a certicate that uses VMCA as the

certicate authority. However, in this case, VMCA signs all certicates with the full chain.

Each machine must have a machine SSL certicate for secure communication with other services. In a multi-

node deployment, you must run the Machine SSL certicate generation commands on each node. Use the --

server parameter to point to the Platform Services Controller from a vCenter Server with external

Platform Services Controller.

Prerequisites

For each machine SSL certicate, the SubjectAltName must contain DNS Name=<Machine FQDN>.

Procedure

1 Make one copy of certool.cfg for each machine that needs a new certicate.

You can nd certool.cfg in the following locations:

Windows C:\Program Files\VMware\vCenter Server\vmcad

Linux /usr/lib/vmware-vmca/share/config/

2 Edit the custom conguration le for each machine to include that machine's FDQN.

Run NSLookup against the machine’s IP address to see the DNS listing of the name, and use that name for

the Hostname eld in the le.

3 Generate a public/private key le pair and a certicate for each machine, passing in the conguration

le that you just customized.

For example:

certool --genkey --privkey=machine1.priv --pubkey=machine1.pub

certool --gencert --privkey=machine1.priv --cert machine42.crt --Name=Machine42_Cert --

config machine1.cfg

vSphere Security

104 VMware, Inc.

4 Stop all services and start the services that handle certicate creation, propagation, and storage.

The service names dier on Windows and the vCenter Server Appliance.

Windows service-control --stop --all

service-control --start VMWareAfdService

service-control --start VMWareDirectoryService

service-control --start VMWareCertificateService

vCenter Server

Appliance

service-control --stop --all

service-control --start vmafdd

service-control --start vmdird

service-control --start vmcad

5 Add the new certicate to VECS.

All machines need the new certicate in the local certicate store to communicate over SSL. You rst

delete the existing entry, then add the new entry.

vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CERT

vecs-cli entry create --store MACHINE_SSL_CERT --alias __MACHINE_CERT --cert machine1.cert

--key machine1.priv

6 Restart all services.

service-control --start --all

Example: Replacing Machine SSL Certificates (VMCA is Intermediate CA)

1 Create a conguration le for the SSL certicate and save it as ssl-config.cfg in the current directory.

Country = US

Name = vmca-<PSC-FQDN-example>

Organization = VMware

OrgUnit = VMware Engineering

State = California

Locality = Palo Alto

Hostname = <FQDN>

2 Generate a key pair for the machine SSL certicate. Run this command on each management node and

Platform Services Controller node; it does not require a --server option.

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --genkey --privkey=ssl-key.priv --

pubkey=ssl-key.pub

The ssl-key.priv and ssl-key.pub les are created in the current directory.

3 Generate the new machine SSL certicate. This certicate is signed by VMCA. If you replaced the

VMCA root certicate with custom certicate, VMCA signs all certicates with the full chain.

nOn a Platform Services Controller node or embedded installation:

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-vmca-

ssl.crt --privkey=ssl-key.priv --config=ssl-config.cfg

nOn a vCenter Server (external installation):

C:\>"C:\Program Files\VMware\vCenter Server\vmcad\"certool --gencert --cert=new-vmca-

ssl.crt --privkey=ssl-key.priv --config=ssl-config.cfg --server=<psc-ip-or-fqdn>

The new-vmca-ssl.crt le is created in the current directory.

Chapter 3 vSphere Security Certificates

VMware, Inc. 105

4 (Optional) List the content of VECS.

"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli store list

nOutput on Platform Services Controller:

MACHINE_SSL_CERT

TRUSTED_ROOTS

TRUSTED_ROOT_CRLS

machine

nOutput on vCenter Server:

output (on vCenter):

MACHINE_SSL_CERT

TRUSTED_ROOTS

TRUSTED_ROOT_CRLS

machine

vpxd

vpxd-extension

vsphere-webclient

sms

5 Replace the Machine SSL certicate in VECS with the new Machine SSL certicate. The --store and --

alias values have to exactly match with the default names.

nOn the Platform Services Controller, run the following command to update the Machine SSL

certicate in the MACHINE_SSL_CERT store.

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store

MACHINE_SSL_CERT --alias __MACHINE_CERT

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store

MACHINE_SSL_CERT --alias __MACHINE_CERT --cert new-vmca-ssl.crt --key ssl-key.priv

nOn each management node or embedded deployment, run the following command to update the

Machine SSL certicate in the MACHINE_SSL_CERT store. You must update the certicate for

each machine separately because each has a dierent FQDN.

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry delete --store

MACHINE_SSL_CERT --alias __MACHINE_CERT

C:\>"C:\Program Files\VMware\vCenter Server\vmafdd\"vecs-cli entry create --store

MACHINE_SSL_CERT --alias __MACHINE_CERT --cert new-vmca-ssl.crt --key ssl-key.priv

What to do next

You can also replace the certicates for your ESXi hosts. See “Certicate Management for ESXi Hosts,” on

page 160.

After replacing the root certicate in a multi-node deployment, you must restart services on all

vCenter Server with external Platform Services Controller nodes.

Replace Solution User Certificates (Intermediate CA)