Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] LDAPpc scanning LDAP for non-provisioned groups

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] LDAPpc scanning LDAP for non-provisioned groups

Chronological Thread 
  • From: Tom Zeller <>
  • To: James Cramton <>
  • Cc:
  • Subject: Re: [grouper-dev] LDAPpc scanning LDAP for non-provisioned groups
  • Date: Mon, 3 Aug 2009 12:56:40 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=oN2PW7lvlW1UsQPw9LfeKXW6HdUck9NWCjyw3GrNz0oowiVZNCwjyOSiAA9whB1nQd RfuFmjFFlqCR+4pGwx+uVlwmElCQnl0k5027SsXwuO9J5TCGMpxts3q8s7JEY9g2Free 2ZEdoR9Jl8B+frQzSMTFhAm1DCRo7/lVMOrgQ=

> 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:
> and
> 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.


Archive powered by MHonArc 2.6.16.

Top of Page