Download

LDAP Integration Guide

Preface

This document describes how to configure OVD to integrate with an LDAP server.

History

Version Date Comments
1.4 2017-07-18 Updates for 2.5, add Windows 2016 support.
1.3 2017-07-18 Reformatting
1.2 2017-03-06 Updates for OVD 2.3
1.1 2015-12-14 Updates and corrections for OVD 1.4
1.0 2015-05-29 First version

Introduction

This document describes how to configure OVD to integrate with an LDAP server. The guide does not cover the specifics of how to setup and configure an LDAP server.

Overview

Inuvika OVD provides support to integrate with an LDAP server. As a minimum, integration with an LDAP server means that users are defined in the LDAP directory and OVD will delegate user authentication to the LDAP server. OVD will retrieve the list of users from the LDAP server but will not modify the user data. OVD is, by default, pre-configured to use the posixAccount object class to filter the LDAP directory to retrieve the set of users.

The system administrator can further choose whether to define user groups in the LDAP server or in OVD. When defining user groups in LDAP, OVD is pre-configured to use the posixGroup object class to filter the LDAP directory to retrieve the data for user groups.

When integrating with an LDAP server, the "Users" page in the OVD Administration Console (OAC) will always retrieve and display the set of users from the LDAP server independent of whether user groups are defined in LDAP or OVD. The user data cannot be modified within OVD, it must be modified directly in the LDAP server.

Before starting the integration with LDAP, ensure that the schema for filtering users, and user groups if applicable, is known and compatible with OVD. Object classes other than posixAccount and posixGroup may be used but please ensure that the schema chosen is compatible with the mapping configuration capabilities of OVD.

Each of the options is described in more detail below and can be configured in the OVD Administration Console (OAC) by selecting the "LDAP" option of the "Domain Integration Settings" on the "Configuration" tab.

LDAP Configuration

For the purposes of this document, we will use an LDAP server with the following configuration:

  • LDAP server IP address: 10.254.0.161
  • LDAP server distinguished name: dc=demo,dc=inuvika,dc=com
  • read only user account: cn=ovd-ldap, ou=OVD OU, dc=demo,dc=inuvika,dc=com

There is no secondary server available in the example.

When anonymous bind is not allowed, an account with read access to the directory is required. In this example, the corresponding account is cn=ovd-ldap.

OVD configuration

This section describes how to configure OVD so that OVD can access data stored in the LDAP server.

Accessing the LDAP Server

The configuration parameters for the LDAP server are defined as follows:

Primary Host: Enter the FQDN or IP address of the LDAP server. In our example this is 10.254.0.161.

Secondary Host: This parameter is optional and in the example we have there is no secondary LDAP server so this field is empty. If you have a secondary LDAP server, specify the FQDN or IP address here.

Server Port: Port 389 is used by default.

Use SSL: If using SSL to communicate with the LDAP server, tick this box and change the server port accordingly (636 by default).

Base DN: This field is mandatory and must contain the base distinguished name of the LDAP server, in our example dc=demo,dc=inuvika,dc=com. The base DN defines the root of the tree for the data that OVD will retrieve from the LDAP server.

Connection Timeout: This field specifies the timeout value in seconds to be used when connecting to the LDAP directory. This value also applies to Microsoft Active Directory and Novell eDirectory integrations. The default is 15 seconds.

Authentication

Access to the LDAP server can be authenticated either by using an anonymous bind or by defining a user account with read access rights on the LDAP directory tree.

Anonymous bind: if using anonymous bind, select the check box. No further information is required so ensure that the BIND DN and Bind password fields are blank.

Test: at this point, the basic connection parameters can be tested by clicking the Test button at the bottom of the page. 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 error information will be displayed in red. To complete the configuration, refer to the Users and User Groups settings described in the next sections.

User Account Authentication

When using a specific user account to authenticate to the LDAP server, a user with read rights on the directory tree is required. In our example the common name of the user is ovd-ldap.

Anonymous bind : the checkbox must be unchecked when specifying a user.

Bind DN (without suffix): Enter only the DN without the suffix from the Base DN defined for the LDAP server.

