Skip to content

Initial Configuration

Last updated on Nov 15 2023.

Server registration

In the Administration Console, go to Servers -> Unregistered Servers. Register all your servers and switch them from "maintenance" to "production" mode.

Warning

If your server does not show up in the list, you might have a DNS configuration issue.

If you want to change the name of any of your servers, click on its name and on the next page enter required name in Display name field.

Install a proper SSL/TLS Certificates on the OVD farm's entry points

The OVD farm requires the use of an X.509 certificate for secure communication.

Self-signed certificates are not for production use. Self-signed certificates are generated during the installation, but this is only designed for evaluation purposes.

Without a signed certificate installed, all users will receive a security warning in their browsers preventing them from accessing the service.

Warning

Before switching your OVD service to production or even deploying to a significant number of users, you must replace the self-signed certificate with a signed certificate obtained from a Certificate issuer.

Certificates must be installed on each node hosting HTTPS access, except for those that are not publicly accessible and are only accessible through Enterprise Security Gateway (ESG).

  • OSM / OAC / OUC
  • OWA
  • ESG

Design a validation plan

Finally, Inuvika recommends defining some form of acceptance criteria and a basic validation plan that will be used as a reference when updating and complexifing the OVD farm.

Keep notes about information on servers (VMs, IP addresses, roles) and any custom / non-standard configurations that you may have performed.

Application server - optional configuration

User Isolation

By giving access to the same Application Server to different user sessions, connected users may find several ways to be aware of each other. Users should not have any rights to view or alter another user’s data but the default Operating System rules can allow users to list existing user accounts and access this data.

Our recommendation, as part of our OVD Best Practices, is to change the Operating System’s default access rules for the home directory base folders.

  • Windows: C:\Users 

    >
    icacls C:\Users /deny "OVDUsers:(NP)(RD)"

    Additionally, you can also apply the following rule which will prevent OVD Users from creating content in C:\. 

    >
    icacls C:\ /deny "OVDUsers:(NP)(W)"

  • Linux: /home 

    #
    chmod o-rw /home/

    Important

    This configuration is not compatible with Snap applications on Ubuntu 22.04 "Jammy Jellyfish". Snap applications are running inside a container and need access to the user's profile.

    If the OVD Application role was deployed using the OVD One Touch Installer, this configuration has already been applied. To revert this configuration and enable Snap applications, grant access by:

    #
    chmod o+rw /home/
    • For RHEL 8, you need to install, enable and start lxcfs service 
      #
      yum install lxcfs
      #
      systemctl enable --now lxcfs

Deactivation of Windows Security on Windows Server 2019/2022

As of Windows Server 2019, the new application Windows Security grants users read-access for critical configurations (firewall, antivirus, device security, etc...). Modifications of these permissions are controlled by the User Account Control (UAC).

Our recommendation, as part of our OVD Best Practices, is to remove user access for Windows Security. Administrators will still be able to access it after this is done.

  • Remove access for the Users Group:

    1. Set environmental variable 

      >
      set WS=%SystemRoot%\SystemApps\Microsoft.Windows.SecHealthUI_cw5n1h2txyewy\SecHealthUI.exe

    2. Remove ownership 

      >
      takeown /f %WS%

    3. Remove access 

      >
      icacls %WS% /deny "Users:(X)"

Let Windows apps access the microphone on Windows Server 2019/2022

Windows Server 2019 introduced a user setting to allow applications to use the microphone. As OVD prevents the use of the Settings pannel, they can't configure it. To globally enforce usage of the microphone, configure the following Group Policy settings:

  1. Navigate

    Computer configuration
  → Administrative Templates
    → Windows Components
      → App Privacy
        → Let Windows apps access the microphone

  2. Set state to Enabled

  3. Set Default for all apps to Force Allow

Secure Gateway

TLS/SSL Server Certificate

The ESG requires the use of an X.509 certificate for secure communication.

A self-signed certificate is generated during the installation, but this is only designed for evaluation purposes. Self-signed certificates are not for production use.

Without a signed certificate installed, all users will receive a security warning in their browsers preventing them from accessing the service.

Warning

Before switching your OVD service to production or even deploying to a significant number of users, you must replace the self-signed certificate with a signed certificate obtained from a Certificate issuer.

Identify the service access point

The certificate issuer will ask for a Common Name (CN). This information is critical as failure to provide the correct name will result in an unusable certificate.

For an OVD environment the CN of the certificate is the ESG service access point, also called the fully qualified domain name (FQDN). For example, if your ESG service is available at ovd.example.com and you expect all your users to use this name to access OVD, this is the FQDN you must provide as the certificate CN.

Warning

In digital certificates a CN can not be an IP - it must be a name (as DNS).

Alternative access points, such as DNS entries and / or IP addresses, can be configured using the Subject Alternative Name (SAN) extension.

For multiple service access points or more complex configurations, please contact your certificate issuer and/or contact Inuvika.

Install the issued certificate

Once your certificate issuer has received your information, you will be given the certificate attached to a private key file, as well as a number of Intermediary CA certificates used by your provider. Please download all these X.509 certificates in PEM representation.

Once you have downloaded all the X.509 files, they must be concatenated in a single PEM file in a specific order. Use a text editor to create a file named ovd-esg-issued.pem and copy the content of each file into it in this exact order:

  • Private key
  • Server certificate
  • Intermediary CA certificate +1
  • Intermediary CA certificate +x

