On Fri, Jan 16, 2015 at 03:34:11PM +0100, Dirk-Willem van Gulik wrote:

W’re comparing various LDAP server setups; and we are wondering what the ‘correct’ search result is for a search which is done such as

 '(|(|(|(givenname=fred*)(sn=fred*)(mail=fred*)(cn=fred*)

You have a mismatch of parentheses there. The filter should be:

(|(givenname=fred*)(sn=fred*)(mail=fred*)(cn=fred*))

[ Note that one '|' can be followed by a list of one or more filters - it is not a dyadic operator - see RFC4515 section 3 ]

Where are the 'non-existent attributes'? All of those listed in the search filter are in the standard schema. Your sample entry below may not have values for all of them, but as the sub-filters are combined with OR that would not matter. Providing an attribute-value assertion containing an outlandish attribute name just might provoke a different response, but the standard says that such elements in a filter should evaluate to UNDEFINED and the OR operator would then treat the element as FALSE.

in a situation where we have records which do not have a certain attribute (e.g. no givenname or cn) — e.g. a record as light weight as:

dn: uid= 1234 objectClass: person uid: 1234 sn: fred fred telephoneNumber: 1234

That would not be a valid entry as objectClass person requires both cn and sn. It *might* be a valid answer to a search - e.g. if access-control prevented disclosure of cn.

As we notice that some servers will return this given above query; and some do not.

In principle the entry matches the filter so it should be returned.

However, the '|' (OR) operator poses a significant problem for a server, particularly where there are a lot of entries and one or more of the attributes in the search string are not indexed. This can force the server to inspect every entry in its database individually which is a lot of work, so servers may refuse to do it. For some servers, an attribute type is treated as 'not indexed' if there are no entries with a value for that attribute type, even if indexing is enabled. [ I think OpenLDAP used to do this but I have not checked recently ]

The actual result that you would get from the server in this case depends to some extent on the security stance of the developers and of the manager of the server instance. I can see valid arguments for several results:

adminLimitExceeded busy unwillingToPerform success - along with zero or more entries

And I cannot find the exact spot in the RFC where the
‘correct’ behaviour is mentioned.

RFC4511, 4.5.1.7. SearchRequest.filter

As we notice that some servers will return this given above query; and some do not.

It would be interesting to have more detail on exactly what you did and what results you found.

Andrew