Bind password: the password to be used for the user.

Test: at this point, the basic connection parameters can be tested by clicking the Test button at the bottom of the page. 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 error information will be displayed in red. To complete the configuration, refer to the Users and User Groups settings described in the next sections. Without further configuration, OVD will use Internal User groups as the default configuration.

Note

If the user account to be used for accessing the LDAP server is located in a group of users or Organization Unit (OU) such as in our example where we have the ovd-ldap user account located in the OU OVD OU (ou=OVD OU,dc=demo,dc=inuvika,dc=com) then there are two options that can be employed to filter users depending on the requirements:

  • Changing the Bind DN; or
  • Changing the Base DN

Change the Bind DN

In this case, the Bind DN is modified to pinpoint the user to be used for accessing the LDAP server. This method is recommended unless the root must be changed to a specific OU or user group to filter users and other objects.

In our example we have the following:

Base DN: dc=demo,dc=inuvika,dc=com

Bind DN (without suffix): cn=ovd-ldap, ou=OVD OU Which means, OVD will authenticate with LDAP using the following user: cn=ovd-ldap, ou=OVD OU,dc=demo,dc=inuvika,dc=com.

Change the Base DN

This option involves changing the Base DN to filter all the objects from the LDAP directory. The new root will be ou=OVD OU,dc=demo,dc=Inuvika,dc=com and OVD will only retrieve objects and sub content (Users, User Groups and OUs) from within the OU OVD OU. As a result the Bind DN does not require the OU parameter to be specified.

In our example we have the following:

Base DN: ou=OVD OU,dc=demo,dc=inuvika,dc=com

Bind DN (without suffix): cn=ovd-ldap Which means, OVD will authenticate with LDAP using the following user: cn=ovd-ldap, ou=OVD OU,dc=demo,dc=inuvika,dc=com

Users Configuration

The Users section defines how user data is retrieved from the LDAP directory and mapped to user data in OVD. OVD is pre-configured to use the posixAccount object class for user data. The user login must be mapped and the user display name may be mapped if available. These fields are retrieved from the LDAP server and used within OVD for the administration console and user connection. Authentication is delegated to the LDAP server by OVD and so password data remains securely within the LDAP server.

Filter: The name of an object class is required. Enter the name of the object class that is being used for user records in the LDAP server. By default, the posixAccount object class is used but other object classes may be used as long as they fit within the configuration possibilities provided.

Specific OU (optional): this field can be used to filter for users in a specific OU only.

Distinguished name field: this field defines the attribute in the LDAP schema that identifies the distinguished name of the user record. In the posixAccount object class, this is the uid attribute. The data in the LDAP directory is mapped to the user login field in OVD.

Display name field (optional): This field defines the attribute in the LDAP schema that contains the user's display name. The data in the LDAP directory is mapped to the user's display name field in OVD. If not specified, the display name is defined as the value of the login.

Locale field (optional): this field defines the language setting for the OVD client being used to access the system. The format for the locale is the ISO-3166 country code. Normally, the language setting is configured within OVD so that the user can choose the language he wishes to use. If the Administrator wishes to force the language setting through LDAP, it can be done with this setting and also disabling the ability to select the language as a user via the Administration Console.

Persistent UID/GID (optional): this option can be selected if you would like your users to be assigned a specific UID and GID that is defined in the LDAP schema. In this case, when a user connects to an Application Server, OVD will create a user on that server with the UID and GID values specified in the user record in the LDAP schema rather than using values assigned by OVD. Using persistent values for the UID/GID will allow you to manage access to resources based on the defined UIDs/GIDs that have been set in the LDAP directory.

UID: this field defines the attribute in the LDAP schema that contains the user's UID. In the posixAccount object class, this is the uidNumber attribute. This field is ignored unless the Persistent UID/GID option is enabled.

GID: this field defines the attribute in the LDAP schema that contains the user's GID. In the posixAccount object class, this is the gidNumber attribute. This field is ignored unless the Persistent UID/GID option is enabled.

The persistent UID/GID server setting is relevant when using an external data storage entry with an NFS server.

