Grouper Users - Open Discussion List

[Tom Barton <>]

Sanjay Vivek wrote:
> Hi Tom,
>
> I've taken a look at the LDAP logs and it looks like Ldappc is looking
> for the users in the Grouper groups in the LDAP source and not the JDBC
> source. For example, we have John Smith 
> ()
>  in
> the Staff group and he's located in our JDBC source (jdbc_ncl). What we
> would like to happen is for the groups to be provisioned from Grouper to
> LDAP with the following entry in LDAP:
>
> dn: cn=ncl:staff,ou=grouper,dc=ncl,dc=ac,dc=uk
> objectClass: groupOfNames
> objectClass: top
> member: 
> ,ou=grouper,dc=ncl,dc=ac,dc=uk
> cn: ncl:staff
>
> We are in a rather unique position of having JDBC as our primary source
> of users. So is it feasible to provision users from our JDBC source to
> LDAP without the users first being present in a LDAP source? Cheers.

Ldappc will not create or delete person entries in ldap. That's presumed 
to be the province of your existing IdM operation. It *will* 
add/delete/modify group entries that correspond to grouper groups, and 
it will add/delete/modify a membership attribute in existing person 
entries (and any other entry types that are associated with group 
memberships).

Ldappc is looking for users in ldap to determine the DN of entries 
corresponding to grouper group memberships to add those value to each 
group's member attribute. I expect that, if you turned up the log level 
of the log4j.logger.edu.internet2.middleware.subject logging target to 
debug, you'd see it looking up member subjects in your jdbc source to 
find the subject attribute it uses to build the ldap search filter to 
find each subject's corresponding ldap entry, and to find the subject 
attribute with which to populate corresponding hasMember values, per the 
declarations in ldappc.xml.