Microsoft Active Directory Integration Guide


This document describes how to integrate Inuvika OVD 2.x with Microsoft Active Directory based on Windows 2012 R2.


Version Date Comments
1.6 2017-07-18 Updates for OVD 2.5, Add Windows 2016 support and correct typos
1.5 2017-07-18 Reformatting
1.4 2016-07-06 Updates for OVD 2.0
1.3 2016-06-23 Updates for OVD 1.4.1
1.2 2015-12-15 Incorporate changes for OVD 1.4
1.1 2005-10-05 Incorporate SSL configuration information and corrections
1.0 2015-06-05 Initial version


This document describes how to integrate Inuvika OVD 2.x with Microsoft Active Directory based on Windows Server 2012 R2. Using an example Active Directory, the document describes the alternative integration methods, and provides detailed instructions and best practices for using Microsoft Active Directory with Inuvika OVD 2.x. A section describing the implementation steps for providing secure access to the Active Directory server is also included.


Microsoft Active Directory is an object directory server and facilitates user authentication and access control in a common domain. The Active Directory domain may be a single domain, or a sub-domain that is part of the Active Directory forest.

To allow an organization to benefit from using their Active Directory server, Inuvika provides built-in integration so that user and group management is centralized. There are several options for configuring the level of integration with Microsoft Active Directory. As a minimum, integration with Active Directory means that users are defined within Active Directory and OVD will delegate user authentication to Active Directory. OVD will retrieve the list of users from Active Directory but will not modify any user data. This allows the enterprise to manage users and passwords together with related policies in a single centralized manner.

The system administrator can further choose whether to define the user groups that will be used by OVD, in Active Directory or in OVD.

In addition, there are two different modes of managing users when integrating with Active Directory. One option is to allow Inuvika OVD to manage the creation of shared folders and user profiles. The second option is to use Active Directory to define the shared folders and user profiles.

For security reasons, the system administrator may also wish to implement SSL communication channels to secure the data transmission between the Active Directory server and the OVD Session Manager.

Finally, if the System Administrator may wish to implement Windows Single Sign-On (SSO) using Kerberos. The steps for implementing Windows SSO are described in the document Single Sign-On with Microsoft Active Directory using Kerberos.

Before starting the integration with Active Directory, the decision on which options to use should be made. Each of the options (except for SSO) is described in more detail below and can be configured in the OVD Administration Console (OAC) by selecting the Microsoft option of the "Domain Integration Settings" on the "Configuration" tab. A further section describes the steps for implementing secure data transmission.

Microsoft Active Directory Setup

For the purposes of this documentation, we will use a Microsoft Active Directory domain called domain.test.demo. In this example, the domain controller hosts Microsoft Active Directory Domain Services and the DNS Server. The domain controller FQDN (Fully Qualified Domain Name) is dc.domain.test.demo with the IP

The Microsoft Active Directory used in this document is running on Windows Server 2012 R2 and is set to run at the 2012 R2 functional level.


This section describes how to configure OVD and Active Directory so that OVD can access data stored in Active Directory.

Microsoft Active Directory Best Practices

Inuvika recommends the following best practices when integrating with Active Directory:

  1. Define all the OVD objects within a dedicated Active Directory OU. These objects are:
    • User Groups specific to the OVD environment (if using Active Directory to define User Groups)
    • Windows OVD Application Servers (OAS) (when managing users in Active Directory)
  2. Stop all domain wide custom policies at the OU level (no propagation of its content). If some policies are mandatory, they should be set after successfully integrating Active Directory with OVD to ensure they do not conflict with the integration.

OVD Server DNS Configuration

Inuvika recommends configuring all the OVD servers in the farm to use the same DNS Server to simplify management. In the example in this document, the DNS Server is provided by the Active Directory Domain Controller. The following example describes how to configure and test the DNS configuration to allow the OVD Session Manager (OSM) to use the DNS Server running on the domain controller.

Ubuntu LTS DNS Configuration

Edit the network interface definition file used by this server

nano /etc/network/interfaces

and add the DNS server information