This feature is available for Windows 2016 and Windows 2012R2, but not Windows 2008R2.

To add external data storage entries with NFS protocol see the Data Storage Guide.

User groups configuration

User groups can be defined using either user groups defined in the LDAP directory or defined internally in OVD by selecting the relevant option in the configuration page.

Internal User Groups

This is the default configuration when configuring LDAP integration. In this case, only User data is retrieved from the LDAP directory and User Groups are managed internally within OVD. No other fields need be defined in this section.

Use Internal User Groups: to manage User Groups within OVD rather than in LDAP, select this option.

Test: at this point, the complete configuration can be tested by clicking the Test button at the bottom of the page. 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 error information will be displayed in red.

Once the configuration has been defined and tested successfully, save the definitions using the Save button. Please refer to the Verification Testing section for information on checking that the LDAP system is correctly integrated with OVD.

LDAP User Groups

This configuration should be used when User Groups are defined and managed within the LDAP directory. In this case, User and User Group data are retrieved from the LDAP directory. By default, OVD is configured to use the posixGroup object class but other object classes may be used if they can be mapped using the interface in the Administration Console. The name of the user group as well as a mapping for how members of a user group can be determined must be defined. Optionally, a User Group description field can be defined. The members of a user group can be determined either by specifying how to retrieve the members of a user group or by specifying how to retrieve the user groups that a user belongs to.

Use LDAP User Groups: to use the User Groups defined in the LDAP directory, select this option and complete the remaining configuration items. If the LDAP directory schema is based on the posixGroup object class, the settings should not need to be modified.

Filter: the name of an object class is required. Enter the name of the object class that is being used for the user group records in the LDAP server. By default, the posixGroup object class is used but other object classes may be used as long as they fit within the configuration possibilities provided.

Specific OU (optional): this field can be used to filter for User Group records within a specific OU.

Name field: this field defines the attribute in the schema that identifies the name of the User Group. For the posixGroup object class, this is the cn field. The data in the LDAP directory is mapped to the User Group name in OVD.

Description field (optional): this field defines the attribute, if available, in the LDAP schema that identifies the User Group description. For the posixGroup object class, this is the description field. The data in the LDAP directory is mapped to the User Group description in OVD.

Use the following field from the user entry: select this mapping if the membership of a user group is to be determined by retrieving the user groups that a user belongs to. In addition, choose whether the user groups will be determined by mapping a specific attribute in the user record to the User Group name or by mapping the attribute to the User Group DN. By default, the attribute to use is member and this value may be overridden if not using the posixAccount object class. This field is not enabled by default.

Use the following field from the group entry: select this mapping if the membership of a user group is to be determined by retrieving the members of a user group. In addition, choose whether the members will be determined by mapping a specific attribute in the user group record to the User login name or by mapping the attribute to the User DN. By default, the attribute to use is set to memberUID and this value may be overridden if not using the posixGroup object class. This mapping is enabled by default.

Note

Do not specify both Use the following field from the user entry and Use the following field from the group entry.

Once the configuration has been defined and tested successfully, save the definitions using the Save button. Please refer to the Verification Testing section for information on checking that the LDAP system is correctly integrated with OVD.

Verification Testing

To test whether the configuration is correct and OVD does retrieve the expected data, go to the "Users" tab in the OVD Administration Console to display the list of users. Verify that the list of users displayed matches the data in the LDAP directory. The number of records displayed can be modified temporarily by changing the Maximum items per page parameter in the "System Settings" page under the "Configuration" tab.

Try adding a new user in the LDAP directory and verify that the user is listed in OVD.

If User Groups are being managed in the LDAP server, also verify that the list of User Groups is correct. Go to the "User Groups" page in the "Users" tab and verify the list displayed. Also, verify that the User Group contains the correct Users by spot checking a number of User Groups and Users.

Try adding a User to a User Group on the LDAP server and ensure that the data is reflected in OVD.

Correct any errors by modifying the configuration parameters accordingly. Once the data has been verified then OVD is correctly configured for use with an LDAP server.