Deployment Strategies of an EMC Documentum … Strategies of an EMC Documentum Content Server Integration with LDAP Applied Technology Abstract This white paper provides a …

Deployment Strategies of an EMC Documentum Content Server

Integration with LDAP Applied Technology

Abstract

This white paper provides a high-level overview of how EMC® Documentum® Content Server provides out-of-the-box support to LDAP servers from different vendors.

October 2008

Copyright © 2008 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com

All other trademarks used herein are the property of their respective owners.

Part Number h5638.1

Deployment Strategies of an EMC Documentum Content Server Integration with LDAP Applied Technology 2

Table of Contents Executive summary ............................................................................................4 Introduction.........................................................................................................4

Scope........................................................................................................................................... 5 Audience ...................................................................................................................................... 5

Overall architecture ............................................................................................5 Scenario 1: LDAP server with an unfederated repository............................................................ 6 Scenario 2: LDAP server with a federated repository.................................................................. 6

Configuration ......................................................................................................8 Configuring LDAP ........................................................................................................................ 8 Configuring synchronization and authentication rules ................................................................. 9 Configuring mapping rules ......................................................................................................... 10 Configuring attribute mapping.................................................................................................... 11 Configuring failovers .................................................................................................................. 12

Scenario 1: When the primary LDAP server is down............................................................. 12 Scenario 2: When the secondary server goes down within the failover usage interval ........ 12

Conclusion ........................................................................................................13


Executive summary With the advent of directory services technology, directory servers have become a centrally located up-to-date store for managing and maintaining user and group information such as phone books, encryption certificates, pointers, and single sign-on information. This revolution has led to the requirement of integrating Lightweight Directory Access Protocol (LDAP) servers with EMC® Documentum® Content Servers, thus reducing many overheads for administrators in managing user and group information. This white paper gives a high-level overview of how Content Server provides out-of-the-box support for LDAP servers of different vendors. It also illustrates different options and limitations laid by the Content Server during the configuration and synchronization process with LDAP servers. By taking a simple deployment scenario, it shows how a hierarchical tree structure of data in an LDAP server maps to the attributes of user and group objects in the Documentum repository, and how the authentication framework authenticates LDAP-based users.

Introduction These days, it is a common scenario in small, medium, and large-scale organizations to store information shared by multiple applications in a centralized location such as directory servers. The LDAP-compliant directory server is an ideal choice for data storage and retrieval due to the following reasons:

• An LDAP server is read optimized and stores information in a structured fashion. • Information stored by LDAP server can be managed easily. • An LDAP server provides a standard way to access the information, so that multiple instances of same

or different applications can share the information. Organizations are using LDAP-compliant directory servers for different services such as white pages service, employee information and infrastructure directory service, and authentication service.

Directory servers are widely used for back-end authentication across enterprise-wide applications, as they are simple and effective. As directory servers are a popular choice for enterprise-wide applications, Documentum provides support for the integration of Documentum Content Server with LDAP-compliant directory server infrastructures. The integration of Documentum Content Server with the LDAP server setup allows the use of the existing infrastructure for the creating and updating of user and group objects by synchronization. Hence, it makes the life of a Documentum repository administrator easy.

Figure 1. A directory server setup integrated with enterprise-wide applications


The terms Content Server and Repository have been used interchangeably depending on the context.

The paper has been organized into two sections. The section “Overall architecture” that starts on this page gives a brief idea about the overall integration architecture. The section “Configuration” on page 8 discusses configuring synchronization of user and group objects, and managing synchronized user and group objects. It also gives an insight into how the synchronized user and group objects will be leveraged during the authentication process.

Scope This white paper describes the back-end data processing that occurs during the integration and post-integration processes, thereby providing an insight into the capabilities and limitations of the Documentum Content Server. This white paper endeavors to strike a balance between the EMC Documentum System Object Reference Manual, EMC Documentum Content Server Administration Guide, and EMC Documentum Administrator User Guide, so that one can get a grasp of the functionality provided by the LDAP Server Integration Infrastructure of the Documentum Content Server, without dwelling into details. Therefore, this paper helps administrators to acquaint themselves of the process of integrating the LDAP-compliant directory server infrastructure with Content Server.

