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 2FA or external authentication providers.
OVD version requirement
This documentation is designed for OVD version 3.0+ and does not support earlier versions.
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.
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 a verification code generated in the Inuvika Authenticator mobile app to login.
It can be Enabled or Enforced by your administrator in the Users > Authentication Settings > Security Settings section of the OVD Administration Console.
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.
Dedicated mobile application¶
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.
For security purposes, Inuvika provides its own mobile application, the Inuvika Authenticator application. This application is supported on Android and iOS devices.
To find the application, the OVD User Configuration provides links to the mobile applications when users setup 2FA. Users can also search for "Inuvika Authenticator" on the Apple App Store or Google Play to find it.
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: