Shane wrote: > I've been trawling through man pages etc today looking for a possible > solution to this and came across this in slapd-meta: > > # Bind with email instead of full DN: we first need > # an ldap map that turns attributes into a DN (the > # argument used when invoking the map is appended to > # the URI and acts as the filter portion) > rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub" > > # Then we need to detect DN made up of a single email, > # e.g. '[EMAIL PROTECTED]'; note that the rule > # in case of match stops rewriting; in case of error, > # it is ignored. In case we are mapping virtual > # to real naming contexts, we also need to rewrite > # regular DNs, because the definition of a bindDn > # rewrite context overrides the default definition. > rewriteContext bindDN > rewriteRule "^mail=[^,[EMAIL PROTECTED],]+$" "%{attr2dn(%0)}" ":@I" > > OK, not really what we want - but it did get me thinking about a what > if. Could this sort of rule be used for any search to say > cn=posixGroups to rewrite a groupOfNames member to return just the uid > rather than full dn. Combine the rewrite rule with an overlay like: > map objectClass groupOfNames posixGroup > map attribute member memberuid > > I'm still struggling to get the rewrite rule to do anything at all for > me (again) but anyone have some of idea if this could actually work?
That's just an example of what librewrite allows to do in slapo-rwm(5). But maybe you got it wrong: that rewriting does not consist in replacing the DN with the email address; it consists in taking a bindDN of the form "[EMAIL PROTECTED]" and turning it into a full DN by performing a search for "([EMAIL PROTECTED])" and using the DN of the resulting entry. This is a hack, and it's possible since "[EMAIL PROTECTED]" is a valid DN. "[EMAIL PROTECTED]" is not a valid DN. So, if you are fine with having "memberUid=uidNumber" as memberUid value, this could be of help, but I fear neither of your (broken [*]) clients would accept such a compromise. p. [*] I say "broken" since a client that uses posixGroup for LDAP grouping is broken (should I say insane?) in the first place. One that expects memberUid to be DN-valued is broken twice. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: [EMAIL PROTECTED] ---------------------------------------