#The primary network interface
auto eth0
iface eth0 inet static
         dns-search domain.test.demo

Save the file and check that the configuration is working correctly by searching DNS for the Active Directory Domain Controller, which in our example is dc.domain.test.demo****

nslookup dc

If the system is setup correctly, the command should output information similar to the following:

root@osm:~# nslookup dc

Name:     dc.domain.test.demo

Next check the DNS reverse name resolution using nslookup:


The command should output something similar to the following:

root@osm:~# nslookup
Address: name = dc.domain.test.demo

Configuring OVD to Use Active Directory

To configure OVD to use Active Directory, login to the OAC, go to the "Configuration" tab and select "Domain Integration Settings". On this page, select Microsoft from the drop down list. The system will display the following screen:

MS AD Integration

Enter the following information relevant to your configuration.

Domain: enter the FQDN of the Active Directory domain (the domain name must be defined in lowercase). In the example, this is domain.test.demo

Primary Host and Secondary Host fields are optional if the OSM server has been configured to use DNS as described above. Otherwise, enter either the FQDN or IP address of the Domain Controller.

Authentication: OVD requires read-only access to Active Directory. Any standard user from the default Users container that has the read all properties enabled can be used. A user from another container will not have this attribute set and therefore requires further configuration. Please refer to Chapter Setting read access for a User in Active Directory for further details.

Test: The Test button performs a connection check. If everything is OK then the system will display information in the upper right corner of the screen in green. If there are any errors, then the information about the error will be displayed in red.

Once the configuration has been defined and tested successfully, save the definitions using the Save button.

To complete the configuration, refer to the Users, User Groups and Domain Users settings described in the next sections.

Advanced Configuration Options

It is possible to refine the connection details to Active Directory using the advanced options as shown below:

LDAP settings

LDAP port: The default port is 389. A different port may be used corresponding to the port defined on the Active Directory server.

Use LDAP encryption (SSL): checking this box enables LDAPS (LDAP over SSL). In this case, the TCP port must be changed manually from 389 to 636 when using the default port. Further details are provided in Section 8 LDAPS Configuration.

Specific organization unit: an organization unit (OU) may be specified to filter the directory data. Data defined for other OU's will be ignored. LDAP connection timeout: the timeout value in seconds to be used when executing LDAP requests to the Active Directory server. A value of 15 seconds is used by default. This value is shared by the Active Directory, LDAP and Novell eDirectory integrations.

Microsoft Active Directory With Multiple Domains

When using a Microsoft Active Directory that has multiple domains, the configuration must be changed as follows:

Multiple domains

Domain: the Active Directory domain (usually the root of the domain)

Primary Host: this is optional if DNS is set up as described above. If required, enter the IP or FQDN of the server acting as the Global Catalog (GC) for the Active Directory forest. The Active Directory Sites and Services tool provided by Microsoft can be used to check the GC information in a forest.

LDAP port: When connecting to a Global Catalog, the TCP port to use is by default 3268 and 3269 when using SSL (LDAPs)


When integrating with Active Directory, the OVD Users page in the OAC will always retrieve and display the set of users from Active Directory independent of other Active Directory integration choices. The user data cannot be modified within OVD, Active Directory must be used to modify any user data.

OVD provides support for both the sAMAccountName (default) and the userPrincipalName. Select the required option in the configuration page as shown below:

Users settings

In both cases, when more than the configured number of users are available (15 by default), a search field will be displayed to allow the search to be refined. Wild card characters can be specified such as *** when specifying the text to use for the search. The number of users to display can be configured by the Maximum items per page setting available in the System Setting page in the Configuration tab in the OAC.

Users search

Using sAMAccountName

When this option is selected, OVD will map the user login name to the sAMAccountName. The sAMAccountName is limited to 20 characters and is typically of the form user10, no domain information is included. This option is the default one.

Using userPrincipalName

When this option is selected, OVD will map the user login name to the userPrincipalName. The userPrincipalName is of the form user10@domain.test.demo. This option should be selected if user names may exceed the 20-character limit imposed by the sAMAccountName (without '@' and the domain part).

