Configuring Security for a Managed VMware Environment in VMM

Applies To: Virtual Machine Manager 2008, Virtual Machine Manager 2008 R2, Virtual Machine Manager 2008 R2 SP1

This topic explains the security decisions you need to make before taking a VMware Infrastructure 3 (VI3) environment under management by System Center Virtual Machine Manager (VMM), and it also explains how to configure security in VMM for the VirtualCenter server and the ESX Server hosts. VMM manages a VMware environment by using a combination of the VirtualCenter WebServices API, for management and SFTP, and HTTPS, for file transfer operations.

Preparing to Manage a VMware Environment

Before you integrate your VMware environment with VMM, you need to decide how to handle the following security issues:

• Do you want to manage your VMware environment in secure mode, requiring authentication of each ESX Server host on all protocols used for communication?

• What account will VMM use for communications with VirtualCenter?

• For file transfers between hosts running non-embedded ESX Server (VMware® ESX Server 3.5, VMware® ESX Server 3.0.2) and Windows Server–based computers, will VMM use the default root credentials or a lower-privilege virtual machine delegate in ESX Server?

Decide Whether to Manage Your VMware Environment in Secure Mode

Before adding the VirtualCenter server to VMM, decide whether you want to manage the VMware environment in secure mode in VMM. When you add a VirtualCenter server to VMM, VMM turns on secure mode by default. If your environment does not require that level of authentication, you can turn off secure mode.

• Secure mode on—When you manage a VMware environment in secure mode, VMM authenticates each ESX Server host on all protocols used for communication. In secure mode, Secure Sockets Layer (SSL) over HTTPS (for embedded ESX Server) requires certificate authentication, and SFTP over Secure Shell (SSH) (for non-embedded ESX Server) requires host public key authentication. VMM retrieves and verifies both.

  If you configure all ESX Server hosts to use certification authority (CA)-signed certificates, the trust relationship of SSL channels can be established seamlessly. However, for non-embedded versions of ESX Server, if you use the self-signed certificates that VMware creates on ESX Server hosts during installation, you must verify the certificate when you configure security for the ESX Server in VMM. If you are managing a large number of embedded ESX Server hosts, you might find it more convenient to copy the certificates manually from each host and use a script to add them to the Trusted People certificate store on the VMM host. For instructions, see How to Automate Certificate Registration for ESX Server Hosts, later in this topic.

  For non-embedded versions of ESX Server, you also will need to add the SSH public keys to the VMM database. For this task also, you can either validate the public key when you configure security for individual hosts in VMM or use a script to update the VMM database with public keys for all of your non-embedded ESX Server hosts. For instructions, see How to Automate Public Key Entry for Non-Embedded ESX Server Hosts, later in this topic.

• Secure mode off—For environments that do not require the use of certificate authentication or RSA public key validation between VMM and ESX Server hosts during VirtualCenter operations, you can turn secure mode off.

Create a Dedicated Account for Communications with VirtualCenter

For communications with the VirtualCenter server, VMM requires an account that has Administrator rights at the Host and Cluster level in VirtualCenter. You can use a local account on the computer that has VirtualCenter installed or an Active Directory account. As a security best practice, create a dedicated service account that is not used by any other user or process.

Decide What Credentials to Use for File Transfer Operations

Next you need to decide which account to use for file transfer operations between hosts running non-embedded versions of ESX Server and Windows Server–based computers. This type of file transfer is required for operations such as a creating a virtual machine with a virtual hard disk stored on a VMM library server or storing a VMware virtual machine in the VMM library.

To perform this type of file transfer, VMM accesses ESX Server hosts directly. For non-embedded versions of ESX Server, VMM must have the credentials of the virtual machine delegate in ESX Server to gain the needed access to virtual machine files on the host. By default, ESX Server uses root credentials on the host for the delegate. If you don’t want to use root credentials, you can configure a lower-privilege account as the virtual machine delegate.

Regardless of your choice, you must perform additional configuration to give VMM the needed access:

• If ESX Server is using the default root credentials as the virtual machine delegate, you must enable SSH root login on each ESX Server host. For instructions, refer to guidelines for SSH security.

