Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] ldappc-ng and deprovisioning of isMemberOf attribute

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] ldappc-ng and deprovisioning of isMemberOf attribute


Chronological Thread 
  • From: Scott Koranda <>
  • To: Tom Zeller <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] ldappc-ng and deprovisioning of isMemberOf attribute
  • Date: Wed, 6 Apr 2011 11:49:59 -0500

> > Hi,
> >
> > I have ldappc-ng running continuously with these arguments:
> >
> > gsh.sh -ldappcng -bulkSync -interval 180
> >
> > I then removed a subject from group. In LDAP the group's
> > hasMember and member attributes were updated correctly to
> > reflect that the subject was removed from the group.
> >
> > The isMemberOf attribute for the subject's DN, however, has
> > not been appropriately de-provisioned.
> >
> > If I leave ldappc-ng running but fire up another process I can
> > see that it thinks it should be de-provisioned:
> >
> > $:/opt/grouper/grouper# sudo -u tomcat6 ./bin/gsh.sh -ldappcng -diff
> >
> > Using GROUPER_HOME: /opt/grouper/grouper.api-1.6.3
> > Using GROUPER_CONF: /opt/grouper/grouper.api-1.6.3/conf
> > Using JAVA: java
> > using MEMORY: 64m-512m
> > Grouper starting up: version: 1.6.3, build date: 2011/01/28 14:16:16,
> > env: production
> > grouper.properties read from:
> > /opt/grouper/grouper.api-1.6.3/conf/grouper.properties
> > Grouper current directory is: /opt/grouper/grouper.api-1.6.3
> > log4j.properties read from:
> > /opt/grouper/grouper.api-1.6.3/conf/log4j.properties
> > Grouper logs are not using log4j: class
> > org.apache.commons.logging.impl.SLF4JLocationAwareLog
> > grouper.hibernate.properties:
> > /opt/grouper/grouper.api-1.6.3/conf/grouper.hibernate.properties
> > grouper.hibernate.properties:
> > grouper@jdbc:mysql://localhost:3306/grouper
> > sources.xml read from:
> > /opt/grouper/grouper.api-1.6.3/conf/sources.xml
> > sources.xml groupersource id: g:gsa
> > sources.xml jndi source id:   ligo:
> > uid=grouper,ou=system,dc=ligo,dc=org@ldap://ldap-test.ligo.org
> > <ldappc:diffResponse
> > xmlns:ldappc='http://grouper.internet2.edu/ldappc'
> > status='success' requestID='2011/04/05-20:26:26.877_QWFZE3IS'>
> >  <modifyRequest xmlns='urn:oasis:names:tc:SPML:2:0'
> > entityName='member'
> > requestID='2011/04/05-20:26:27.095_QWFZE3I0'
> > returnData='everything'>
> >    <psoID ID='employeenumber=882,ou=people,dc=ligo,dc=org'
> > targetID='ldap'/>
> >    <modification modificationMode='delete'>
> >      <dsml:modification
> > xmlns:dsml='urn:oasis:names:tc:DSML:2:0:core'
> > name='isMemberOf' operation='delete'>
> >        
> > <dsml:value>Communities:LVC:LSC:MOU:UWM:UWMGroupMembers</dsml:value>
> >      </dsml:modification>
> >    </modification>
> >  </modifyRequest>
> >  <ldappc:id
> > '/>
> > </ldappc:diffResponse>
> >
> > But after watching 5 cycles go by for the ldappc-ng running
> > with interval 180 I still do not see the isMemberOf attribute
> > being deprovisioned:
> >
> > $ ldapsearch -x -LLL -b "dc=ligo,dc=org" -H ldap://ldap-test.ligo.org
> > "(uid=scott.koranda)" isMemberOf | grep UWMGroupMembers
> > isMemberOf: Communities:LVC:LSC:MOU:UWM:UWMGroupMembers
> >
> > In ldappcng.xml I have this for object 'member':
> >
> >    <object id="member">
> >      <identifier ref="member-dn" baseId="${peopleOU}">
> >        <identifyingAttribute name="objectClass" value="person" />
> >      </identifier>
> >      <attribute name="objectClass" ref="member-objectclass"
> > retainAll="true" />
> >      <attribute name="isMemberOf" ref="memberIsMemberOf" />
> >    </object>
> >
> > Any ideas?
>
> Bug. The -interval option selects groups that have been changed during
> the specified interval for provisioning as well as their members. If a
> member has been removed, it is no longer considered for provisioning.

Thanks for the update.

>
> I see 3 options :
>
> 1. support incremental provisioning (we are actively figuring this
> out, no code yet)
> 2. When using -interval, do a full sync at some configurable interval, say
> 24h
> 3. support Member.lastModifyTime (and Stem.lastModifyTime, etc)

Unfortunately since we use isMemberOf attributes on users for
important authorization decisions I cannot have a latency of
24 hours. I really need an operational latency of < 15 minutes.

>
> I think #2 might be realistic in the short term.

Is there any path forward that could get me a latency of < 15
minutes in the short term other than running a full sync
(which takes just about 15 minutes for us) in the next few
days?

Or do I have to revert back to ldappc (no ng) for the time
being? Can that be done with Grouper 1.6.3?

Thanks,

Scott




Archive powered by MHonArc 2.6.16.

Top of Page