Re: LDAP Search with non-existent attributes

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

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
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------