Grouper Developers Forum

["Michael R. Gettes" <>]

From empirical observation - LDAPPC with respect to grouper
does NOT currently own all groups in a corresponding OU of
the DIT - this comment is directed at 1.0 and not what KH
has been working on.  LDAPPC only operates on the namespace(s)
it is defined as owning within an OU of the DIT. I submit
this is proper operation.  LDAPPC, 1.0, does NOT apply the
same methodology for signet permissions - it currently owns
all value spaces for edupermission - and I think this is broken
as it should only be responsible for the value spaces defined
similarly to how it handles grouper groups.

Is this any clearer?

/mrg

On Apr 25, 2008, at 16:06, Tom Barton wrote:
> I think I understand the use case, but perhaps not your statement of  
> gap between that and current Ldappc capabilities. Are you saying  
> that Ldappc currently deals with groups as needed, but not with  
> privs? So that there would not need to be a relaxing of the  
> requirement that an Ldappc instance "own" all groups in a  
> corresponding ou in the DIT?
>
> Tom
>
> Michael R. Gettes wrote:
> > I think have a reasonable use case for doing this...
> > comanage - where you have multiple COs working against
> > the same directory.  If you view a CO as a signet/grouper
> > pair - then an individual LDAPPC instance working against
> > the signet/grouper pair publishing to a SINGLE directory
> > to be the amalgamation (?) of various COs thusly implies
> > LDAPPC only manage entities it knows.  Now, we could say
> > each CO is represented by an appropriate name space and
> > LDAPPC would only manage the defined name space (name space
> > being defined as a value space and NOT a portion of a DIT)
> > and then you can have multiple COs operate in the same portion
> > of the DIT.  This is the feature I was wanting for comanage to
> > fix in LDAPPC for signet - for grouper LDAPPC was already shown
> > to do the right thing.
> > I hope this makes sense.
> > /mrg
> > On Apr 25, 2008, at 14:22, Kathryn Huxtable wrote:
> > > A good point. I think it's a bad idea to mix grouper-managed  
> > > groups and non-grouper-managed groups.
> > >
> > > Anyway, I didn't think there'd be enough interest to add that  
> > > feature.
> > >
> > > -K
> > >
> > > On Apr 24, 2008, at 11:22 PM, Tom Barton wrote:
> > > > If this behavior is changed, you'll need to find another way to  
> > > > delete groups in LDAP that have been deleted from the grouper db.  
> > > > At least until the grouper API can notify Ldappc of incremental  
> > > > changes to the grouper db (and Ldappc can act on that info),  
> > > > which is one of the next enhancements planned for the API.
> > > >
> > > > Tom
> > > >
> > > > Kathryn Huxtable wrote:
> > > > > I meant to send this to the list as well. -K
> > > > > Begin forwarded message:
> > > > > > *From: *Kathryn Huxtable < <mailto: 
> > > > > > >>
> > > > > > *Date: *April 24, 2008 2:30:35 PM CDT
> > > > > > *To: *Owen Cliffe < <mailto: 
> > > > > > >>
> > > > > > *Subject: **Re: [grouper-dev] ldappc  
> > > > > > edu 
> > > > > > .internet2 
> > > > > > .middleware 
> > > > > > .ldappc.synchronize.GroupEntrySynchronizer.clearRoot()*
> > > > > >
> > > > > > I suppose it could be made optional if there's much demand for  
> > > > > > it.
> > > > > >
> > > > > > At KU, I just put the grouper-generated groups into a separate  
> > > > > > ou from the groups managed by other systems. So they were under
> > > > > >
> > > > > > ou=grouper,ou=groups,dc=ku,dc=edu
> > > > > >
> > > > > > Would that work for you?
> > > > > >
> > > > > > -K
> > > > > >
> > > > > > On Apr 24, 2008, at 7:06 AM, Owen Cliffe wrote:
> > > > > > > I've noticed that ldappc clears the entire provisioned OU of  
> > > > > > > all objects
> > > > > > > which don't match the provisioned groups' object class.  While  
> > > > > > > I can of
> > > > > > > understand the motivation for this, I was wondering if it is  
> > > > > > > absolutely
> > > > > > > necessary, or  it could be made optional.
> > > > > > >
> > > > > > > We have a (possibly unusual)  scenario where we have some LDAP  
> > > > > > > groups
> > > > > > > (which have a different objectClass  to the   ldappc  
> > > > > > > provisioned groups)
> > > > > > > which are managed by a separate system to our grouper maintained
> > > > > > > groups. At present we can't easily migrate the maintenance of  
> > > > > > > these
> > > > > > > groups into grouper (although It's something which we might  
> > > > > > > consider in
> > > > > > > the future).
> > > > > > >
> > > > > > > For historical reasons we would like to preserve these groups  
> > > > > > > under the
> > > > > > > same DN as the grouper provisioned groups.  The only way I've  
> > > > > > > found to
> > > > > > > work around this for now is to comment out the clearRoot()  
> > > > > > > call in
> > > > > > > GroupEntrySynchronizer.initialize().  This doesn't seem to  
> > > > > > > cause any
> > > > > > > problems for us, although I suppose that there is a  risk of a  
> > > > > > > namespace
> > > > > > > clash if a grouper group ends up with the same cn as an  
> > > > > > > existing group,
> > > > > > > this isn't a problem for us as the CNs for the "other" groups  
> > > > > > > cannot
> > > > > > > contain semicolons.
> > > > > > >
> > > > > > > As an aside, I was wondering why ldappc doesn't use a  
> > > > > > > properties file
> > > > > > > like grouper  to configure application-level options on top of  
> > > > > > > the
> > > > > > > ldappc.xml file, it might make adding minor options like this  
> > > > > > > a bit
> > > > > > > easier...
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > --Owen
> > > > > > >
> > > > > > > --Owen Cliffe                    Systems & Networks  
> > > > > > > Administrator
> > > > > > > Bath University Computer Services            University of Bath
> > > > > > > Tel: 01225 386047
> > > > <tbarton.vcf>
> <tbarton.vcf>