LDAPpc scanning LDAP for non-provisioned groups

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.