Page tree
Skip to end of metadata
Go to start of metadata

Frequently Asked Questions

What are the ERR_13748_MATCHING_RULE_NO_SYNTAX errors that are flooding my log files?

You may see errors in your logfiles that look like this:

2019-09-26 13:23:37,271 [] [main] INFO (org.apache.directory.api.ldap.model.schema.registries.Registries): ERR_13748_MATCHING_RULE_NO_SYNTAX The MatchingRule 2.5.13.21 does not have a syntax. This is invalid

The short story is that those may be safely ignored.

The long story is, that every LDAP servers has its "quirks".  There is practically no LDAP server that strictly and preciselly follows LDAP standards. In addition to that, LDAP standards are still just a human-readable text and there is no reference implementation. Therefore the people writing LDAP servers and people writing LDAP clients do not always agree what is a standard-compliant behavior. Those are also the likely reasons behind this message.

This specific message means that the definition of matching rule 2.5.13.21 (telephoneNumberSubstringsMatch) in OpenLDAP schema refers to a syntax 1.3.6.1.4.1.1466.115.121.1.58 which is not defined in OpenLDAP schema.

We do not want to be judges of LDAP compliance as we are not a standard body. The fact is that the implementation of OpenLDAP and the implementation of Apache Directory API do not agree at this point. This particular issues may get eventually fixed in either OpenLDAP or Apache Directory API. But as both the server and the client is made by people, it is likely that there will be more such issues in the future.

This particular issue is harmless as midPoint does not rely on explicit definition of LDAP syntaxes. Other similar issues are very likely to be harmless too. But it is hard to be completely sure.

Currently there is no simple way how to silence those error reports except for setting the log levels. This can be hopefully improved in future versions of Apache Directory API.

Configuration Tips and Tricks

Paging and Sizelimit

Unlike other LDAP servers OpenLDAP imposes size limit also on paged searches. The sizelimit (soft and hard) seems to limit total number of entries returned in all pages. To change this behavior a "prtotal" size limit needs to be set:

olcLimits: dn.exact="cn=idm,ou=Administrators,dc=example,dc=com" size.prtotal=unlimited
  • No labels