User Groups

Irrespective of how users are managed, user groups can be defined using either Active Directory or OVD by selecting the relevant option in the configuration page as shown below:

User groups settings

Using Active Directory User Groups

When using Active Directory user groups, the user group data is defined in Active Directory and then retrieved by the OSM as read-only data. The data is used to publish OVD applications either using the OAC or via the OSM API.

In this case, all the user groups to be used in OVD must be created and managed in Active Directory. Inuvika recommends using one or more dedicated OVD user groups, for example "Inuvika Users" and to perform a search to find the user group as in the example below should the number of user groups exceed the page limit setting.

User groups search

Adding a user to or removing a user from a user group is performed within Active Directory using Microsoft tools such as the Active Directory Users and Computers snap-in:

Add user in MS AD

Using Internal User Groups

When using internal user groups, user groups are created using either the OAC or the OSM API, and stored in the OVD database. The list of available users will be retrieved from Active Directory by OVD, and can be added to a user group for resource publishing via the OAC or OSM API.

This method can be useful when using a complex Active Directory with many OUs and user groups, or when there is limited access to Active Directory with no option to create specific OVD user groups.

Domain Users

OVD Users can be managed within Active Directory or by Inuvika OVD by selecting the relevant option in the configuration page as shown below. There are important differences in functionality between these two options as described in detail in the following sections.

Domain users settings

Manage Users In OVD

To manage users in OVD select the option: Use internal method to handle users in OVD sessions. In this case, OVD will manage user profiles and shared folders using the OFS as well creating users on the relevant application servers.

  • This mode is required if using both Linux and Windows application servers
  • OVD manages user data persistency through the use of the OFS role which provides centralized Linux and Windows profile data management
  • OVD manages user sessions:
    • The OVD Admin account (an OVD account local to the Windows application server) creates a user session on behalf of the user account on a Windows OVD Application Server (OAS) and creates a local user profile with TS/RDS local access
    • When a user logs off, the OVD Admin account deletes the local user session, backs up all user data to the OFS store (in the case that user persistency is enabled)
    • The OVD Admin account deletes the user from the local accounts on the Windows server
  • Active Directory is used for user authentication and optionally for user groups. Other Active Directory services are not supported in OVD such as GPOs, network shares, application and printer publishing
  • Windows OAS servers can be members of an Active Directory domain or simply running in a WORKGROUP

Manage Users In Active Directory

To manage users in Active Directory, select the option: Use Active Directory to handle users in OVD sessions (not compatible with Linux applications). In this case, users are managed entirely in Active Directory, the OFS is not used for user profiles or shared folders.

  • This mode can only be used for a pure Windows OAS environment.
  • Linux OAS servers are not supported in this mode.
  • Not all Session Manager settings apply in this mode.
  • Microsoft roaming profiles are required to provide user profile data persistency within the OVD server farm (in the case of load balanced OAS Windows servers).
  • A full Active Directory integration is provided including GPOs, network shares, application and printer publishing.

See Chapter 7 Active Directory Recommended Configuration for further information on how to setup OVD in a full Active Directory environment

Setting read access for a User in Active Directory

In this example, we have a specific account created in an OVD dedicated Organization Unit in Microsoft Active Directory. By default, users created outside the default Users container do not have the read all properties attribute which is required by OVD.

In this example, our account is admin which is a domain user account. Start the Active Directory Users and Computers snap-in.

Read Access for a User

Then select the domain object / View / Advanced Features

Advanced features

Now select domain object / properties

Domain Properties

Now click the Advanced button

Domain Properties - Access

Click Add and select the user account.

Add user for Admin rights

Select the Properties tab:

Permissions tab

In the Apply to drop down, select this object only Select Read all properties

Read Access for a User

Click OK and save all changes.

Dedicated Organization Unit

It is best to create a dedicated organization unit (OU) in Active Directory to make it easier to manage the OVD server deployment and other OVD objects such as user groups.

Dedicated Organization Unit

Create all objects related to the OVD farm inside the OU if possible and particularly:

  • User Groups (if defining user groups in Active Directory)
  • Windows Application Servers (if managing users in Active Directory)