This paper assumes that the reader has a prior knowledge of LDAP server and Documentum repository administration. Further, this paper does not explain the procedure for integrating LDAP servers with Documentum Content Server. EMC Documentum Administrator User Guide and EMC Documentum Content Server Administration Guide provide information on how to configure and maintain LDAP configuration.

Audience This white paper is mainly intended for Documentum repository administrators who intend to integrate an existing directory infrastructure with Documentum Content Server.

Overall architecture This section describes the overall architecture of LDAP servers’ integration with a Documentum repository.

LDAP servers are widely used across enterprise applications for verifying user login credentials. The main driver behind the introduction of the LDAP integration feature in Documentum Content Server is to enable the use of the user information stored in the centralized user registry on the directory server. When a user tries to log in to a directory-enabled client application such as a Documentum repository, the client application performs a bind operation against the LDAP server using the login credentials provided by the user. The success of the bind operation determines whether the authentication is successful or not. This is the common underlying principle for applications that use directory server infrastructure for providing authentication across enterprise applications. The LDAP integration with Documentum Content Server feature has been built on the same principle described in this section. The details of the feature design are mentioned in the following sections.

The Documentum repository requires an object of type dm_ldap_config to be created for every LDAP server that needs to be integrated with the Content Server. This LDAP config object holds all the information required to contact, search, and fetch the data from the LDAP server. The “Configuration” section on page 8 discusses various options that are available while creating a valid configuration object. These options that are configured during the configuration process determine how the integration via synchronization takes place.

Depending on the size of the organization and its requirements, the repositories can be configured in many different ways. Depending on the requirements, an organization can go for either a single repository or a group of repositories configured in a federated mode. The following scenarios describe the basic


architecture of the integration of LDAP servers with a single repository or a group of repositories in a federated mode.

Scenario 1: LDAP server with an unfederated repository Let us consider a scenario wherein an organization has a single Documentum repository, and an LDAP server setup containing a primary server configured with two secondary servers. Generally, the LDAP servers are set up for failover; therefore, the secondary servers start functioning when the primary server is down. The “Configuration” section has details on how to configure secondary LDAP servers for a primary server. Figure 2 depicts the overall architecture of integrating an LDAP server with a single repository.

Figure 2. Architectural view of an LDAP server integration with an unfederated repository As shown in Figure 2, the LDAP-Documentum repository synchronization process is initiated as soon as the valid configuration object has been created. This process syncs up the repository with the LDAP server, by creating dm_user and dm_group objects for all the users and groups found in the LDAP server based on the configured options in the dm_ldap_config object. The LDAP password checking process authenticates when the user who has been synced tries to log in. The failover servers are used only for authentication, if primary servers are not available.

Scenario 2: LDAP server with a federated repository Let us consider another scenario where a large organization has an LDAP server setup and more than one repository configured in the federated mode. In such a scenario, as shown in Figure 3, only the governing repository is synchronized using the LDAP Documentum repository synchronization process. The federation update job mechanism is in turn responsible for syncing up the newly created user and group objects or propagating changes to the objects in the member repositories. The member repositories authenticate the LDAP synced-up user independently without involving the governing repository. Hence,


every member repository requires a copy of the valid LDAP configuration objects to successfully authenticate a user associated with the corresponding LDAP server.

Figure 3. Architectural view of an LDAP server integration with a federated repository Alternatively, as shown in Figure 4, when the member repositories are at different physical locations, the member repositories can point to the nearest replicated LDAP server, if any are available.

Figure 4. Architectural view of an LDAP server integration with a federated repository and member repository integrated with a replicated LDAP server


