New in D6 Platform: LDAP Integration Enhancements

Documentum can use an LDAP directory as a source of users and groups as well as a server for authenticating users. D6 has enhanced the capabilities for using LDAP servers with Documentum in the following ways:

Support for Additional LDAP Vendors

In version 5.3 Content Server supported the following LDAP servers:

• Microsoft Windows Server 2003 Active Directory
• Oracle Internet Directory
• Sun Java System Directory Server

D6 extends the LDAP support to the following servers:

• IBM Tivoli Directory Server
• Novell eDirectory
• Microsoft ADAM (Active Directory Application Mode)

Robust LDAP Authentication

D6 makes LDAP authentication support more robust by adding the ability to retry connection attempts and the ability to use secondary LDAP servers for failover, when the primary LDAP server is not available. These capabilities are described later.

Flexible LDAP Attribute Mapping

D6 also enhances the flexibility in using LDAP as a source for users and groups by enabling mapping of multiple LDAP attributes to one property and the ability to use expressions to define the mapped value. This new capability is also described below.

Robust LDAP Authentication

In D6, it is possible to configure secondary, failover LDAP servers for any primary LDAP server used for authentication. A primary LDAP server is one that the Content Server initially resolves for authenticating a user. Each primary LDAP server can have one or more failover LDAP directory servers for authentication. Content Server uses the failover LDAP servers if the LDAP server initially chosen for authentication is not available.

An LDAP configuration object represents an LDAP server that Content Server can use for authentication (or for user/group synchronization). The failover behavior is controlled by the following two properties in the LDAP config object:

• failover_ldap_config_ids – lists the object IDs of the secondary LDAP server config objects for the primary server represented by this LDAP config object
• failover_use_interval – defines the duration for which Content Server will continue to use a failover server for authentication before attempting again to contact the primary LDAP server. This enables restoration of normal operation once the primary LDAP server becomes available again

When Content Server chooses an LDAP server to authenticate a user, it retries connection to the LDAP server via multiple attempts if the connection attempt fails.

The retry_count property of the ldap config object specifies the number of times Content Server will attempt to contact the chosen LDAP server.

If all of these attempts fail and there are secondary, failover LDAP servers configured for the primary LDAP server, Content Server attempts to use one of those servers. If there are no failover LDAP servers configured or if the user cannot be authenticated using a failover server, user authentication fails.

Having seen the new features in LDAP configuration, we can now understand the overall failover behavior in the authentication process.

1. The primary LDAP server becomes unavailable.
2. Content Server receives an authentication request and attempts to bind to the primary LDAP server. The connection attempt fails. Content Server makes as many total attempts as specified in the
   retry_count property of the LDAP config object of the primary LDAP server.
3. Content Server attempts to contact the secondary LDAP directory
   servers in the order that they are configured in failover_ldap_config_ids. Once Content Server successfully binds to a secondary LDAP directory server, it continues to use that server for any subsequent attempts for authentication. Once the duration of time configured in the failover_use_interval property has elapsed, Content Server attempts to contact the primary LDAP directory server for user authentication.
4. If the secondary LDAP directory server is unavailable or becomes unavailable within the specified use interval, Content Server contacts the remaining secondary LDAP directory servers, per the order listed in failover_ldap_config_ids.Content Server only contacts the secondary LDAP directory servers that are configured for the primary LDAP directory server; it will not contact the LDAP servers listed in the failover_ldap_config_ids property of the secondary servers.
5. If all attempts to contact the secondary LDAP directory servers fail, Content Server contacts the primary LDAP server again. If all LDAP servers are unavailable, user authentication fails.

Limitations

• An LDAP server created as a secondary server can only be designated as the failover server for one LDAP server. You cannot use the same LDAP server as a failover server for multiple LDAP servers.
• LDAP failover is supported for user authentication only. LDAP failover is not supported for user or group synchronization or on-demand user synchronization.

Attribute Mapping for User/Group Synchronization

D6 adds the ability to map multiple LDAP attributes to one property in Documentum and the ability to use expressions to define the mapped value.

Content Server uses attribute mapping to populate user/group object properties when these users or groups are synchronized from an LDAP server. The mapping is specified in the LDAP config object. LDAP entry attributes can be mapped to system or user-defined properties.

For example, the LDAP user attribute homepage can be mapped to a custom user property called web_page. More commonly, the LDAP attributes givenname and sn (surname) are mapped to the dm_user.user_name property.

Multiple LDAP properties can be combined into a single repository property using an expression. For example, the following expression uses the LDAP attributes sn and givenname to generate a user_address (email) value:

${givenname#1}${sn}@company.com

In this example, John Doe’s email address will become JDoe@company.com.

The #1 (= substring of length 1 from left) picks the first letter of the string value.

Property values set through mappings to LDAP attributes may only be changed either through the LDAP entry (by making the change in LDAP that gets synchronized to the repository) or by a user with Superuser privileges.

Advertisement