[Date Prev][Date Next]
"Kurt D. Zeilenga" wrote:
> At 04:17 AM 2001-11-01, Pierangelo Masarati wrote:
> >Has ever been any attempt to consider it in LDAP specification,
> Given that a DN is not a string but a complex data definition,
> doing a substrings assertion on the DN doesn't make much sense.
> Now, one could define an extensible matching rule for doing
> a substrings assertion upon the string representation of the
> DN, but this doesn't make all that much sense given all the
> alternative codes of the same DN.
what Kurt says makes a lot of sense. I understand what you're
trying to do with the "member" attribute: it closely resembles
what happened with samba-tng (and, I guess, with samba itself).
Initially, they improperly re-used the member attribute, using
OpenLDAP 1.X or even UMich LDAP, to define an attribute structured
as "some name,code1,code2"; when someone tried to compile samba
with OpenLDAP 2.0.X this didn't work any longer due to the dn
syntax of the "member" attribute, so they had to generate
a "sambaMember" attribute. Note that the problem, in this case,
was the search filter for "(member=some name,*)" resolving to
undefined because of the wildcard.
If you want to select something based on some DN being member of
a group, the LDAP-ish solution is: use the approximate knowledge
of the entry to find the entry's DN (e.g. search for
"(cn=*some name*)"), then use the dn you find to search for
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:email@example.com
via La Masa 34, 20156 Milano, Italy |