[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: posixGroup

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. 'mail=someone@example.com'; 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=[^,]+@[^,]+$" "%{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 "mail=user@domain" and turning it into a full DN by
performing a search for "(mail=user@domain)" and using the DN of the
resulting entry.  This is a hack, and it's possible since
"mail=user@domain" is a valid DN.  "user@domain" 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.


[*] 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
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it