Status

This is the recommended connector to connect midPoint with the LDAP servers.

Description

Connector for standard LDAPv3 directory servers.

Capabilities and Features

History

This is an LDAP connector completely rewritten from scratch during 2015. It was significantly improved in following years. Currently the LDAP connector is perfectly stable and tested in many deployments. It can be used with a variety o LDAP servers, including exotic and obsolete systems.

Versions

Interoperability

In theory the connector should work with any LDAPv3 compliant LDAP server. However, many servers claim LDAPv3 compliance while the reality is far from ideal. The connector supports "quirks" of several popular LDAP servers and it tolerates some violations of LDAPv3 standards.

The connector was successfully tested with the following LDAP servers (assuming reasonably recent versions of the servers):

• OpenLDAP
• ForgeRock OpenDJ / wren:DS
• 389 directory server / Red Hat Directory Server / Fedora Directory Server
• Oracle Directory Server Enterprise Edition (DSEE) / Sun One / Sun Java System / iPlanet Directory Server
• ViewDS

We know that at least some operations of the connector works with these servers and they are supported in some midPoint deployments. However, support for any specific server is not part of standard midPoint subscription and it has to be negotiated separately (see below).

If you are using this connector with a different directory server please let us know. We would like to know both about the positive and negative experiences.

Limitations

• Additional search filter does not work for "Sun changelog" synchronization strategy. The structure of changelog does not allow direct application of the filter on server-side. Client side application of filter is not straightforward due various complexities and the implementation is not planned for now.
• Synchronization based on modifyTimestamp has a simplistic implementation. It does not support SPR, VLV or referral-following functionality. This synchronization method is inherently inefficient and unreliable. It should be used only as a last resort, if no other method is available.

Support

LDAP connector is bundled with midPoint distribution. Support for LDAP connector is included in standard midPoint support service (a.k.a. bundled support) - however, there are limitations. This "bundled" support only includes operations of LDAP connector that 100% compliant with LDAP standards. Any non-standard functionality is explicitly excluded from the bundled support.

It is a sad fact that so far we haven't seen any LDAP server that would be 100% standard-compliant or that would not require any non-standard extensions to work. Therefore if you want to be sure that this LDAP connector will work with your LDAP server, we strongly recommend to negotiate support for that specific server in your midPoint support contract.

For the purposes of this definition "standard" means RFC specifications that reach at least a "proposed standard" status. Drafts, informational documents, vendor specifications or any other documents are not considered to be part of LDAP standards.

This means that the bundled support does not include support for any specific LDAP server. Support for specific servers needs to be explicitly negotiated in the support contract.

Documentation

ConnId Result Handlers

Those "result handlers" are an artifact of an original original Identity Connector Framework over-engineering. The handlers are supposed to assist connectors by implementing "mechanism" that the connector or resource does not support - such as search result filtering, data normalization and so on. However, those handler are generic and they know nothing about the particulars of the resource that the connector connects to. Therefore in vast majority of cases those handlers just get into the way and they distort the data. Good connectors usually do not need those handlers at all. Unfortunately, these handler are enabled by default and there is no way for a connector to tell the framework to turn them off. The handlers needs to be explicitly disabled in the resource configuration.

<icfs:resultsHandlerConfiguration>
  <icfs:enableNormalizingResultsHandler>false</icfs:enableNormalizingResultsHandler>
  <icfs:enableFilteredResultsHandler>false</icfs:enableFilteredResultsHandler>
  <icfs:enableAttributesToGetSearchResultsHandler>false</icfs:enableAttributesToGetSearchResultsHandler>
</icfs:resultsHandlerConfiguration>

Date and Time Formats

 You can control the way LDAP connecto presents dates and times by by using timestampPresentation configuration property. It has three possible values:

• native: LDAP connector will present timestamps in native ConnId date format. This is the most natural and default setting.
• unixEpoch: LDAP connector will present timestamps in UNIX epoch format (number of seconds since 1970)
• string: LDAP connector will present timestamps in LDAP-native format (generalized time, ISO 8601

In a normal case all timestamps in midPoint are in W3C DateTime format. When using the native time representation, MidPoint automatically converts all the date/time values to this format.

However, older versions of ConnId framework did not have any way how to express date/time information in the schema. The native time representation was not possible. ConnId framework was representing date/time information as (long) integers in UNIX timestamp format. For these cases there are options to represents time as long integer or string. This is mostly a historical feature now.

ObjectClass Filters

Natural way to use LDAP is to use "short" search filters, such as (cn=foo). However, such search filter can match objects of several incompatible objectclasses, producing incorrect results. Therefore a strict way to construct a search filter is to always add an objectclass clause to the filter, resulting in (&(objectclass=inetOrgPerson)(cn=foo)) filter. Use of such search filter ensures that the results will be correct.

This search filter should work flawlessly on standard-compliance and correctly-configured LDAP servers. Therefore since connector version 3.2, use of such search filters is tuned on by default. However, such search filters may cause issues on non-compliant and/or incorrectly configured and populated servers. In such case, the behavior can be controlled by includeObjectClassFilter configuration property.

Resource Examples

• OpenLDAP
• OpenDJ
• Directory Server Enterprise Edition

Notes

The LDAP connector bundle also contains connectors for Active Directory and eDirectory. These connectors are specializations of the LDAP connector and support the LDAP quirks needed to work with AD and eDirectory.

See Also

• LDAP Connector Documentation
• LDAP Explanation
• LDAP Connector Migration
• Active Directory Connector (LDAP)
• eDirectory Connector
• Legacy LDAP Connector