Lorenzo Pastrana writes:
I've been reading (and actually experienced) that DN, not being a full class attribute, is not filterable (read : with wildcards / patterns).
It's not an attribute at all. Written the same way as attributes in LDIF format and maybe some other stuff, that's all.
Wildcard matching wouldn't work too well with DN syntax, but OpenLDAP does support scope-based matching rules: distinguishedNameMatch (the usual EQUALITY matching rule, like scope=base), dnOneLevelMatch, dnSubtreeMatch, dnSubordinateMatch (other scopes), dnSuperiorMatch (inverse of dnSubordinateMatch).
I've been thinking about 'duplicating' the DN in an attribute since the hidden 'entryDN' attribute is not accessible either but that sounds ugly and redundant to me.
It's not hidden. It's an operational attribute, which means it's only returned if you explicitly ask for it in the list of attributes to return from a search.
If there is a commonly used alternative to filtering DNs I'd be glad to hear.
Use filters like '(entryDN:dnOneLevelMatch:=dc=example,dc=com)'. Don't know if indexing of entryDN is needed or supported, since slapd alreday has an implicit index for the DN.