I've been reading (and actually experienced) that DN, not being a full class attribute, is not filterable (read : with wildcards / patterns).
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.
If there is a commonly used alternative to filtering DNs I'd be glad to hear.
Thanks.
Lorenzo Pastrana R&D Head @ Happy End -------------------------- Web Shop Multimédia Design Visual Communication & Publishing -------------------------- Tél.: +33 1 42 47 83 09 Fax.: +33 1 47 70 70 19 E-mail : lorenzo.pastrana@happyend.fr
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.
Hallvard B Furuseth wrote:
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.
AFAIK, filtering on entryDN is actually dealt with using the dn2id index, which is maintained by default.
p.
Pierangelo Masarati wrote:
Hallvard B Furuseth wrote:
Don't know if indexing of entryDN is needed or supported, since slapd alreday has an implicit index for the DN.
AFAIK, filtering on entryDN is actually dealt with using the dn2id index, which is maintained by default.
Pierangelo, you said it's supported since 2.4.13:
http://www.openldap.org/lists/openldap-software/200902/msg00116.html
Ciao, Michael.
On Fri, 2009-06-05 at 12:28 +0200, Hallvard B Furuseth wrote:
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.
Ok.. thanks
Wildcard matching wouldn't work too well with DN syntax,
Well, no rocket science here.. I guess it would work in our case..
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'm trying to filter out multiple sub-branches so scope based is not enough here.
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.
Ah, great ... I'll try this, but your pattern below seems ok for the filter I need and it works also with (uid:dn:=...) even if it's not strictly the same.
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)'.
Thanks a lot.
Lorenzo Pastrana R&D Head @ Happy End -------------------------- Web Shop Multimédia Design Visual Communication & Publishing -------------------------- Tél.: +33 1 42 47 83 09 Fax.: +33 1 47 70 70 19 E-mail : lorenzo.pastrana@happyend.fr
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Lorenzo Pastrana -
Michael Ströder -
Pierangelo Masarati