6:34 a.m.
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*)
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
As we notice that some servers will return this given above query; and some do not.
And I cannot find the exact spot in the RFC where the ‘correct’ behaviour is mentioned.
Would anyone have a pointer or a suggestion ? And would OpenLDAP 2.4 be intentionally more
accommodating than the spec ?
Dw.
10:23 a.m.
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 |
-----------------------------------------------------------------------
8:30 a.m.
On 20 Jan 2015, at 19:23, Andrew Findlay
<andrew.findlay(a)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.
2987
days inactive
2992
days old
openldap-technical@openldap.org
2 comments
2 participants
participants (2)
-
Andrew Findlay -
Dirk-Willem van Gulik