Chapter 13 Authentication and User Management

7Enter the name of a user and group.

Use the format DOMAIN\name, where DOMAIN is the name of the Active Directory domain and name is the user name or group name.

8(Optional) If the name you entered is a group (not a single user), select the Name refers to a group of users check box.

9Enter the assigned role name for the user or group (usually Admin).

The role name is case-sensitive. If this is a system role, you must use the nonlocalized role name. For example, for the Administrator role, enter Admin. For the Read-only role, enter ReadOnly.

10 Select the Propagate permission check box and click OK.

What to do next

1Attach the profile to the hosts as described in “Attach Entities from the Host,” on page 224.

2Apply the profile to the hosts as described in “Apply a Profile from the Host,” on page 225.

Encryption and Security Certificates for ESX

ESX supports SSL v3 and TLS v1, generally referred to here as SSL. If SSL is enabled, data is private, protected, and cannot be modified in transit without detection.

All network traffic is encrypted as long as the following conditions are true:

nYou did not change the Web proxy service to allow unencrypted traffic for the port.

nYour service console firewall is configured for medium or high security.

Host certificate checking is enabled by default and SSL certificates are used to encrypt network traffic. However, ESX uses automatically generated certificates that are created as part of the installation process and stored on the host. These certificates are unique and make it possible to begin using the server, but they are not verifiable and are not signed by a trusted-well-known certificate authority (CA). These default certificates are vulnerable to possible man-in-the-middle attacks.

To receive the full benefit of certificate checking, particularly if you intend to use encrypted remote connections externally, install new certificates that are signed by a valid internal certificate authority or purchase a certificate from a trusted security authority.

NOTE If the self-signed certificate is used, clients receive a warning about the certificate. To address this issue, install a certificate that is signed by a recognized certificate authority. If CA-signed certificates are not installed, all communication between vCenter Server and vSphere Clients is encrypted using a self-signed certificate.

These certificates do not provide the authentication security you might need in a production environment.

The default location for your certificate is /etc/vmware/ssl/ on the ESX host. The certificate consists of two files: the certificate itself (rui.crt) and the private-key file (rui.key).

Enable Certificate Checking and Verify Host Thumbprints

To prevent man-in-the-middle attacks and to fully use the security that certificates provide, certificate checking is enabled by default. You can verify that certificate checking is enabled in the vSphere Client.

NOTE vCenter Server certificates are preserved across upgrades.

Procedure

1 Log in to a vCenter Server system using the vSphere Client.

2Select Administration > vCenter Server Settings.

ESX Configuration Guide

3Click SSL Settings in the left pane and verify that Check host certificates is selected.

4If there are hosts that require manual validation, compare the thumbprints listed for the hosts to the thumbprints in the host console.

To obtain the host thumbprint for ESX, run the following command. openssl x509 -in /etc/vmware/ssl/rui.crt -fingerprint -sha1 -noout

5If the thumbprint matches, select the Verify check box next to the host. Hosts that are not selected will be disconnected after you click OK.

6Click OK.

Generate New Certificates for the ESX Host

The ESX host generates certificates the first time the system is started. Under certain circumstances, you might be required to force the host to generate new certificates. You typically generate new certificates only if you change the host name or accidentally delete the certificate.

Each time you restart the vmware-hostd process, the mgmt-vmware script searches for existing certificate files (rui.crt and rui.key). If it cannot find them, it generates new certificate files.

Procedure

1Put the host into Maintenance Mode.

2In the directory /etc/vmware/ssl, back up any existing certificates by renaming them using the following commands.

mv /etc/vmware/ssl/rui.crt /etc/vmware/ssl/orig.rui.crt mv /etc/vmware/ssl/rui.key /etc/vmware/ssl/orig.rui.key

NOTE If you are regenerating certificates because you accidentally deleted them, you are not required to rename them.

3Reboot your host to allow it to begin using the new certificate, or restart the host services: a Use the following command to restart the vmware-hostd process.

service mgmt-vmware restart

bUse the following command to restart the vmware-vmkauthd process. service vmware-vmkauthd restart

4Confirm that the ESX host successfully generated new certificates by using the following command and comparing the time stamps of the new certificate files with orig.rui.crt and orig.rui.key.

ls -la /etc/vmware/ssl/rui*

5Exit Maintenance Mode.

Chapter 13 Authentication and User Management

Replace a Default Certificate with a CA-Signed Certificate

The ESX host uses automatically generated certificates that are created as part of the installation process. These certificates are unique and make it possible to begin using the server, but they are not verifiable and they are not signed by a trusted, well-known certificate authority (CA).

Using default certificates might not comply with the security policy of your organization. If you require a certificate from a trusted certificate authority, you can replace the default certificate.

NOTE If the host has Verify Certificates enabled, replacing the default certificate might cause vCenter Server to stop managing the host. If the new certificate is not verifiable by vCenter Server, you must reconnect the host using the vSphere Client.

Procedure

1Put the host into Maintenance Mode.

2Log in to the service console and acquire root privileges.

3In the directory /etc/vmware/ssl, rename the existing certificates using the following commands.

mv rui.crt orig.rui.crt mv rui.key orig.rui.key

4Copy the new certificate and key to /etc/vmware/ssl.

5Rename the new certificate and key to rui.crt and rui.key.

6Reboot your host to allow it to begin using the new certificate, or restart the host services: a Use the following command to restart the vmware-hostd process.

service mgmt-vmware restart

bUse the following command to restart the vmware-vmkauthd process. service vmware-vmkauthd restart

7Exit Maintenance Mode.

Configure SSL Timeouts

You can configure SSL timeouts for ESX.

Timeout periods can be set for two types of idle connections:

nThe Read Timeout setting applies to connections that have completed the SSL handshake process with port 443 of ESX.

nThe Handshake Timeout setting applies to connections that have not completed the SSL handshake process with port 443 of ESX.

Both connection timeouts are set in milliseconds.

Idle connections are disconnected after the timeout period. By default, fully established SSL connections have a timeout of infinity.

Procedure

1 Log in to the service console and acquire root privileges. 2 Change to the directory /etc/vmware/hostd/.

3Use a text editor to open the config.xml file.