Once this is done you may install the certificate on the ESG:

  • Copy the ovd-esg-issued.pem file to the ESG host

  • Create a copy of the self-signed PEM file as a backup: 

    #
    cp /etc/ovd/slaveserver/gateway.pem /etc/ovd/slaveserver/gateway.pem.orig

  • Copy the file containing the new certificate to the file 

    #
    cp ovd-esg-issued.pem /etc/ovd/slaveserver/gateway.pem

  • Reload/restart the ESG service to activate the new SSL certificate

    • OVD version 3.2+ 

      #
      systemctl reload ovd-slaveserver

    • OVD version <3.2 

      #
      systemctl restart ovd-slaveserver

Use a web browser to go to your ESG service access point using HTTPS (in our example: https://ovd.example.com/) and verify that the communication is secure and the given certificate is the one you received from your issuer.

OVD Web Access Configuration

For security reasons, the ESG isn't configured to allow communication to the OVD Web Access (OWA) by default. The configuration can be changed to allow access. This will allow you to then provide a single secure (SSL) connection point for all clients (EDC, EMC, OWA).

Note

The OWA itself may be configured to provide secure access to users outside the LAN. This requires the use of a third party network component, such as a Reverse Proxy and/or a Firewall (NAT redirection).

In such cases, the ESG is not mandatory to provide a WAN access, but this is only for the OWA! An ESG is required for WAN access from EDC / EMC.

To enable the OWA access in the ESG:

  • Edit the configuration file /etc/ovd/slaveserver/slaveserver.conf and locate the line: 

    # web_client = http[s]://ip[:port]/

  • Uncomment the variable and set the value to the URL of your OWA. For example: 

    web_client = http://webaccess.test.demo/

  • Save the file and restart the slaveserver service. 

    #
    systemctl restart ovd-slaveserver

Advanced Configuration Settings

The ESG configuration is stored in the file /etc/ovd/slaveserver/slaveserver.conf. The configuration may be adjusted by editing the file and changing the contents of the Gateway section as described below:

  • address: 0.0.0.0 (default). Defines the IP address of network interface on which the ESG should bind. By default, the ESG binds on all the network interfaces
  • port: 443 (default). Defines the port to use.
  • max_process: 10 (default). Defines the maximum number of processes to run on the ESG server.
  • max_connection: 100 (default). Defines the maximum number of connections that can be opened on the ESG server.
  • process_timeout: 60 (default). Defines the timeout in seconds per process

  • connection_timeout: 10 (default). Defines the timeout in seconds per connection

  • admin_redirection: true or false (default). Use this setting to allow access to the OVD Administration Console through the ESG. This parameter is deprecated with ovd 2.9. It is replaced by admin_host

  • admin_host: hostname, ip address or url. Use this setting to allow access to the OVD Administration Console through the ESG. It replace the parameter admin_redirection

  • web_client: hostname, ip address or url. Use this setting to allow access to the OVD Web access through the ESG.

  • root_redirection: Use this setting to define the root path for the Gateway. For example, enter the value /ovd to automatically redirect a connection request for https://gw.demo to https://gw.demo/ovd

  • http_keep_alive: true (default) or false. Enable or disable session keep alive.

  • certificate_path: gateway.pem (default). Location to the TLS/SSL server certificate file to use for the ESG.

    OVD Version restrictions

    The SOAP endpoint is not available after OVD versions 3.1.

Important

Don't forget to restart the slaveserver service after any configuration change.

Protocol and Cipher Settings

With the default configuration, the Enterprise Secure Gateway accepts connections encrypted using a minimum of TLS 1.2.

The security settings for the ESG are stored in the file /etc/ovd/slaveserver/slaveserver.conf. The configuration may be adjusted by editing the file and changing the contents of the Gateway section as described below:

  • minimal_protocol: One of sslv3, tlsv1, tlsv1.1, or tlsv1.2 (default). Specify the minimal TCP security protocol the ESG supports. The default value is the most secure, keeping backward compatibility.

    Warning

    TLS 1.3 (RFC 8446) may be supported by your version of OpenSSL with increased security for web-browsers that implement it.

  • cipher_list: If this option is set, it will configure the cipher preference list accepted by the Enterprise Secure Gateway by preference order. If it is not set, the default system ciphers will be used.

    To list all the ciphers supported on your system, use the command:

    #
    openssl ciphers -v 'ALL'

    The format used for this setting is described at https://www.openssl.org/docs/man1.1.1/man1/ciphers.html

    The following configuration enables all ECDHE key exchange suites having an AES cipher and sorts them by strength. It also moves all AES256 ciphers to the end of the list. This is a high-security list that has good compatibility with OpenSSL version 1.1.1 or greater.

    cipher_list = ECDHE+AES:@STRENGTH:+AES256

    The list below works on Ubuntu versions greater or equal to 16.04 and CentOS 7, and enables all suites based on the AES cipher with any key-exchange algorithms. It is less secure, but has better compatibility.

    cipher_list = AES

    Another way is to explicitly configure the accepted list of ciphers. This list is compatible with Windows 8+ clients:

    cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-SHA256:DHE-DSS-AES256-SHA:DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA

An online tool like ssllabs.com is useful to test the final configuration.

Another option is to use the command-line tool testssl.sh if the ESG is not exposed on the internet.