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.