On 2015-06-03 11:20, Pierre Schweitzer wrote:

This is not a question, but really a bug report about a broken behavior.

Again: I can confirm that requesting an attribute which does not exist in the subschema does not affect whether an entry is returned.

I quote them again: "Potentially, OpenLDAP should have a bug raised to make it impossible to get into a situation where error 65 is returned on a query, as it likely does not conform to the RFC."

Again: This statement is right and AFACIS OpenLDAP always worked correctly.

Here is the log extract you're asking for (I just filtered out the base DN): Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH base="XXXX" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(uid=heis spiter))" Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH attr=javaRemoteLocation Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SEARCH RESULT tag=101 err=65 nentries=0 text=

Up to now there's absolutely no evidence in the information you provided that this is a bug.

How did you make sure that an entry should be returned for exactly this search with the bound identity and your configuration?

I suspect a configuration or data error on your side. Many things can be wrong. Without seeing your config, data and the bound identity nobody can track this down for you.

Ciao, Michael.