Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] ldappcng de-provisioning of stems

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] ldappcng de-provisioning of stems


Chronological Thread 
  • From: Scott Koranda <>
  • To: Tom Zeller <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] ldappcng de-provisioning of stems
  • Date: Fri, 8 Apr 2011 13:42:09 -0500

> > Hi,
> >
> > In Grouper I deleted a stem and waited a full ldappc-ng
> > synchronization cycle and did not see the stem de-provisioned
> > from LDAP.
> >
> > So I edited ldappcng.xml and added the 'authoritative="true"'
> > attribute to the <object id="stem"> element. I then ran
> > another full synchronization and the stem was de-provisioned.
> >
> > I did, however, see this in the log file:
> >
> > 2011-04-08 12:56:48,572: [Timer-2] ERROR LdapTargetProvider.execute(341)
> > -  -
> > DeleteResponse[status=failure,error=customError,errorMessages={[LDAP:
> > error code 66 - subordinate objects must be deleted
> > first]},requestID=2011/04/08-12:56:48.533_QWJN5A99]
> >
> > and this in the stdout/stderr:
> >
> > <ldappc:syncResponse>
> >    <deleteResponse xmlns='urn:oasis:names:tc:SPML:2:0' status='failure'
> > requestID='2011/04/08-12:56:48.533_QWJN5A99' error='customError'>
> >      <errorMessage>[LDAP: error code 66 - subordinate objects must be
> > deleted first]</errorMessage>
> >    </deleteResponse>
> >    <ldappc:id ID='ou=grouper,dc=ligo,dc=org'/>
> > </ldappc:syncResponse>
> >
> > So it appears that ldappc-ng is attempting to delete the DN
> >
> > ou=grouper,dc=ligo,dc=org
> >
> > That is the DN where all of the Grouper groups and stems as
> > provisioned into LDAP are rooted. For example, the Grouper
> > group
> >
> > Communities:LSCVirgoLIGOGroupMembers
> >
> > is provisioned (as I want) as
> >
> > cn=LSCVirgoLIGOGroupMembers,ou=Communities,ou=grouper,dc=ligo,dc=org
> >
> > In ldappcng.xml my stem provisioning configuration looks like
> > this:
> >
> >    <object id="stem" authoritative="true">
> >      <identifier ref="stem-dn" baseId="groupsOU}">
> >        <identifyingAttribute name="objectclass"
> > value="organizationalUnit" />
> >      </identifier>
> >      <attribute name="objectClass" ref="stem-objectclass" />
> >      <attribute name="ou" ref="stem-ou" />
> >      <attribute name="description" ref="stem-description" />
> >    </object>
> >
> > and in ldappc.properties I have
> >
> > $ grep groupsOU conf/ldappc.properties
> > groupsOU=ou=grouper,dc=ligo,dc=org
> >
> > In ldappc-resolver.xml I have
> >
> >  <resolver:DataConnector id="StemDataConnector"
> > xsi:type="grouper:StemDataConnector">
> >    <grouper:GroupFilter xsi:type="grouper:StemName" name="Communities"
> > scope="SUB" />
> >  </resolver:DataConnector>
> >
> > How can I get ldappc-ng to not want to de-provision
> > ou=grouper,dc=ligo,dc=org ?
> >
> > Thanks,
> >
> > Scott
>
> Should Scott get this week's bug-finder-award ?

I do what I can. ;-)

Thanks for continuing to read my email...

> Do not be
> authoritative for stems, for now. Ordering is important.
>
> [1] https://bugs.internet2.edu/jira/browse/GRP-597

So OpenLDAP will not, of course, allow ldappcng to do the
delete on the DN (and our ACLs also would not allow it), so
there is no risk from that particular action I believe.

Is there any other risk or can I leave the
'authoritative="true"' attribute and just live with the error
message for now?

Thanks,

Scott

P.S. I can also live for now without de-provisioning empty
stems since the stems are not used for any authorization.



Archive powered by MHonArc 2.6.16.

Top of Page