Configuration The Content Server requires dm_user and dm_group objects to be created for every user or group that accesses the Documentum repository as the Content Server uses the corresponding objects for authentication purposes. The configuration process involves the creation of an object of type dm_ldap_config, for every directory server to be integrated with the Content Server. The Content Server supports integration of multiple LDAP servers at the same time. It is during the configuration phase that one has to analyze how the existing directory server setup has been configured; analyze how its schema, namespace, and topology have been defined; and formulate an approach to integrate with the Content Server. It is highly recommended to use Documentum Administrator for creating LDAP configuration objects.

The decision-making process during the LDAP configuration has been divided into four phases, which are described in the following sections:

• “Configuring LDAP” on this page • “Configuring synchronization and authentication rules” on page 9 • “Configuring attribute mapping” on page 11 • “Configuring failovers” on page 12

Configuring LDAP This is the first phase of the LDAP configuration process. During this phase the user provides the connection details of the LDAP directory server, which will be used during the synchronization and authentication processes. The following pointers need to be considered while configuring the basic LDAP information:

• Providing a unique name to an LDAP configuration object One needs to provide a unique name to an LDAP configuration object, such that no two primaries or failover LDAP severs have the same name. The uniqueness of an object name not only helps to uniquely identify the configuration object, but also to uniquely identify the user objects. One example is when two users’ entries exist in two different directory servers with the same common name. The config object name that is stored as a domain for every user synced up from the directory server to Content Server is used to uniquely identify the user. Let us consider a scenario where the sales and engineering departments of an organization have their user information stored in two different directory servers and both departments have users named “Mark.” If both departments need to access the Content Server, the corresponding directory servers have to be integrated and synced up with the Content Server. During this integration process with the Content Server, a conflict would arise when two user objects have to be created with the same name Mark (as the Content Server requires user names to be unique). In such a situation, the name of the LDAP server config that is stored as domain in a user object is used to uniquely identify the user, whether it is the Mark belonging to the sales department or the Mark belonging to the engineering department.

• Enabling the LDAP configuration object The LDAP server needs to be enabled to synchronize it with the repository. One can choose to enable the LDAP server either at the time of creation or after the successful creation of the LDAP config object. The LDAP configuration object needs to be enabled to successfully synchronize the corresponding LDAP server with the repository and to successfully authenticate the LDAP synchronized user.

• Selecting the type of LDAP server to integrate with Documentum Content Server Currently, Documentum Content Server provides out-of-box support for the following six LDAP servers: Active Directory Server ADAM (Active Directory in Application Mode) Oracle Directory Server


Sun One/iPlanet Directory Server IBM Tivoli Directory Server Novell Directory Server

• Specifying the directory server IP address, port number, Binding Distinguished name, and password used The Distinguished Name (DN) has to be specified such that the Binding Distinguished account has all the rights on the LDAP server to view all the user and group accounts that are planned to be synchronized to the Content Server.

• Configuring the directory server for secure mode Content Server provides support for Secure Socket Layer (SSL) connectivity with the directory server when the LDAP server is configured for LDAP SSL. Currently, Documentum Content Server supports only server SSL authentication.

Configuring synchronization and authentication rules Synchronization and authentication options have to be configured after the basic LDAP information has been configured. The synchronization and authentication options are used during LDAP Documentum repository synchronization and authentication. During the configuration of synchronization and authentication rules, decisions regarding what needs to be synchronized and how the synchronization should happen need to be taken. The LDAP Documentum repository synchronization process is a one-way synchronization process, which synchronizes all the changes from the LDAP server to the repository. Configuring synchronization and authentication rules involves the following steps:

• Choosing the import type Depending on the requirement you can choose one of the following three options: User synchronization

User synchronization involves importing only the user entries present in the LDAP server and creating objects of type dm_user for the imported user entries.

User and group synchronization User and group synchronization involves importing both user and group objects from the LDAP server to the repository.