• To avoid enabling SSH remote logon to the highly privileged root, configure a virtual machine delegate account for each ESX Server host. To perform file-level actions on the ESX Server host, the account must meet the following requirements:

  • The account must be a member of the Administrator role in ESX Server.

  • You must use the same delegate user (by default, vimuser) on all ESX Server 3i hosts that use the NFS datastore.

  For more information about configuring virtual machine delegates, refer to VMware Documentation (https://go.microsoft.com/fwlink/?LinkId=163914).

  Warning

  After you configure virtual machine delegate credentials in VirtualCenter, you must restart the ESX Server host. That can cause loss of state for any running virtual machines. To avoid this, you should shut down or migrate any running virtual machines before you change the credentials. For a procedure, see How to Change Virtual Machine Delegate Credentials for a Managed Host, later in this topic.

VMM uses a different file transfer protocol for embedded versions of ESX Server (VMware® ESX Server 3i and later) than for non-embedded versions (VMware® ESX Server 3.5, VMware® ESX Server 3.0.2). Similarly to Windows Server Core, for greater security on the host computer, embedded versions of ESX Server install minimal code and no local console.

File transfers to ESX Server hosts use the following protocols:

• Embedded ESX Server—VMM uses HTTPS over default port 443 for file transfers. In secure mode, encryption using Secure Sockets Layer (SSL) requires certificate authentication.

• Non-embedded ESX Server—VMM uses SFTP over default port 22. In secure mode, encryption using Secure Shell (SSH) requires RSA public key authentication.

Follow Security Best Practices for Accounts and Authentication

When you add your VirtualCenter server to VMM and configure security for the ESX Server hosts, follow security best practices for accounts and authentication:

• Use Active Directory Domain Services (AD DS) to maintain all administrative accounts in a multi-platform environment—By using AD DS uniformly, you can enable a single administrator to manage all accounts and apply the same account policies (password strengths, expiration, classification, and so forth) throughout all of the environments. In addition, Active Directory’s implementation of the Kerberos protocol can provide authentication services for all accounts in each domain, allowing users to prove their identity to one another in a secure manner when communicating.

• Verify self-signed certificates and RSA public keys before accepting them in VMM—When you configure security settings for a managed ESX Server host in secure mode, VMM retrieves the self-signed certificate that VMware created when ESX Server was installed. For non-embedded versions of ESX Server, VMM also retrieves an RSA public key from the host computer. When you configure security for the host in VMM, always verify the certificate and public key on the host computer before you update the security settings in VMM.

• Optionally, use CA-signed certificates instead of self-signed certificates—For greater security and ease of management, use certificates from a trusted CA instead of self-signed certificates for authentication of the VirtualCenter server and your ESX Server hosts. CA-signed certificates do not require verification in VMM.

Integrating Your VMware Environment with VMM

After making the security decisions described in the previous sections, you are ready to add your VirtualCenter server to VMM and then configure security for the ESX Server hosts. If you plan to allow virtual machine self-service, you also will need to enable users to download the VMware ActiveX control that they must install so that they can open the VMM Self-Service Portal.

Add the VirtualCenter Server to VMM

VMM performs supported management tasks in a VMware environment by communicating with VirtualCenter. For these communications, VMM uses the WebServices API on default port 443. Encryption is performed through HTTPS using SSL.

While adding the VirtualCenter server, you configure all of these options, specifying the following:

• The TCP/IP port to use for connections to the VirtualCenter server (default port 443).

• The account credentials to use for connections to the VirtualCenter server.

  You can use a local account or an Active Directory domain account as long as the account has administrative rights in VirtualCenter at the Host and Cluster level. The account does not need to be a local administrator on the operating system. You should use a dedicated account that is not used by any other user or process.

• If you are using a self-signed certificate for the VirtualCenter server, you must import the certificate to the Trusted People certificate store on the VMM server to verify the computer’s identity. That is not required if you use a CA-signed certificate.

  Note

  This operation requires an account that is a member of the local Administrators group on the VMM computer. If the VMM service is running under a domain account rather than Local System, the operation must be run under that domain account.

For more information, see How to Add a VMware VirtualCenter Server (https://go.microsoft.com/fwlink/?LinkID=128560).

Enable Full Management of ESX Server Hosts

When you add a VMware VirtualCenter server to VMM, VMM discovers the ESX Server hosts and adds them to VMM with OK (Limited) status. OK (Limited) status indicates that VMM does not have the information required to perform file transfers on the hosts. While a host has OK (Limited) status, the VMM administrator can perform a limited set of management tasks that do not require file transfers.

To change a host’s status to OK and enable full management in VMM, you must provide VMM with the credentials for the virtual machine delegate on the host (either root or the lower-privileged account that you configured earlier). Additionally, if secure mode is enabled, VMM must be able to identify the host by its SSL certificate and, for non-embedded versions of ESX Server, by the host’s SSH public key.

To provide the needed information, update the host’s properties in VMM. For more information, see How to Set Credentials for Communicating with a Host (https://go.microsoft.com/fwlink/?LinkID=162973).

If you are managing multiple ESX Server hosts, you can save time by scripting certificate registration on the VMM server and the addition of public keys to the VMM database. For procedures, see How to Automate Certificate Registration for ESX Server Hosts (for certificate registration) and How to Automate Public Key Entry for Non-Embedded ESX Server Hosts (for adding public keys to the VMM database), later in this topic.

Enable Access to VMware Virtual Machines Through the VMM Self-Service Portal

If you plan to allow users to manage VMware virtual machines through the VMM Self-Service Portal, you must enable the users to download and install a VMware ActiveX control. This control must be downloaded through a secure SSL channel. VMM connects to the VMware host by using SSL. However, to ensure that users can download and install the ActiveX control, you must enable SSL on the VMware host computers. Alternatively, you can install the Virtual Infrastructure client on the client machine, which will also install the ActiveX control, thereby eliminating the need to download the ActiveX control from the host.

Optional Configuration Tasks

The following sections provide procedures for automating certificate and public key registration and for changing virtual machine delegate credentials on your ESX Server hosts.

How to Automate Certificate Registration for ESX Server Hosts

The following procedure provides a sample script to automate certificate registration on the VMM server for multiple ESX Server hosts. To register the certificates, you must add them to the Trusted People local certificate store.

To register self-signed certificates on the VMM server for ESX Server hosts

1. Manually copy the self-signed certificate from each ESX Server host.

   To retrieve a certificate:

   1. Log on to the service console as the root user.

   2. Change directories to /etc/vmware/hostd/

   3. To identify the certificate file, use a text editor to open the config.xml file and find the following XML segment:

      <ssl>
      <!-- The server private key file -->
      <privateKey>/etc/vmware/ssl/rui.key</privateKey>
      <!-- The server side certificate file -->
      <certificate>/etc/vmware/ssl/rui.crt</certificate>
      </ssl>
      

      The sample code shows the default certificate file, /etc/vmware/ssl/rui.crt.

   4. Copy the certificate file.

2. On the VMM server, load the certificates to the Trusted People store. The following command adds the certificate for host1 to the Trusted People store:

   >certutil -addstore -enterprise TRUSTEDPEOPLE c:\temp\<host1>\cert.cer
   

   Note

   This operation requires an account that is a member of the local Administrators group on the VMM computer. If the VMM service is running under a domain account rather than Local System, the operation must be run under that domain account.

How to Automate Public Key Entry for Non-Embedded ESX Server Hosts

The following procedure provides a sample script to automate public key entry in VMM for hosts running non-embedded versions of ESX Server (ESX Server 3.5 and ESX Server 3.0.2).

To add public keys to VMM for non-embedded ESX Server hosts

1. Manually collect the public key from each host that is running ESX Server 3.5 or ESX Server 3.0.2.

2. Load the SSH public keys to the VMM database. The following Windows PowerShell – VMM script adds the public key file for host1 to the VMM database:

   >$c = get-VMMserver localhost 
   >$vmhost = get-VMHost <host1> 
   >$vmhost | associate-vmhost –SshPublicKeyFile C:\<host1>\ssh_host_rsa_key.pub
   

How to Change Virtual Machine Delegate Credentials for a Managed Host

If you decide to change the virtual machine delegate for your ESX Server hosts from the default root credentials to a lower-privilege account after adding the VirtualCenter server to VMM, use the following procedure to safeguard virtual machine state while you make the change. For more information about your options, see Decide What Credentials to Use for File Transfer Operations, earlier in this topic.

To change virtual machine delegate credentials for ESX Server hosts

1. Shut down or migrate any running virtual machines on the ESX Server hosts.

2. In VirtualCenter, reset virtual machine delegate credentials for each ESX Server host.

   The account must be a member of the Administrator role in ESX Server. For ease of management, you might want to use the same virtual machine delegate on all ESX Server hosts. For information about configuring virtual machine delegates, see your ESX Server documentation.

3. Restart the ESX Server hosts.

4. In VMM, update the credentials for each ESX Server host with the account name and passport for the new Virtual Machine Delegate account. To update a host’s credentials, in Hosts view of the VMM Administrator Console, right-click the host and then click Configure Security.

See Also

Concepts

Hardening Virtual Machine Hosts Managed by VMM

Other Resources

Managing a VMware Infrastructure in VMM