Grouper Developers Forum

[Owen Cliffe <>]

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
provisioned
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).


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