Groups and member users synchronization Synchronization of groups and its member users involves importing all the group entries from the LDAP server. During this process, it first checks whether a member user of the group is present already in the Documentum repository or not. In case the member user of the group is not present in the Documentum repository, a corresponding user entry is imported to the Documentum repository. Although the user and group synchronization option suits all kinds of scenarios, the other two options can be used in the following specialized scenarios:

o If there are few Documentum users across the different departments of an organization then one can opt for synchronizing groups and member. This can be achieved by creating a Documentum group for each department. The Documentum group should contain references to Documentum users.

o User synchronization can be opted in scenarios where the users have not been separated into different groups.

• Selecting the synchronization type The synchronization can be either in full or incremental fashion. The LDAP Documentum repository synchronization process is usually a job that is scheduled to run periodically to update the repository of the entry changes made in the LDAP server. When the full synchronization option is chosen, all the user and groups will be synchronized from the LDAP server. When the synchronization job is initiated for the first time, the full synchronization is done. When the incremental synchronization option is


chosen, then only the changes made in the LDAP server will be synchronized. The changes can be one of the following Addition / Modification / Deletion of Users Addition / Modification / Deletion of Groups Addition / Modification / Deletion of members in a group

• Various other synchronization options are available that allow one to configure the deleted, renamed users and groups in the LDAP server. The Documentum Content Server does not allow the deletion of users from the repository. Hence, when the LDAP synchronized repository user has been deleted from the LDAP server, then you can either choose to inactivate that particular user’s state or not the change the user’s state in the repository. If the synchronized user or group has been renamed, then you can either choose to rename or retain the repository object name.

• Authentication options such as “Use DN stored in the user object” and “Search the DN based on the user login name for authentication” can be configured here.

Configuring mapping rules The LDAP server’s namespace is hierarchical. In the LDAP server the data is organized in the form of a tree structure known as the Directory Information Tree (DIT). The Documentum repository objects’ namespace is flat. The mapping rules determine which users and groups need to be synchronized with the repository’s namespace.

• Configuring the user and group object class The user and group object class determine which of the user and group entries in the LDAP server are imported into the Documentum repository during the LDAP Documentum repository synchronization process.

• Configuring the user and group search base The search base determines the scope of the DIT in which the LDAP Documentum repository synchronization process looks for user and group entries.

• Configuring the user and group search filter The search filter as the name suggests is used to further place the constraints on the search scope of the DIT. Depending on the requirement, the search filter can be effectively used to filter the entries. Let’s take a scenario in which all the users in the organization are grouped together and only some of the grouped users need to be synchronized with the repository. This scenario is depicted in Figure 5. In this scenario, one can effectively use a search filter to look for entries in the LDAP server by adding a special attribute called “user_type”, with a value of “Documentum” to the user entries.


Figure 5. Mapping between an LDAP hierarchical namespace to a flat object namespace

Configuring attribute mapping Configuring attribute mapping is the most important task under configuring mapping rules. Although configuring the object class, search base, and search filter determine the part of DIT to be searched and which user and group entries need to be imported, it is the attribute mapping that plays a key role in mapping hierarchical organized data into a flat object namespace. It has to be done carefully because the repository places a lot of constraints on what value each attribute holds. One of the common problems while mapping the user entries from the tree structured namespace to flat object namespace is that two different entries bear the same name. For example, let’s consider a scenario where an organization has two employees named Mark, one working for an engineering department and the other working for a marketing department. In the LDAP server it does not pose a problem as long as they have been placed in DIT, such that every entry has a unique DN, as shown in Figure 5. But if one wanted to synchronize both departments to a Documentum repository, then attribute mapping has to be done cleverly such that it does not break the repository placed constraints such as:

• All the following mandatory attributes should be mapped to non-null values: Mandatory user attributes

o user_name

o user_login_name

o user_address

Mandatory group attributes o group_name

• The user_name attribute must be mapped to a LDAP attribute having a unique value. • If the repository is configured in domain required mode, then the combination of user_login_name and