Stop GPO Inheritance

It is highly recommended to stop domain GPO inheritance to avoid any possible negative impact of domain policies on the OVD environment. If some domain GPOs need to be applied to the OVD servers and users, those GPOs should be applied only after OVD has been successfully evaluated without them. This is important so that policies that may conflict with OVD or cause other problems can be isolated.

Recommended GPOs will vary from one environment to another. It is recommended to check the Microsoft web site for the recommended GPOs for a Windows 2016, 2012 R2, or 2008 R2 server.

A GPO that must always be set for each Windows OAS is the User Group Policy loopback processing mode. When user profiles for both Windows workstations and Windows RDS servers are managed using Active Directory, if this policy is not set, registry settings from a Windows 8 system may be overwritten by Windows 2008 R2 registry settings. With this policy set to Replace this problem will not occur.

User Group Policy loopback processing mode

Session Time Limit Settings

The session time limit settings available in the OVD Administration Console are not usable when Active Directory is configured to manage users (Section 5.2 Manage Users In Active Directory).

Session Time Limits

The Sessions Time Limits settings for this configuration can be set using Group Policies. The relevant Group Polices are located under Computer Configuration>Administrative Templates>Windows Components>Remote Desktop>Services>Session Time Limits as shown in the screenshot below. Set the values that you require using these parameters.

Inuvika OVD Service Considerations

In a full Active Directory environment, some additional configuration settings are required to be applied on all the OAS Windows servers involved in an OVD farm. Two OVD applications need to be published in the RemoteApp Manager. In Windows Server 2008 R2, use the MMC snap-in called Remote App Manager on every individual RDSH server to publish the applications. On Windows Server 2012, management of Remote Apps can be performed centrally in the Server Manager. In both cases, the OVDDesktop.exe and OVDRemoteApps.exe applications must be published. The screenshot below shows these applications being published in a Windows Server 2008 environment.

RemoteApp Manager

These two OVD applications are not managed by OVD when the full AD mode is configured. They must be published as RemoteApps and also be allowed to run as the initial program when an OVD session is started. For each OAS Windows server, select the RDSH Configuration and modify the RDP-Tcp Properties to apply the setting Run initial program specified by user profile and Remote Desktop Connection or Terminal Services client as shown below.

RDP-TCP properties

Alternatively, the Allow remote start of unlisted programs GPO can be modified to specify that remote users can start any program on the RDSH server. The full path for the GPO is Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections as shown in the screenshot below.

Allow remote start of unlisted programs

LDAPS Configuration


In order to enable Active Directory and OVD to use Transport Layer Security (TLS) for communication, an X.509 certificate must be configured for use with Active Directory. The certificate may be a commercial SSL certificate or a self-signed certificate. The OVD Session must be configured so that it can trust the certificate. The port used for the communication between the Active Directory server and the OVD Session Manager, by default 636, must be open.

The sections below describe the steps required to implement secure data transmission between Active Directory and the OVD Session Manager.

DNS Configuration

It is very important that the correct DNS configuration entries are made so that the reverse and forward lookup for the Active Directory server are possible.


The DNS server needs to have records containing the FQDN of the Active Directory server, the FQDN for the OSM and the short hostname. This is crucial so that the reverse name lookup using the PTR record will match and the common name in the certificate can be correctly resolved.

Active Directory Configuration

In most cases, the Active Directory Domain Controller would typically be the Certificate Authority for any workstations or users that belong to its domain. To create this environment, the Active Directory Certificate Services server role should be installed on your Active Directory server. When performing the installation, ensure that the Certification Authority Role Service is installed and that "Enterprise" is chosen when specifying the setup type.

Active Directory must be configured with its own X.509 certificate and private key, and the associated CA certificate(s). The CN attribute in the certificate must carry the server's FQDN and match the records in the DNS server. Refer to the available Microsoft documentation for instructions on configuring Active Directory. Ensure the OSM is configured to use the same DNS server as the Active Directory server as described in section 2.2 OVD Server DNS Configuration.

