Grouper Developers Forum

[James Cramton <>]

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.

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.

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?

Thanks!

--
James Cramton
The University of Arizona

520 777 1967