user_login_domain has to be unique, or else the user_login_name must be unique. An attribute mapping configuration even allows to map a combination of two different ldap attributes to a single dm_user/dm_group attribute. Different organizations have different naming conventions such as using a combination of last name and given name to uniquely identify a user. Such situations can be handled by mapping attributes such as dm_user.user_name to a combination of first name and last name.


For optional attributes of a dm_user/dm_group object, the attribute mappings allow you to configure the rejection rule in case the mapped LDAP attribute is either empty or does not have sufficient characters. The rejection rule can be any of the following three options:

• Never reject any user or group • Reject a user or group entry if the mapped attribute is empty • Reject a user or group entry if the mapped entry is either empty or does not have sufficient characters Apart from these constraints the following rules will be used while mapping:

• There are no spaces required between different mapped values due to the bracket delimiters. If there is a space between the mapped values, it will be reflected in the result.

• The only limit to the number of LDAP attributes that can be mapped into one Documentum attribute stems from the length of the constant-field in the repository, which is 64 characters.

• Standard Documentum attribute length limitations are still applicable – for example, the substituted string for user_name must be less than 32 characters.

• A number can be included at the end of the LDAP attribute name. This number would then determine the length of the substring (max length) of the substituted value.

Configuring failovers The Documentum repository requires the enabled LDAP servers to be up and running always as the repository contacts the LDAP server each time an LDAP synced-up user tries to log in. The primary server may not be available at all times due to unavailability of the network, unavailability of the directory server, or administrative reasons such as maintenance and so on. The failover server or the secondary servers come into the picture when the primary servers are not available and they provide the same service as the primary server. The failover servers are mainly intended to serve the authentication failovers and not the failover during synchronization. Configuring failovers allows attaching one or more secondary servers to the primary LDAP server. You can configure failover parameters such as usage interval, retry interval, and retry count. The retry count specifies the number of times a repository tries to bind to an LDAP server before reporting connectivity failure. The retry interval (in seconds) specifies the time interval between retries. The usage interval specifies the number of seconds the failover server will be used before contacting the primary server. The failover parameters apply for all the failover servers, that is, every failover server configured for a primary will use the same values. The failover feature is better understood by analyzing the following two scenarios.

Scenario 1: When the primary LDAP server is down When the primary LDAP server is down then the repository tries to contact the primary LDAP server (for authentication). The number of times the repository’s authentication service tries to contact the primary LDAP server and the length of the retry interval is determined by the failover configuration settings. If the authentication service succeeds in contacting the primary LDAP server, then the repository uses the primary LDAP server for authentication or else the repository tries to contact and use one of the secondary servers that have been configured for failover. If none of the secondary servers have been configured, then the repository reports authentication failure.

Scenario 2: When the secondary server goes down within the failover usage interval Let us consider a scenario with the following criteria:

• A primary LDAP server has been configured with two failovers, F1 and F2. • The repository uses F1 when the primary server is down. • The failover usage interval is 600 seconds. • The primary server goes down.


• The repositories use the F1 server for 300 seconds and then the F1 server goes down. In such a scenario, the repository would then contact the F2 server and use it for the remaining 300 available seconds before contacting the primary server.

Conclusion LDAP server integration is critical to any successful deployment of a Documentum Content Server setup. The first step in LDAP server integration is the creation of a dm_ldap_config object for a directory server that needs to be integrated with the Content Server. EMC highly recommends to use Documentum Administrator for creating LDAP configuration objects. During the configuration phase the administrator needs to provide the connection details of the LDAP directory server, which will be used during the synchronization and authentication processes. The administrator also needs to define synchronization and authentication rules, attribute mapping rules, and configure the failover server. The failover server or the secondary server can be configured by defining the failover parameters such as usage interval, retry interval, and retry count. This brief overview starting from architecture to configuration options used in the synchronization and authentication process is aimed to smoothen the process of integration of Documentum Content Server with LDAPs.


Documents

Deployment Strategies of an EMC Documentum … Strategies of an EMC Documentum Content Server Integration with LDAP Applied Technology Abstract This white paper provides a …