|Support provided by||Evolveum|
|Target systems||Standard LDAP servers (LDAPv3)|
This is the recommended connector to connect midPoint with the LDAP servers.
Connector for standard LDAPv3 directory servers.
This is an LDAP connector completely rewritten from scratch in 2015. It is using Apache Directory API and it is designed and built to work with recent ConnId versions and to take all the advantages of that. This is the supported and recommended LDAP and AD connector for midPoint. The old LDAP and AD connectors are now deprecated and they are no longer supported.
LDAP or LDAPS
Capabilities and Features
|Schema||YES||Determined from standard LDAP schema.|
For LDAP servers that support Sun-style changelog (Retro ChangeLog) or modifyTimestamp.
There is a contributed code for OpenLDAP synchronization. However, this is not included in "bundled" support.
It is assumed that the server will hash the password and store it securely. Support for connector-side hashing is limited.
No activation for generic LDAP as there is not LDAP standard for that. This can be simulated in midPoint.
Simple Paged Results and VLV
|Native attribute names||YES|
Use ri:dn instead of icfs:name
Use ri:entryUUID instead of icfs:uid
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.
|Framework version||Bundled with midPoint|
LDAP stable, AD experimental
|184.108.40.206||Evolveum||download jar||GitHub||June 2016||220.127.116.11||Fixes timeout errors and resource leaks during AD connector resets.|
|18.104.22.168||Evolveum||download jar||GitHub||June 2016||22.214.171.124||3.4||Minor fixes.|
|126.96.36.199||Evolveum||download jar||GitHub||September 2016||188.8.131.52||3.4.1||Minor improvements.|
|184.108.40.206||Evolveum||download jar||GitHub||October 2016||220.127.116.11||Minor improvements.|
|1.4.3||Evolveum||download jar||GitHub||December 2016||18.104.22.168||3.5||Minor improvements.|
|1.4.4||Evolveum||download jar||GitHub||April 2017||22.214.171.124||3.5.1||CredSSP and Exchange powershell support, bugfixes, minor improvements.|
|1.4.5||Evolveum||download jar||GitHub||3rd July 2017||126.96.36.199||3.6||Powershell bugfixes, minor improvements.|
|1.5||Evolveum||download jar||GitHub||4th October 2017||188.8.131.52||3.6.1||More powershell execution alternatives and improvements, alternative auxiliary object class detection, explicit object class filter, configurable timestamp presentation, better error messages.|
|1.5.1||Evolveum||download jar||GitHub||11th December 2017||184.108.40.206||3.7, 3.7.1||Release coupled with AD connector.|
|1.6||Evolveum||download jar||GitHub||4th May 2018||220.127.116.11||3.7.2, 3.8||Release coupled with AD connector.|
|1.6.1||Evolveum||download jar||GitHub||17th April 2019||18.104.22.168||none||Fix of security vulnerability: missing check of certificate validity.|
|2.0||Evolveum||download jar||GitHub||7th November 2018||22.214.171.124||3.9||Native timestamp support. Support for delta-based updates. Additional search filter support.|
|2.1||Evolveum||download jar||GitHub||17th April 2019||126.96.36.199||none||OpenLDAP access log synchronization (contributed by Jonathan Gietz)|
Object class handling improvements (contributed by Matthias Wolf)
Experimental support for "language-tagged" attributes.
Fix of security vulnerability: missing check of certificate validity.
|2.2||Evolveum||download jar||GitHub||31st May 2019||188.8.131.52||none|
Upgrade of Apache Directory API (may fix some connection issues)
|2.3||Evolveum||download jar||GitHub||13th August 2019||184.108.40.206||4.0|
Upgrade of Apache Directory API
|2.4||Evolveum||download jar||GitHub||22nd November 2019||220.127.116.11||TBD|
Removed legacy support for eDirectory
|2.4.1||Evolveum||download jar||GitHub||23rd September 2020||18.104.22.168||TBD (probably 4.0.3)|
Fix configuration order (MID-6312)
|3.0||Evolveum||download jar||GitHub||3rd April 2020||22.214.171.124||4.1|
Fixed detection of polystring attributes.
|3.1||Evolveum||download jar||GitHub||20th October 2020||126.96.36.199||4.2|
Additional filter fixes at several places.
|3.2||Evolveum||download jar||GitHub||31th March 2021||188.8.131.52||4.3|
Optional unbind before disconnect
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):
- 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
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.
- 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.
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.
There may be exception to this rule for the customers that purchased support before the release of midPoint 4.0. In case of any doubts please contact Evolveum sales representatives.
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.
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.
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.
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.