2.5 Oracle VM Post-Installation Configuration

The purpose of this section is to describe any security configuration changes that must be made after installation. However, the installers for Oracle VM components have been designed to minimize security risks by default, so potential issues are addressed automatically during the installation procedure. Some general security considerations are listed here:

  • It is good practice to remove or disable components that are not needed in a given type of deployment. However, Oracle VM is based on a lightweight, optimized version of Oracle Linux: obsolete packages and components are simply not included in the installation media.

  • Installation requires the creation and assignment of superusers and root passwords so that software can be installed and configured. As soon as the installation and configuration tasks have been completed, it is recommended that you create individual user accounts for each Oracle VM administrator. Consider disabling root access where possible.

  • Weak or plain-text protocols, such as FTP or standard HTTP, must be disabled by default. For demo and testing purposes it would be acceptable to use them, but you must always be aware that this is insecure. Communications between Oracle VM components are properly secured by default. Oracle VM Manager and the Oracle VM Servers communicate via the Oracle VM Agents, and all agent communication is SSL-encrypted. Access to the Oracle VM Manager is configured to use HTTPS by default. By default, the SSL certificate, used to encrypt communications, is signed by an internal CA certificate that is generated for the Oracle VM Manager instance during installation. Since most client applications, including user web browsers, will not have this CA certificate installed it is not possible for many client applications to validate the SSL certificate presented when accessing an Oracle VM Manager service over HTTPS. Some client applications may fail entirely if an SSL certificate cannot be validated, while other applications may simply issue a warning and allow users to proceed at their own risk. To minimize the likelihood of a man-in-the-middle attack, it is important that validation can actually take place. Therefore, it is appropriate to take one of the following courses of action:

    • Install the CA certificate for the Oracle VM Manager instance into the trusted CA certificate store for all client applications that will have access to Oracle VM Manager.

    • Change the SSL certificate used for HTTPS communications by Oracle VM Manager to use a certificate that is signed by a trusted third-party CA, for which all of your client applications already have the CA certificate installed.

    These operations are discussed in detail in Setting Up SSL in the Oracle VM Administrator's Guide.

  • Any files that may contain sensitive information should have restrictive file permissions by default. These files include audit logs, password files and configuration. Oracle VM is configured in such a way that no sensitive data, for example clear text passwords, can be disclosed in any logs or temporary files. File permissions are kept strict by default to prevent unauthorized access, and encryption is applied where required.

    Access to the physical servers is tightly restricted by default, which implies that the risk of information being compromised is very small. Therefore, sensitive data such as log files, password files and configuration data are generally well protected in an Oracle VM environment. After successful installation or upgrade of Oracle VM Manager, be sure to remove the log files from /tmp, as instructed by the installer.

2.5.1 Changing Oracle VM Agent SSL Certificates

Communications between Oracle VM Agents and Oracle VM Manager are SSL-encrypted using an RSA algorithm and 2048-bit private key. The relevant files are located in /etc/ovs-agent/cert:

  • certificate.pem

  • key.pem

  • request.pem


Any changes to the SSL certificates used by the Oracle VM Agent causes authentication failure for the Oracle VM Manager instance that currently has ownership of the server. To resolve this, after a change, you must release ownership of the server (this may include a requirement to remove a server from any server pool that it may belong to), and then rediscover the server and take ownership of it again as if it was a new server.

To replace the default self-signed certificate with your own trusted certificate, replace the certificate file and key files.

To generate a new certificate and key files, log on to an Oracle VM Server and execute the command ovs-agent-keygen. The command is used as follows:

# ovs-agent-keygen -h
Usage: ovs-agent-keygen [OPTION]
Generate SSL certificate and key files for Oracle VM Agent XMLRPC Server.
-f, --force      override existing files
-v, --version    show version number and exit
-h, --help       show this help message and exit

The generated files are placed in the directory mentioned above. If you use the "-f" option, the existing files are overwritten.

