Annoyingly, some applications require the entire dn of a user be in the memberUid field and others only require the memberUid. On some posixGroups, I end up having the following:
cn: grpname objectClass: top objectClass: posixGroup gidNumber: 550 memberUid: uid=user1,ou=People,dc=example,dc=com memberuid: user1 memberUid: uid=user2,ou=People,dc=example,dc=com memberuid: user2
Is there any way to map one to the other so I do not end up having "duplicate" entries?
Thank you,
This is the same basic problem I'm trying to solve (on list: rewrite rule - turn groupOfNames into posixGroup)
I kind of like you're solution, despite the obvious duplication, of putting both the uid and the dn into the memberuid field - at least that way makes it a unified place for group management rather than needing to maintain seperate posixGroup and groupOfNames lists.
A rewrite rule sounded ideal - pity it seems to be impossible. It seemed like such a simple idea for requests to cn=groupName,cn=posixGroups to select matching groupname from cn=groupsOfNames, and return objectClass posixGroup and member: regex( s/uid=(.*?),.*/\1/ ) ...and overlay was suggested as a possibility - I have no idea how to start with that yet, even though the overlay idea was suggested as also being not very nice it may be my best choice for now if it works ...any pointers on where to start / examples? (pls don't just recommend the man pages as I'll read them regardless)
short of overlays possibly working looks like we're stuck waiting for all clients to move to the correct LDAP standard of using groupOfNames and until then have to deal with duplication.
Shane.
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?
TIA Shane.
On 09/05/07, Shane squindler@gmail.com wrote:
This is the same basic problem I'm trying to solve (on list: rewrite rule - turn groupOfNames into posixGroup)
I kind of like you're solution, despite the obvious duplication, of putting both the uid and the dn into the memberuid field - at least that way makes it a unified place for group management rather than needing to maintain seperate posixGroup and groupOfNames lists.
A rewrite rule sounded ideal - pity it seems to be impossible. It seemed like such a simple idea for requests to cn=groupName,cn=posixGroups to select matching groupname from cn=groupsOfNames, and return objectClass posixGroup and member: regex( s/uid=(.*?),.*/\1/ ) ...and overlay was suggested as a possibility - I have no idea how to start with that yet, even though the overlay idea was suggested as also being not very nice it may be my best choice for now if it works ...any pointers on where to start / examples? (pls don't just recommend the man pages as I'll read them regardless)
short of overlays possibly working looks like we're stuck waiting for all clients to move to the correct LDAP standard of using groupOfNames and until then have to deal with duplication.
Shane.
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.
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: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org
-
Karen R McArthur -
Pierangelo Masarati -
Shane