LDAP Connector

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.

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.

You may be getting warnings and info messages in your log, like this:

Generally speaking, those messages are benign. We are using Apache Directory API as an LDAP client library in our LDAP connector. The Directory API is quite pedantic when it comes to adherence to LDAP standards and schema consistency. However, there is perhaps no single LDAP server that is 100% compliant with LDAP standards (see LDAP Survival Guide). Hence the warnings and info messages in log files.

As we cannot really fix the serves, and the behavior of Directory API is technically correct, there is no right way to solve this issue. The easiest practical way to get rid of the messages is to set levels for particular loggers:

Setting Directory API loggers to these levels should still be safe. In case of any major problem the connector itself should log appropriate error message.

Since version 3.4 of the connector, LDAP connector has a support for fail-over functionality. Several LDAP servers can be configured in LDAP connector. The connector will fail over to a secondary server(s) in case that the primary server fails. This can be configured using the servers configuration property:

The main LDAP server configured using the usual configuration properties (host, port and similar) is considered a primary server. Secondary servers can be configured using servers configuration property. The example above is a configuration of two LDAP servers:

There are several requirements, assumptions and limitations to this functionality:

LDAP replication functionality is quite common in LDAP server implementations. The fail-over functionality of LDAP connector takes advantage of this functionality. However, LDAP servers generally implement only weak consistency guarantees for replicated directory topologies, which is somehow given by the design of LDAP protocol and directory data structures. Weak consistency has its significant advantages, yet it has also disadvantages. When it comes to operation of LDAP connector, perhaps the most problematic is a read-after-write scenario. The connector may write data to primary server, then the primary server goes down, connector fails over to the secondary server, which means that subsequent read gets outdated data from a secondary server. As the fail-over happens transparently in the connector, the application (midPoint) is not aware that fail-over took place, it has no idea that the data may be out of date. This may cause temporary fluctuations, where old data may be presented as current data for a limited period of time. However, both LDAP servers and midPoint are built for eventual consistency, converging data values eventually. However, data consistency has to be kept in mind, and proper method should be employed both at the LDAP side (e.g. replication failure recovery) and midPoint side (e.g. regular reconciliation) to make the entire system eventually consistent.