As of Oracle VM Release 3.3, the Oracle VM Agent password is only used for authentication during the initial discovery process. Thereafter, all subsequent authentication between the Oracle VM Manager and Oracle VM Agent is achieved using certificates. This approach improves security and helps to limit access to the Oracle VM Agent to the Oracle VM Manager instance that has ownership of the Oracle VM Server where the agent is running. Nonetheless, it is good practice to change the Oracle VM Agent password for any server when ownership is released. A mechanism is in place to do this when you release ownership of a server within the Oracle VM Manager Web Interface and in the Oracle VM Manager Command Line Interface.

2.5.2 Enabling LDAP Authentication on Dom0

You can enable LDAP authentication on each Oracle VM Server instance to control and log access attempts on Dom0. Enabling LDAP authentication can enhance security for a critical asset (Dom0) for the same reasons that make centralized user control valuable in other contexts.


Setting up LDAP authentication requires configuration settings that are specific to your business needs. It is beyond the scope of this documentation to provide detailed examples of the different methods to enable LDAP authentication. However, the following procedures provide basic steps to guide you through an initial configuration.

To enable LDAP authentication on Dom0, you can do either of the following:

  • Follow the procedure in the Oracle Linux 6 Administration Guide to configure and install the openldap-clients, sssd, and sssd-client packages. You must use the authconfig command to enable LDAP authentication instead of running the Oracle Linux Authentication Configuration GUI.

    For more information, see Enabling LDAP Authentication at: http://docs.oracle.com/cd/E37670_01/E41138/html/ol_enblcli_ldap.html

  • Configure LDAP authentication on Oracle VM Server as follows:

    1. Verify that the required packages are available and install them, if required.

      # rpm -qa | egrep -i 'nss-pam-ldap|pam_ldap'
    2. Copy the LDAP server SSL or TLS certificate to the following directory:


    3. Set permissions on the certificate.

      # chmod 644 /etc/openldap/cacerts/openldap.pem
    4. Rehash the CA certificates.

      # cacertdir_rehash /etc/openldap/cacerts
    5. Enable LDAP authentication. Either use the authconfig command or start the interface for configuring system authentication.

      • # authconfig --enableldap --enableldapauth --ldapserver=ldap://hostname:389 \
         --ldapbasedn="dc=example,dc=com" --update

      • # authconfig-tui

The following are example configurations for LDAP authentication:

  • /etc/openldap/ldap.conf

    TLS_CACERTDIR /etc/openldap/cacerts
    BASE dc=example,dc=com
    URI ldap://hostname:389
  • /etc/pam_ldap.conf

    ssl start_tls
    tls_cacertdir /etc/openldap/cacerts
    base dc=example,dc=com
    uri ldap://hostname:389
    pam_password md5
  • /etc/nslcd.conf

    ssl start_tls
    tls_cacertdir /etc/openldap/cacerts
    base dc=example,dc=com
    uri ldap://hostname:389
    uid nslcd
    gid ldap

2.5.3 Enabling FIPS for OpenSSL on Oracle VM Server

Consider enabling FIPS mode for OpenSSL to ensure that your OpenSSL is compliant with Federal Information Processing Standard (FIPS) Publication 140-2, which is a standard that establishes security requirements for cryptographic modules. This action can optionally be performed on each system that forms part of the infrastructure of your Oracle VM deployment. Further information on enabling FIPS mode for OpenSSL is provided in the Oracle Linux 6 Security Guide available at:


In this section we outline the steps required to enable FIPS for OpenSSL on Oracle VM Server. It should be noted that there are some minor differences between Oracle VM Server and Oracle Linux 6 and therefore some of the steps to set up and configure FIPS mode for OpenSSL may differ from the instructions provided for Oracle Linux 6.


The Oracle VM Server must have been registered with ULN. The openssl-fips package is available on the ol6_x86_64_addons channel.

