[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP Search with non-existent attributes



> On 20 Jan 2015, at 19:23, Andrew Findlay <andrew.findlay@skills-1st.co.uk> wrote:
> 
> 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 ]

Ok - glad to hear this; I was rather confused (above string was taken out of a test dump of a VoIP system and also seen very similar diadics on quite a few deskop/mac products). So the string itself is bogus to start with.

.. cut …

> 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
...
> 
>> 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.

Thanks - we’ll dive further and will summarise if something sensible comes out of it - but it appears that, to start with, various VoIP phones and desktop products, generate an OR query which is already a bit dubious to start with.

Dw.