6.0.3
Table Of Contents
- vSphere Security
- Contents
- About vSphere Security
- Updated Information
- Security in the vSphere Environment
- vSphere Authentication with vCenter Single Sign-On
- Understanding vCenter Single Sign-On
- How vCenter Single Sign-On Protects Your Environment
- vCenter Single Sign-On Components
- How vCenter Single Sign-On Affects Installation
- How vCenter Single Sign-On Affects Upgrades
- Using vCenter Single Sign-On with vSphere
- Groups in the vsphere.local Domain
- vCenter Server Password Requirements and Lockout Behavior
- Configuring vCenter Single Sign-On Identity Sources
- Identity Sources for vCenter Server with vCenter Single Sign-On
- Set the Default Domain for vCenter Single Sign-On
- Add a vCenter Single Sign-On Identity Source
- Edit a vCenter Single Sign-On Identity Source
- Remove a vCenter Single Sign-On Identity Source
- Use vCenter Single Sign-On with Windows Session Authentication
- vCenter Server Two-Factor Authentication
- Using vCenter Single Sign-On as the Identity Provider for Another Service Provider
- Managing the Security Token Service (STS)
- Managing vCenter Single Sign-On Policies
- Managing vCenter Single Sign-On Users and Groups
- Add vCenter Single Sign-On Users
- Disable and Enable vCenter Single Sign-On Users
- Delete a vCenter Single Sign-On User
- Edit a vCenter Single Sign-On User
- Add a vCenter Single Sign-On Group
- Add Members to a vCenter Single Sign-On Group
- Remove Members from a vCenter Single Sign-On Group
- Delete vCenter Single Sign-On Solution Users
- Change Your vCenter Single Sign-On Password
- vCenter Single Sign-On Security Best Practices
- Troubleshooting vCenter Single Sign-On
- Understanding vCenter Single Sign-On
- vSphere Security Certificates
- Certificate Management Overview
- Managing Certificates with the Platform Services Controller Web Interface
- Explore Certificate Stores from the Platform Services Controller Web Interface
- Replace Certificates with New VMCA-Signed Certificates from the Platform Services Controller Web Interface
- Make VMCA an Intermediate Certificate Authority from the Platform Services Controller Web Interface
- Set up Your System to Use Custom Certificates from the Platform Services Controller
- Managing Certificates with the vSphere Certificate Manager Utility
- Revert Last Performed Operation by Republishing Old Certificates
- Reset All Certificates
- Regenerate a New VMCA Root Certificate and Replace All Certificates
- Make VMCA an Intermediate Certificate Authority (Certificate Manager)
- Generate Certificate Signing Requests with vSphere Certificate Manager (Intermediate CA)
- Replace VMCA Root Certificate with Custom Signing Certificate and Replace All Certificates
- Replace Machine SSL Certificate with VMCA Certificate (Intermediate CA)
- Replace Solution User Certificates with VMCA Certificates (Intermediate CA)
- Replace All Certificates with Custom Certificate (Certificate Manager)
- Manual Certificate Replacement
- Managing Certificates and Services with CLI Commands
- View vCenter Certificates with the vSphere Web Client
- Set the Threshold for vCenter Certificate Expiration Warnings
- vSphere Permissions and User Management Tasks
- Understanding Authorization in vSphere
- Understanding the vCenter Server Permission Model
- Hierarchical Inheritance of Permissions
- Multiple Permission Settings
- Managing Permissions for vCenter Components
- Global Permissions
- Using Roles to Assign Privileges
- Best Practices for Roles and Permissions
- Required Privileges for Common Tasks
- Securing ESXi Hosts
- Use Scripts to Manage Host Configuration Settings
- Configure ESXi Hosts with Host Profiles
- General ESXi Security Recommendations
- Certificate Management for ESXi Hosts
- Host Upgrades and Certificates
- ESXi Certificate Default Settings
- View Certificate Expiration Information for Multiple ESXi Hosts
- View Certificate Details for a Single ESXi Host
- Renew or Refresh ESXi Certificates
- Change Certificate Default Settings
- Understanding Certificate Mode Switches
- Change the Certificate Mode
- Replacing ESXi SSL Certificates and Keys
- Use Custom Certificates with Auto Deploy
- Restore ESXi Certificate and Key Files
- Customizing Hosts with the Security Profile
- ESXi Firewall Configuration
- Customizing ESXi Services from the Security Profile
- Enable or Disable a Service in the Security Profile
- Lockdown Mode
- Check the Acceptance Levels of Hosts and VIBs
- Assigning Permissions for ESXi
- Using Active Directory to Manage ESXi Users
- Using vSphere Authentication Proxy
- Configuring Smart Card Authentication for ESXi
- ESXi SSH Keys
- Using the ESXi Shell
- Modifying ESXi Web Proxy Settings
- vSphere Auto Deploy Security Considerations
- Managing ESXi Log Files
- Securing vCenter Server Systems
- vCenter Server Security Best Practices
- Verify Thumbprints for Legacy ESXi Hosts
- Verify that SSL Certificate Validation Over Network File Copy Is Enabled
- vCenter Server TCP and UDP Ports
- Control CIM-Based Hardware Monitoring Tool Access
- Securing Virtual Machines
- Limit Informational Messages from Virtual Machines to VMX Files
- Prevent Virtual Disk Shrinking
- Virtual Machine Security Best Practices
- General Virtual Machine Protection
- Use Templates to Deploy Virtual Machines
- Minimize Use of Virtual Machine Console
- Prevent Virtual Machines from Taking Over Resources
- Disable Unnecessary Functions Inside Virtual Machines
- Remove Unnecessary Hardware Devices
- Disable Unused Display Features
- Disable Unexposed Features
- Disable HGFS File Transfers
- Disable Copy and Paste Operations Between Guest Operating System and Remote Console
- Limiting Exposure of Sensitive Data Copied to the Clipboard
- Restrict Users from Running Commands Within a Virtual Machine
- Prevent a Virtual Machine User or Process from Disconnecting Devices
- Modify Guest Operating System Variable Memory Limit
- Prevent Guest Operating System Processes from Sending Configuration Messages to the Host
- Avoid Using Independent Nonpersistent Disks
- Securing vSphere Networking
- Introduction to vSphere Network Security
- Securing the Network with Firewalls
- Secure the Physical Switch
- Securing Standard Switch Ports With Security Policies
- Securing vSphere Standard Switches
- Secure vSphere Distributed Switches and Distributed Port Groups
- Securing Virtual Machines with VLANs
- Creating a Network DMZ on a Single ESXi Host
- Creating Multiple Networks Within a Single ESXi Host
- Internet Protocol Security
- Ensure Proper SNMP Configuration
- Use Virtual Switches with the vSphere Network Appliance API Only If Required
- vSphere Networking Security Best Practices
- Best Practices Involving Multiple vSphere Components
- Synchronizing Clocks on the vSphere Network
- Storage Security Best Practices
- Verify That Sending Host Performance Data to Guests is Disabled
- Setting Timeouts for the ESXi Shell and vSphere Web Client
- Defined Privileges
- Alarms Privileges
- Auto Deploy and Image Profile Privileges
- Certificates Privileges
- Content Library Privileges
- Datacenter Privileges
- Datastore Privileges
- Datastore Cluster Privileges
- Distributed Switch Privileges
- ESX Agent Manager Privileges
- Extension Privileges
- Folder Privileges
- Global Privileges
- Host CIM Privileges
- Host Configuration Privileges
- Host Inventory
- Host Local Operations Privileges
- Host vSphere Replication Privileges
- Host Profile Privileges
- Inventory Service Provider Privileges
- Inventory Service Tagging Privileges
- Network Privileges
- Performance Privileges
- Permissions Privileges
- Profile-driven Storage Privileges
- Resource Privileges
- Scheduled Task Privileges
- Sessions Privileges
- Storage Views Privileges
- Tasks Privileges
- Transfer Service Privileges
- VRM Policy Privileges
- Virtual Machine Configuration Privileges
- Virtual Machine Guest Operations Privileges
- Virtual Machine Interaction Privileges
- Virtual Machine Inventory Privileges
- Virtual Machine Provisioning Privileges
- Virtual Machine Service Configuration Privileges
- Virtual Machine Snapshot Management Privileges
- Virtual Machine vSphere Replication Privileges
- dvPort Group Privileges
- vApp Privileges
- vServices Privileges
- Index
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.
n
Active 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.
n
Active 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.
n
OpenLDAP versions 2.4 and later. vCenter Single Sign-On supports multiple OpenLDAP identity
sources. Shown as OpenLDAP in the vSphere Web Client.
n
Local 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 dierent
machine than the vCenter Server system. Using local operating system users might make sense in an
embedded deployment but is not recommended.
n
vCenter 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.
n
Users who are in the default domain can log in with their user name and password.
n
Users 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.
n
Including a domain name prex, for example, MYDOMAIN\user1
vSphere Security
30 VMware, Inc.