To make an Oracle VM Server compliant with Federal Information Processing Standard (FIPS) Publication 140-2, perform the following steps:

  1. First check that FIPS is not already enabled:

    # cat /proc/sys/crypto/fips_enabled
  2. Log in to ULN and enable the ol6_x86_64_addons channel for your system.

  3. Install the dracut-fips package:

    # yum install dracut-fips

    This package must be installed so that the system checks the integrity of the kernel components at boot time.

  4. Remove the existing openssl package and install the openssl-fips-1.0.1* package. You can use yum shell to perform these transactions as shown here:

    # yum -y shell <<EOF
    remove openssl
    install openssl-fips-1.0.1*

    You cannot use separate yum remove and yum install commands as yum itself depends on the OpenSSL library being available.

    Alternatively, download the openssl-fips-1.0.1* package and use the rpm command instead:

    # rpm -e --nodeps openssl
    # rpm -ivh openssl-fips-1.0.1*.rpm
  5. Identify the device UUID for your boot partition. There are a variety of ways to do this, the following shell command should return the UUID of the device being used for your boot partition:

    # blkid `mount |grep \/boot|awk '{print $1}'`

    Note that if you have partitioned the disk in such a way that /boot is not on its own partition, the above command will not return any output.

  6. Edit /etc/default/grub:

    1. If /boot or /boot/efi is located on a separate partition from / and you have obtained the UUID for the device where this partition is located, you must add the following line to ensure that when grub is updated FIPS is enabled automatically and that the system is able to identify the appropriate device to boot from:

      GRUB_CMDLINE_LINUX_DEFAULT="splash=verbose verbose crashkernel=224M-:112M showopts fips=1 \
                boot=UUID=boot_UUID root=UUID=root_UUID"

      Where boot_UUID and root_UUID are the UUIDs that you obtained in the previous step.


      If /boot or /boot/efi exist on a separate partition from / and you do not specify a valid boot= entry, the system crashes because it cannot locate the kernel's .hmac file.

    2. If /boot or /boot/efi is not located on a separate partition from /, then you do not need to specify the boot partition:

      GRUB_CMDLINE_LINUX_DEFAULT="splash=verbose verbose crashkernel=224M-:112M showopts fips=1"
  7. Rebuild the GRUB config to use the changes that you have made to /etc/default/grub:

    1. On BIOS-based systems, issue the following command as root:

      # grub2-mkconfig -o /boot/grub2/grub.cfg
    2. On UEFI-based systems, issue the following command as root:

      # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
  8. Edit /etc/sysconfig/prelink and set PRELINKING=no.

    Prelinking must be disabled to allow the system to verify the integrity of modules correctly.

  9. Remove all existing prelinking from binaries and libraries:

    # prelink -u -a

    If you do not disable and remove all prelinking, users cannot log in and /usr/sbin/sshd does not start.

  10. Recreate the initramfs file system:

    # dracut -f

    This can take some time to complete. You may run this with the -v or --verbose switch to monitor the process.

  11. Remove the existing SSH host keys:

    # rm /etc/ssh/ssh_host*

    OpenSSH uses the FIPS-validated OpenSSL library modules to generate new, FIPS-approved keys when the system is next rebooted. (Under FIPS mode, ssh-keygen can create new RSA host keys in /etc/ssh, but not DSA keys, and it displays key fingerprints as SHA1 hashes instead of as MD5 hashes.)

  12. Shut down and reboot the system into FIPS mode.


    While the system is rebooting, generate input events by pressing keys at random or by moving the mouse. You should create at least 256 such events to ensure that the system has sufficient entropy available for key generation.

  13. When the system has rebooted, check that FIPS is enabled:

    # cat /proc/sys/crypto/fips_enabled
  14. To test that FIPS is functioning correctly, run the following OpenSSL command and check that an error is returned:

    # openssl md5 /etc/hosts
    Error setting digest md5
    140297679636296:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180:

    The error is returned when you attempt to obtain an MD5 hash, because MD5 is not a FIPS approved Hash Standard.