Microsoft Active Directory Integration Guide

Last updated on Aug 27 2024.

Preface

This document describes how to integrate Inuvika OVD Enterprise with Microsoft Active Directory Server.

Introduction

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 Enterprise. A section describing the implementation steps for providing secure access to the Active Directory server is also included.

Overview

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.

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 "Users" tab. A further section describes the steps for implementing secure data transmission.

DNS configuration

When your Active Directory server acts as a DNS server on your domain, Inuvika recommends that it is also configured on the OVD Session Manager host as a primary DNS server. This facilitates the integration of OVD and Active Directory.

Microsoft Active Directory Setup

The Microsoft Active Directory used in this document is running on either Windows 2016 or 2012 R2. It is also configured in compatibility mode to ensure members that join the domain can be running any version of Windows starting from Windows 2012 R2.

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.

Firewall and Ports

OVD requires several ports to be open in order to interact with Active Directory. Although specific commands are provided in Firewall Configuration, IT Administrators should review and verify all necessary firewall rules in order to prevent possible service disruptions.

OVD Session Manager

• Outgoing traffic

  • TCP 389 (LDAP) or TCP 636 (LDAPS) or TCP 3268 (LDAP Global Catalog) or TCP 3269 (LDAPS Global Catalog) for communication with the Active Directory server using the LDAP protocol.

    Please refer to Advanced Configuration Options and Microsoft Active Directory With Multiple Domains for more information regarding which port to choose.

  • TCP 445 (SMB): for communication with the Active Directory server using the SMB protocol.

    This is required when using the SMB password change method. Refer to Users Password for more information.

  • TCP/UDP 88 and TCP/UDP 464: for communication with the Active Directory server using the Kerberos protocol.

    This is required when using the Kerberos password change method. Refer to Users Password for more information.

    This is also required when configuring the Active Directory SSO using Kerberos.

SELinux Configuration (RHEL only)

Important

This configuration only applies to SELinux enabled systems. For more information please refer to section in Installation and Configuration Guide: Security-Enhanced Linux

On OVD Session Maganager:

1. allow Apache to connect to an Active Directory server:

   setsetbool -P httpd_can_connect_ldap=1

2. allow password change through AD/LDAP server:

   setsebool -P nis_enabled=1

Configuring OVD to Use Active Directory

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

Enter the following information relevant to your configuration.

Domain: enter the Active Directory Domain Name. In the example, this is domain.test.demo

Special considerations for Multi-Tenant configuration

Tenant domain must match the AD domain.

For more information, please refer to the Domain Name and service access point section from the Multi-Tenant Guide.

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 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 for Active Directory using the advanced options:

LDAP port: The default ports are 389 for regular communication or 636 when using LDAP over SSL. A different port may be used corresponding to the port defined on the Active Directory server.

Encryption: Define the encryption mechanism used to secure ldap connections. Possible values are:

• None (default): LDAP connection is not encrypted.

• StartTLS: LDAP connections use the default ldap port to open a secure session with the ldap server.

• LDAP over SSL: LDAP connections use a port dedicated to a secure channel. The standard port for ldaps is 636.

Additional requirements for encryption

Configuring transport encryption requires extra configuration that is documented in the Configuring Transport Encryption with Active Directory section.

Password change method: Define the method used to change user passwords. Please refer to the section Users Password for more information.

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 and LDAP integrations.

Microsoft Active Directory With Multiple Domains

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

