Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] ldappc edu.internet2.middleware.ldappc.synchronize.GroupEntrySynchronizer.clearRoot()

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] ldappc edu.internet2.middleware.ldappc.synchronize.GroupEntrySynchronizer.clearRoot()

Chronological Thread 
  • From: "Michael R. Gettes" <>
  • To: Owen Cliffe <>
  • Cc: Tom Barton <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] ldappc edu.internet2.middleware.ldappc.synchronize.GroupEntrySynchronizer.clearRoot()
  • Date: Mon, 28 Apr 2008 16:00:13 -0400

I am in favor of the schema-less approach and what you describe
is the namespace managed approach i have been advocating for
some time. +1 to this idea.


On Apr 28, 2008, at 7:58, Owen Cliffe wrote:
Apologies Tom, I forgot to forward this answer to the list, a slightly
amended version follows:

-------- Original Message --------
Subject: Re: Fwd: [grouper-dev] ldappc

Tom Barton wrote:
I see. And rather than using the group objectclass to distinguish groups
that "belong" to Ldappc, perhaps it could be useful to mark them in some
other attribute (eduInternet2LdappcInstanceId maybe, especially
recognizing that some sites wish to run multiple instances of Ldappc,
each "owning" their own slice of the grouper db).

I think a custom attribute would be a sensible default way of
segregating provisioned LDAP groups between different ldappc
provisioning instances (we already use this technique with grouper group
attributes to simplify the process of synchronizing external group data
into grouper). However as you say later there are going to be cases
where people are unable or reluctant to add extra schemas (we have this
problem with our AD setup).

Perhaps one approach would be to use a custom attribute/schema by
default but then also
allow users to manually specify the set of groups to compare with an
LDAP base, filter and scope. That way users with more unusual setups
should be catered for (with the caveat that the user would need to make
sure that the sets of groups managed by each instance were disjoint).
That way users could seperate instances by objectClass, ou, or even by
cn. An extreme example might be different ldappcs which provision
different grouper stems into a flat hierarchy into the same DN: one
provisions root:stem1:... and matches/deletes groups with
cn=root:stem1:* and another provisions root:stem2:... and matches groups
with cn=root:stem2:*.

Notionally each LDAPPC provisioning "session" then contains:
- A grouper search of groups/stems to provision
- *An LDAP search of which groups to manage/delete
- A binding from grouper/ldap groups for the above groups with an
assumption that the binding will produce ldap groups which match the
LDAP search and that no other provisioning sessions will produce LDAP
groups which match the LDAP search.

Any such changes might open up the possibility of provisioning conflicts
but so long as users are made aware of the risks of mis-configuring
provisioning I think the extra flexibility would be beneficial.

As an aside, I might be wrong but I didn't notice a way of binding an
LDAP group
attribute statically for generated groups (only from an existing grouper
group attribute), If one could say have a binding in the config for all
groups which set "arbitraryAttributeX=arbitraryValueY" on groups which
were provisioned that might be a useful generalisation of the
eduInternet2LdappcInstanceId you suggest above.

Of course, you probably only get full value from Ldappc if the DSA's
schema is extended, the way things are now.
Agreed, however we really appreciated the ability to use ldappc without
having to extend our group schema (we don't use eduPerson inside our
LDAP either).

Owen Cliffe Systems & Networks Administrator
Bath University Computer Services University of Bath
Tel: 01225 386047

Archive powered by MHonArc 2.6.16.

Top of Page