Initial Configuration¶
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
Additionally, you can also apply the following rule which will prevent OVD Users from creating content in
C:\
. -
Linux:
/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:
- For RHEL, you need to install, enable and start lxcfs service
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:
-
Set environmental variable
-
Remove ownership
-
Remove access
-
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:
-
Navigate
Computer configuration → Administrative Templates → Windows Components → App Privacy → Let Windows apps access the microphone
-
Set state to
Enabled
- Set
Default for all apps
toForce 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:
-
Copy the file containing the new certificate to the file
-
Reload/restart the ESG service to activate the new SSL certificate
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: -
Uncomment the variable and set the value to the URL of your OWA. For example:
-
Save the file and restart the slaveserver service.
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 interfacesport
: 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 byadmin_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 parameteradmin_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 forhttps://gw.demo
tohttps://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:
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 anAES
cipher and sorts them by strength. It also moves allAES256
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.The list below enables all suites based on the AES cipher with any key-exchange algorithms. It is less secure, but has better compatibility.
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.