The Certificate Services installation wizard will allow you to create a self-signed CA certificate that can be used for SSL connections to Active Directory. Because the certificate is self-signed and does not use a publicly trusted Certificate Authority, there are further steps involved so that the certificate can be trusted by the OSM. These steps are described in the section below.

If a commercial SSL certificate is used, the certificate must be imported into Active Directory as normal but it should not be necessary to import the certificate into the OSM.

Certificate Export

Once the SSL certificate is available and has been installed in Active Directory, the OSM must be configured to trust the certificate. The first step of this process is to export the certificate as a base-64 encoded X509 file. The file must then be copied to the Session Manager server so that it can be installed.

Session Manager Configuration

Configuring the Session Manager consists of importing the X509 certificate if required and then configuring OVD to use SSL.

Certificate Import

The example below presents the steps to follow for the case where a single CA has been used to create the SSL certificate. This approach can be extrapolated to cases where multiple CAs are involved.

  1. Copy the certificate file exported from Active Directory to the directory /etc/ssl/certs/.
  2. Edit the /etc/ldap/ldap.conf file and add this entry:

    TLS_CACERT /etc/ssl/certs/<ca.cer>

    where ca.cer is the file containing the base-64 encoded certificate that was exported from Active Directory. Then save the file and exit.

  3. Run the following openssl command (change ca.cer to the name of the certificate from step 1):

    openssl x509 -in /etc/ssl/certs/ca.cer -noout -text -subject | sed -n '/subject/s/.*CN=//p'
  4. With the IP and hostname that results from the previous step, do the following:

    1. Edit your /etc/hosts file and add the IP and hostname
    2. Update the resolv.conf file (at /etc/resolvconf/resolv.conf.d/base in Ubuntu) with the DNS server set to the IP of the Active Directory Domain Controller
  5. Restart Apache to apply the changes:

    • Ubuntu:

      service apache2 restart
    • RHEL/CentOS 7:

      service httpd restart

Depending on the version of Linux and the packages installed on the OSM, a reboot of the LDAP service may be required for the TLS_CERT entry to be loaded. It is easiest to perform a reboot of the entire server to ensure it is loaded.

Administration Console Configuration

In the OVD Administration Console (OAC), go to the "Configuration" tab and select "Domain Integration Settings". On this page, select Microsoft from the drop down list.

The SSL settings are listed under the "Server" section. Check the SSL box to enable LDAPs. Then change the TCP port (LDAP Port) from 389 to 636 if you are using the default port.

When setting the hostname (Domain or Primary Host), the value should match the hostname generated by step 3 in section 8.4.1. It must be the FQDN and not just the IP, otherwise the cert will be mismatched and it will not honor the authentication.

Verification steps

After completing the configuration, use the TEST button to perform a configuration check. If the test is successful, the results are annotated in green. If the test has errors, the results are annotated in red. If the results are green, users may login to OVD and will be authenticated by Active Directory using the secure channel.

Problem Determination

Depending on the errors displayed after performing the test, please check the following cases:

Port 636 is not open

To check that port 636 is open, do the following:

  • Windows:

    # netstat -an -p tcp | find "636"

    This should output data similar to the following:

    Proto  Local Address          Foreign Address        State
    TCP                LISTENING
  • Linux:

    # netstat -an4 | grep -i "636"

    This should output data similar to the following:

    tcp       0      0    *               LISTEN

The address denotes that it is listening and allows inbound outboard IPs to accept/receive traffic to port 636. If you have communication issues or disruption it may be due to firewall restrictions either on the server or imposed by an external firewall. Ensure that the external firewall is configured to allow LDAP/LDAP and MS Domain Services.

A further check is to perform a telnet request from the OSM to the Active Directory server using port 636 to ensure that communication can be established.

DNS Issues

Check that the DNS is correctly configured and use the nslookup command to verify that the hostname is correctly resolved.

Also check that the DNS server is correctly configured on the OSM. If the Microsoft Active Directory server is acting as the DNS server, ensure that the OSM DNS server corresponds to the IP address of the Active Directory server.