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]
---------------------------------------


Reply via email to