I was perusing the source for OpenLDAP and I saw where the root DSE supports something called absolute filters. It looks like it's specified in RFC4526 It looks like the author that originally drafted it was working on the OpenLDAP project so I don't know if this is something useful to that specific implementation or what.

At any rate the RFC gives this definition:

   An 'and' filter consisting of an empty set of filters SHALL evaluate
   to True.  This filter is represented by the string "(&)".

   An 'or' filter consisting of an empty set of filters SHALL evaluate
   to False.  This filter is represented by the string "(|)"

My question is: What the usefulness of this? I can't think of any examples where this provides the ability to do something you couldn't do before. If you want an absolute AND then can't you do an (objectClass=*) filter since all entries must have at least one object class?

The only one I can kind of think of a use for is the Absolute False. It may be that you just want to do a noop on the server to make sure communication is still functioning normally. That's still sort of redundant since I would think querying the root DSE and discarding the results would do the same thing and couldn't be all that computationally expensive.

Using the filter in an ldapsearch produces the results I guess I should expect given the above:

[root@hypervisor openldap]# ldapsearch -x -H ldap://policyServer.trunkator.com -b '' -s base "(|)" +
# extended LDIF
# LDAPv3
# base <> with scope baseObject
# filter: (|)
# requesting: +

# search result
search: 2
result: 0 Success

# numResponses: 1
[root@hypervisor openldap]#

Using the absolute true filter returns the same thing as if I had done an (objectClass=*) (which is the default filter for OpenLDAP's ldapsearch client if you don't specify one on the command line).

According to the RFC they removed these from the original LDAPv3 RFC and so the author went through the trouble of getting them added back in and I'm just curious as to why (I'm sure there's a reason).

Any ideas?


Bit of poor phrasing up top: When I say "root DSE supports" a clearer way of saying it is that the root DSE in OpenLDAP is hard coded to report back that it supports absolute filters.

  • 1
    This question appears to be off-topic because it is not about a technical problem you have but stems from curiosity about a decision some protocol designer made. – Sven Jul 26 '13 at 20:05

The Abstract and the Background sections of the RFC clearly state that this feature was overlooked in LDAP v3. The concept of absolute filters apparently is a part of X.500/DAP and they aim to help with querying DSA-specific entries, which might not have an objectclass associated with them. Although this is obviously not a vendor specific feature, its implementation is left to the vendor (e.g., OpenLDAP seems to have implemented it). It doesn't seem to be very useful if the directory software being used associates all entries including the DSA-specific ones with an objectclass (e.g., top) which makes the filter '(objectclass=*)' function as if it's an absolute filter that results in 'true'. If the directory software doesn't associate DSA-specific entries with an objectclass or another attribute whose specific value will resolve to 'true' in a search, then an absolute filter that acts as a true/false switch becomes sort of a required feature (unless the directory software provides a proprietary way to retrieve such entries, which is probably not a good idea as such nonstandard implementation will force LDAP clients to be vendor limited/specific).


I suspect it's to make certain programming constructs easier. For example, if you build up filter expressions in your code like this:

for filter in filters:
    filter_string = filter_string + '(' + filter + ')'
filter_string = filter_string + ')'

...then in the case in which you have no filters you end with (&), and the part of the RFC you've highlighted defines how this should behave. The same reasoning holds true for (|).

  • In that situation wouldn't it make sense for the recommendation to be "check your string length and if it's only three characters long do (objectClass=*) instead"? What I mean is that it seems like a lot of effort if it's just to get that functionality (which isn't to say that isn't its intended use) when a simple if/else state ought to catch such a thing. – Bratchley Jul 26 '13 at 20:09
  • Eh, I'm just guessing. For an authoritative answer you could contact the RFC author (and post the answer here if you get one). – larsks Jul 26 '13 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.