Skip to content

Authentication Guide

Last updated on Oct 31 2023.


This document presents and describes the authentication process that users must follow to access the Inuvika OVD Enterprise platform.


To access their OVD environment, users must authenticate first. While the traditional / historical way of authentication involves a login and password, more options are available with OVD, such as Two-Factor Authentication (2FA) or external authentication providers.

Password authentication

OVD's default authentication method uses password-based authentication.

End-users will have the ability to change their passwords. They can also be forced to change it when the password has expired. Passwords can be expired manually by the administrator or automatically by implementing a password expiry policy.

Directory integration

When OVD is configured to use an external directory instead of it's own database, end-users can authenticate with OVD using their directory credentials.

OVD also supports password change for LDAP and MS AD as long as users have the rights to do so.

Restriction with LDAP module

Due to limitations with the LDAP directory, OVD cannot detect an expired password if expired by an expiry policy.

In such a case, the behavior on the user's side will not be affected. The user will still be prompt to change their password. However, the Administration Console will display the password status as valid.

Password Policies Set In Your External Directory

When using an external directory, such as LDAP or an AD, the administrator may put password policies into place. These policies will still apply after integrating with OVD.

In the case a periodic password expiry policy is set, OVD clients will prompt the user when their password expires. The prompt will contain instructions to change their password.

Password content policies set in the external directory, such as minimum password length and character range, will be honored during password change.

Two-Factor Authentication (2FA)

2FA adds an additional layer of security for users as it will require both the password and an external time-sensitive secret.

It can be Enabled or Enforced by your administrator in the Users > Authentication Settings > Security Settings section of the OVD Administration Console. For more information, please read Security settings.

If 2FA is Enforced, users will be unable to access their OVD accounts until they configure 2FA. The OVD client will prompt users with this information and redirect them to the OUC to setup 2FA for their accounts.

Require Time Synchronization

In order to use 2FA, you must ensure that the Session Manager OS has an up-to-date synchronized clock with an NTP service.

This can be done by installing and configuring an NTP service on the OSM node itself or on the hypervisor, depending on your infrastructure.

Two-Factor Authentication requires a mobile device with a specific application that will generate verification codes that users will use in conjunction with their password to login to OVD.

Methods for 2FA with OVD

OVD provides multiple different methods users can use to setup two-factor authentication.

Inuvika Authenticator mobile app

For security purposes, Inuvika provides its own mobile application, the Inuvika Authenticator application. This application is supported on Android and iOS devices and available in the applications stores:

The OVD User Configuration also provides these links to the mobile applications when users setup 2FA.


Users can register email addresses or use the email address associated with their user account. When this method is selected, an email is sent to the user with a randomized code. The code can then be submitted in the OVD application as the 2FA code.

Security keys

Security keys are hardware authentication devices that can be used as your second factor of authentication instead of a verification code. They offer the best security for the second factor with a unique cryptographic key embedded in its hardware.

Keys must be compatible with the Universal 2nd Factor (U2F) and/or Webauthn open standards and can be used in USB and Near-Field Communication (NFC).

One of the key security aspects to configure in OVD is the AppID. This is used to protect the user against phishing attacks by matching the end of the OVD server's public domain name.

Example: if the OVD Web-Access URL is, the AppID field can be set to or


This 2FA method requires users to use a domain name (as opposed to an IP address URL) to access OVD, regardless of the OVD client used.

When using a web browser to access OVD, https communication is required in order to use security keys.

The mobile client only supports NFC-enabled keys.

Backup Code

Backup codes, also known as emergency codes or rescue codes, can be generated by the user once a 2FA method has been configured.

Each code can then be used once, and only once, to login to OVD. This method is not supposed to be used on a daily basis but rather for emergencies or as a backup access plan.

Security of the OVD 2FA functionality is limited by how users securely store their backup codes.

Duo Security

OVD can delegate 2FA out to Duo Security as a third party provider. OVD supports the following Duo methods: SMS, Phone call, Duo Mobile and Push notification.


This method is only available in OVD 3.2+

To configure OVD with Duo Security:

  1. Login to your Duo Security console
  2. Under the Applications page, create an Auth API application
  3. Copy the Integration key, Secret key, and API hostname details to the corresponding fields on the OVD Administration Console.

See the Duo documentation for more information on how to configure and manage Duo 2FA:

OVD User Configuration (OUC)

The OUC is a service that lets users manage their authentication settings (password change & 2FA configuration).

Users will be redirected to the OUC from any OVD client from the following actions:

  • User click the "Security settings" button
  • User's password is expired while authenticating
  • User must configure 2FA before connecting to OVD

TLS/SSL Server Certificate

The OUC requires the use of an X.509 certificate in order to secure communication.

A self-signed certificate is generated during the installation process but this is only designed for evaluation and not for production. Without a signed certificate installed, users will receive a security warning blocking the site from their browser when accessing the service.


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.

Configuration may change depending on the following scenarios:

  • All clients directly connect to OSM (no ESG is used): Install the certificate on the OSM node in Apache.

  • All clients connect to ESG (including OWA): Install the certificate on the ESG

  • Some clients connect to ESG and other don't: Install one certificate on the OSM node in Apache and another certificate on the ESG.

Refer to configuring a certificate on the ESG.

External Authentication Providers: Kerberos & SAML 2.0

OVD supports delegating authentication to external services.

These methods are detailed in their own dedicated documents: