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.