Domain: the Active Directory Forest Name (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. Or you can also use the gc._msdcs.<DnsForestName> DNS entry. 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 default ports are 3268 for regular communication or 3269 when using LDAP over SSL.

Users

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.

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 "System" tab in the OAC.

Active Directory provides several forms of login names for a user:

• sAMAccountName: this is the historical Windows login, limited to 20 characters

• Full sAMAccountName: this form prefixes the login with the netbios domain. Ex: DOMAIN\john.

• userPrincipalName: this form suffixes the login with the DNS domain. Ex: john@domain.local

Users can login to OVD using any of these 3 formats. The first form, samAccountName, is typically the default format used as it is the easiest.

Please note that the login portion of a user's userPrincipalName (UPN) can differ from the sAMAccountName. Ex: for a user DOMAIN\john, the UPN can be jack@domain.local.

In order to deal with cases like this both forms of names are displayed in the OVD Administration Console when listing users.

Multi-Domain and Login Duplication

When using a forest or federated domains, it is possible that the same user login exists in multiple domains. Due to this the safest type of login names is one that includes a form of domain.

In such cases where a user attempts to login but there are multiple users with their specific login, OVD will attempt authentication for each user sequentially until one matches (replicating Windows identification and authentication behavior).

Users Password

Users have the ability to change their password if the administrator authorizes the action (enabled by default). This action is done using the OVD User Configuration.

When using Active Directory integration, OVD will update the user passwords in the Active Directory.

The firewall must be configured to ensure that the OSM can comnmunicate with the Active Directory for password change requests. Refer to Firewall and Ports for more information.

SMB Method

This method uses anonymous requests to communicate with the Active Directory. These requests are allowed by default on Active Directory.

Kerberos Method

This password change method is an alternative when the SMB method can not be used. For instance, when Active Directory is configured to block anonymous requests used by SMB, the Kerberos method can be used since it uses authenticated requests.

Additional requirements

The Kerberos method requires additional configuration. Configure the Session Manager server to synchronize the time with the Domain Controller. Refer to Time Synchronization for more information.

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:

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.

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:

Nested groups, also known as "child groups"

Active Directory supports nested groups. Group nesting is when one group is added as a member of another group. This gives the first group all the permissions of the parent group it's been added to.

OVD provides several ways to handle nested groups:

1. Disabled: no nested groups will be retrieved, so OVD will only see users as being members of “first level” group.

2. Enabled (default): nested groups are retrieved, so OVD will see users as being members of all their group recursively.

3. Enabled (alternative method): this option is similar to the second option (above), but the recursive process of retrieving groups is done by OVD instead of the AD.

   This option is useful for when the AD is not indexed properly as OVD software will process the groups faster than the AD.

   Important: If this is the case in your infrastructure, you should investigate the reason. This setting should not be used in a production environment.

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.

User Session Configuration

When connecting with Active Directory, OVD provides multiple ways to integrate OVD user sessions with the Active Directory infrastructure. This includes whether to use domain users or local users and whether to rely on OVD or Active Directory for user profile storage and management.

When OVD manages user sessions, Domain users are not used and OVD provisions temporary local users on the OAS:

• 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.

Full OVD integration

In this integration mode, OVD will manage user profiles and shared folders using the OFS, as well as creating users on the relevant application servers.

• OVD manages user data persistency through the use of the OFS, which provides centralized Linux and Windows profile data management.

• Active Directory is used for user authentication and, optionally, for user groups. Other Active Directory services are not supported in OVD (ex: GPOs, network shares, application and printer publishing).

• Windows OAS servers can be members of an Active Directory domain or simply running in a WORKGROUP.

Hybrid integration

This mode allows for a hybrid approach using Active Directory native users with OVD's profile management.

This mode should be used instead of "Full OVD" mode when:

• Native AD users are required along with other AD services (GPO, password save, network shares, applications, and printer publishing)

This mode should be used instead of "Full AD" mode when:

• Both Linux and Windows applications are required
• Your AD infrastructure does not have Roaming Profiles setup or, if they are setup, they do not perform well

Important

If a roaming profile is available and configured for a domain user, the following GPO must be enabled to prevent roaming profiles loading when the OVD session starts:

Computer Configuration
  → Administrative Templates
    → System
      → User Profiles
        → Only allow local user profiles

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

This mode adds the option Profile cache. Enabling this option will result in caching the profile on the Application Server when the session is ended. This behavior is the default when using native sessions with Active Directory users.

Full Active Directory integration

In this integration mode, users are managed entirely in Active Directory and the OFS is not used for user profiles or shared folders. Linux Application Servers can be used without profiles.

• 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, applications, and printer publishing.

See Active Directory Recommended Configuration for further information on how to setup OVD in a Full Active Directory environment.

Windows 10/11 Enterprise/Pro support (OVD Application Server role)

When using Windows 10 or 11 as an OVD Application Server, Full Active Directory integration requires an additional GPO. It will configure OvdShell as the default shell of the Application Server.

To activate this support, open Group Policy Management and apply to all workstations a registry GPO with the following parameters:

Hive:       HKEY_CURRENT_USER
Key path:   SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value name: shell
Value type: REG_SZ
Value data: Ovdshell.exe

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.

Then select the domain object / View / Advanced Features

Now select domain object / properties

Now click the Advanced button

Click Add and select the user account.

Select the Properties tab:

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

Click OK and save all changes.

Active Directory Recommended Configuration

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.

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

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 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 10 system may be overwritten by Windows Server registry settings. With this policy set to Replace this problem will not occur.

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.

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 configuration mode, additional configuration is required.

The OVDDesktop.exe and OVDRemoteApps.exe applications must be allowed to start as initial program in the Remote Desktop session. This must configured for each OAS Windows server, via the Server Manager or with the GPO named Allow remote start of unlisted programs:

Computer Configuration
  → Administrative Templates
    → Windows Components
      → Remote Desktop Services
        → Remote Desktop Session Host
          → Connections
            → Allow remote start of unlisted programs

These Inuvika system applications also need to be published in the RemoteApp Manager. But this configuration is already applied by the Inuvika OVD Enterprise installer.

For troubleshooting purposes, you may wish to double check the configuration. Remote Apps management is available in the Server Manager.

Configuring Transport Encryption with Active Directory

The OVD Session Manager uses LDAP to communicate with Active Directory.

By default, LDAP communication between client and server applications is not encrypted.

Enabling a secure TLS/SSL communication channel requires extra configuration on the OVD Session Manager host and may require changes on your Active Directory server if it is not already configured for TLS/SSL.

Issue and install a certificate on Active Directory

Detailing the process of issuing a certificate for Active Directory is beyond the scope of this documentation. Please refer to the Microsoft's documentation for detailed instructions.

Your Active Directory server might already be configured with encryption. In which case, you can switch to the next section.

Please pay extra attention at the following point regarding certificate's requirement:

• The certificate's Common Name (CN) field must be in the <server_hostname>.<ad_domain> form.

• Alternative access points (names and IP addresses) can be configured with the Subject Alternative Name (SAN) extension. When doing so, it is required that the first entry remains the same as the Subject CN (<server_hostname>.<ad_domain>).

• The certificate requires the Extended Key Usage OID 1.3.6.1.5.5.7.3.1, also known as serverAuth.

Note

Active Directory will automatically use any installed certificate for LDAP that matches its requirement. No reboot is required.

When using "AD-CS" in "Enterprise Role", a certificate is automatically generated.

Configure the Session Manager to trust the Active Directory certificate

Once your Active Directory server is configured with a certificate, you must update the OSM configuration to "trust" this certificate.

1. Import the CA certificate that signed your AD certificate into the OSM as /etc/ssl/certs/ovd-ldap.pem

   • When using intermediary CA certificate(s), each intermediate certificate, plus the CA certificate, must be concatenated in a single PEM file in this exact order:

     • Intermediary CA certificate Level n
     • Intermediary CA certificate Level 2
     • Intermediary CA certificate Level 1
     • CA Certificate

2. Make sure the configuration file is accessible by OVD

   chmod  +r /etc/ssl/certs/ovd-ldap.pem

3. Edit the LDAP configuration file

   • Ubuntu LTS: /etc/ldap/ldap.conf

   • RHEL: /etc/openldap/ldap.conf

4. Add the following line

   TLS_CACERT /etc/ssl/certs/ovd-ldap.pem

   Note

   Certificate verification can be disabled for test purposes:

   # TLS_CACERT TLS_CACERT /etc/ssl/certs/ovd-ldap.pem
   TLS_REQCERT never

   This option is not secure and not recommended for production. It should only be used when setting up a prototype as a temporary workaround.

5. Restart Apache to apply the changes:

   • Ubuntu LTS:

     systemctl restart apache2

   • RHEL:

     systemctl restart httpd

Name resolution

When using names and not IP addresses to identify the Active Directory server (related to the certificate fields), it is required that the OVD Session Manager is able to resolve the name. This can be done by using a DNS server or by adding an entry in /etc/hosts.

Multi-Tenant, multi-Forest or multiple LDAP servers

When using OVD as a multi-tenant environment, you may have more than one LDAP / Active Directory to configure for encryption.

In this case, simply concatenate the CA certificate and Intermediate CA certificates of each LDAP / Active Directory server into the /etc/ssl/certs/ovd-ldap.pem file.

Apply the change in the OVD configuration

Back in the OVD Administration Console, configure Configuring OVD to Use Active Directory with encryption:

1. Primary Host: FQDN of the Active Directory server that is defined in the certificate.

2. Enable the Encryption by selecting either the "StartTLS" or "LDAP over SSL" option

   Note

   When both encryption methods are available on your Active Directory server, it is recommended to use StartTLS.

3. Use the Test button to perform a configuration check.

4. If, and only if, the check passes (no red annotations shown), click the Save button

All LDAP traffic between the OVD Session Manager and the Active Directory server will now use a secure communication channel.

Troubleshooting

The following sub-sections provide different ways of troubleshooting communication issues with your Active Directory server.

When using encryption, it is recommended to first validate communication without encryption.

Check the LDAP configuration in command line

The ldapsearch utility is a very efficient way to troubleshoot broken LDAP access and / or configuration issues.

ldapsearch is provided by the ldap-utils package on Ubuntu LTS and openldap-clients on RHEL.

When detecting an LDAP communication problem, the Session Manager issues a customized ldapsearch command line in the OSM logs. These command lines can be copied from the logs and run verbatim to help the administrator identify the issue.

Check connectivity with LDAP host

A common problem while configuring LDAP is TCP/IP connectivity issues.

This check should be run on the OSM node itself for best results.

1. When using a host name instead of an IP, ensure the name can be resolved using getent hosts or ping.

2. Check the IP level connectivity with ping.

3. Check the TCP level connectivity with telnet (port 389 or 636).

4. When using encryption, you can use the openssl command to verify the configuration of your LDAP server:

   • StartTLS

     openssl s_client -connect FQDN:389 -starttls ldap

   • LDAP over SSL

     openssl s_client -connect FQDN:636

Time Synchronization

The Domain Controller should be configured as the local network's time server (NTP server). Configure the Session Manager server to synchronize with the Domain Controller, and the Domain Controller to synchronize each hour against a reliable outside source.

Make sure the clock time of the Domain Controller, the client workstation and Session Manager server are in sync. If the time difference is greater than five minutes, Kerberos may not work correctly.

NTPD is a Linux software service to synchronize the time over the network using NTP (Network Time Protocol). This package should be installed and configured on the Session Manager server.

1. Install the ntp package and stop the service in case it is running:

   • For Ubuntu

     • Install the ntp package

       apt install ntp

     • Stop the ntp service

       systemctl stop ntp

2. Synchronize the time by using the following command:

   ntpdate dc.test.demo

3. Open the /etc/ntp.conf file

   1. comment all the lines starting with server

      # more information
      #server 0.ubuntu.pool.ntp.org
      #server 1.ubuntu.pool.ntp.org
      #server 2.ubuntu.pool.ntp.org
      #server 3.ubuntu.pool.ntp.org
      #Use Ubuntu's ntp server as a fallback
      #server ntp.ubuntu.com

   2. then set the Domain Controller as the ntp server

      server dc.test.demo

   3. Restart the service

      • For Ubuntu

        systemctl start ntp

Firewall Configuration

For more detailed firewall configuration, please refer to the Firewall and Ports.

Follow the instructions below to configure default firewalls on the Session Manager.

• If using UFW (default firewall for Ubuntu):

  • Open the LDAP port for outbound traffic:

    ufw allow out 389/tcp

    Important

    If you use a different port for communicating with your LDAP server, replace 389 with the port you are using.

    For insance, when using the legacy LDAP over SSL encryption, the port to use is 636.

    Please refer to Advanced Configuration Options for more information regarding which port to choose.

  • Open port 445/TCP for outbound traffic:

    ufw allow out 445/tcp

  • Open port 88/TCP-UDP for outbound traffic:

    ufw allow out 88

  • Open port 464/TCP-UDP for outbound traffic:

    ufw allow out 464