Grouper Developers Forum

[Tom Zeller <>]

> Folks,
>
> At U of Arizona this week, our LDAPpc testing saw some unexpected behavior
> that I remember from Brown's testing of LDAPpc 1.0 back in 2006. Brown
> developed its own LDAP provisioning code that handled this work differently,
> so I'm now having to confront what I didn't resolve 3 years ago. The U of A
> is running the distribution version of LDAPpc 1.4.2.
>
> At both institutions, we have our registrar-provisioned course groups in a
> different stem than the course groups that are consumed by applications.
>
> For example:
>
>        arizona.edu:courses-registration:2009fall:ACCT531:001:learner
> and
>        arizona.edu:courses:2009fall:ACCT531:001:learner
>
> Members of the course-registration stem are members of a similarly named
> course group in the courses stem. This makes provisioned course group
> members indirect members of the course group in the courses stem, and any
> ad-hoc memberships created manually in Grouper are direct members in the
> course group in the courses stem.  Evidently, at this point, we should
> perhaps call this "The Cramton Obfuscation Design Pattern." Perhaps it
> over-complicates things, but in both cases, there are sound business reasons
> to maintain a layer of abstraction between the provisioned course groups and
> the course groups consumed by applications.

The CODP resembles provisioning 'org' groups using composites, I would
think, so it might be a common-enough situation.

Groups in 'courses-registration' are members of groups in 'courses', right ?

> LDAPpc is configured to provision only the courses stem into LDAP. But in
> reviewing the LDAP traffic during LDAPpc provisioning, we see LDAPpc
> performing an LDAP search for the course groups in the courses-registration
> stem while it is provisioning the courses stem.

You are seeing something like

SRCH base="ou=grouper,ou=groups,dc=eds,dc=arizona,dc=edu" filter="(cn=X)"

where X is the "name" of a 'course-registration' group which is a
member of a 'courses' group ?

> Is there a way to configure LDAPpc to not scan LDAP for stems that are not
> provisioned into LDAP? Brown's design prevented this behavior, because it
> does not permit a truly incremental LDAP provisioning run. Or is this a bug
> I should open up in Jira?

As of 1.4.2, ldappc always attempts to lookup members, since the
'control' which decides whether or not a member is provisioned is it's
existence in the directory. In other words, <group-queries> is ignored
for member groups.

In future-1.5, there is more control in terms of deciding which
members to provision. I hadn't thought of this case where some members
of a particular source would be provisioned while others were not (the
granularity is sourceID), but it shouldn't be too hard to include.

So, yes, please open a bug (if I'm understanding correctly). I don't
intend to fix this in 1.4, but rather 1.5.

TomZ