2012/10/28 <[email protected]>:
>
>
>
> All,
>
> Hopefully somebody can help me with the JavaScriptfu needed to do this. I'm
> using LSC 2.0.1.
>
> We're replicating from an iPlanet server using the rfc2307bis schema to an
> OpenLDAP server using the nis (rfc2307) schema. We went with the
> nis/rfc2307 schema instead of the rfc2307bis schema, as the Linux
> nss-pam-ldapd package works better with it, and can't handle the extras that
> rfc2307bis brings us (memberOf/nested groups/etc).
>
> The source base is ou=groups,o=example,o=org, the target base is
> ou=groups,dc=example,dc=org for groups.
> The source base is ou=People,o=example,o=org, the target base is
> ou=users,dc=example,dc=org for users.
>
> The source has something like:
>
> dn: cn=test-users,ou=groups,o=example,o=org
> description: Test users
> objectClass: top
> objectClass: groupOfUniqueNames
> objectClass: inetMailGroup
> objectClass: inetLocalMailRecipient
> objectClass: inetSubscriber
> objectClass: ipUser
> objectClass: posixGroup
> cn: test-users
> gidNumber: 502
> uniqueMember: uid=test1,ou=People , o=example , o=org
> uniqueMember: uid=test2,ou=People,o=example,o=org
> uniqueMember: cn=east-test-users,ou=Groups,o=example,o=org
>
> And I need the destination to look something like:
>
> dn: cn=test-users,ou=groups,dc=example,dc=org
> description: Test users
> objectClass: top
> objectClass: posixGroup
> cn: test-users
> gidNumber: 502
> memberUid: test1
> memberUid: test2
> memberUid: (first user in east-test-users)
> memberUid: (2nd user in east-test-users)
> ..
>
> So 3 catches:
>
> 1) Same entries have spaces in the DN, some don't. Not sure why, but these
> can probably be easily stripped.
> 2) Referintial integrity in the source is busted. Some groups have users
> listed that aren't in the users table. I'm not concerned about these.
> 3) Groups can reference other groups, and those groups can also reference
> others.
>
> My first pass was something hackish like:
>
> <dataset>
> <name>memberUid</name>
> <policy>FORCE</policy>
> <forceValues>
> <string>var umembers =
> srcBean.getAttributeValuesById("uniqueMember").toArray(); for (var i=0;
> i<umembers.length; i++) { umembers[i] =
> umembers[i].match(/^[a-z]+=([^,]+)/).slice(1).join("") } umembers</string>
> </forceValues>
> <delimiter>$</delimiter>
> </dataset>
>
> Which handles #1 & #2, but doesn't handle #3 at all, which is a huge
> problem. Thinking through this, the logic flow seems to be:
>
> - If the entry starts with "uid=", grab the username out of it and use that.
> - If the entry starts with "cn=", grab the group name, then recursively scan
> that group and any child groups and add those users following the same
> loigic.
>
> So I'm guessing an array of users/groups. Users keeps getting appended to,
> and groups acts as a stack until it's depleted (found the most child node).
>
> Any ideas on the best way to do this? I'd really appreciate it!
When looping on users DN in your source group, you can test if the DN
is a user DN or a Group DN (use if dn.startsWith("uid=")). When you
find groupDN, you can get members of this group by searching on it
with srcLdap.attribute(DNgroup,'uniqueMember') : this will do a search
on the and return values from the defined attribute.
See
http://lsc-project.org/javadoc/2.0-SNAPSHOT/org/lsc/jndi/ScriptableJndiServices.html
Clément.
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
