Grouper Users - Open Discussion List

[Marwan Shaher <>]

Michael,
Thank you for your reply. Yes, it was helpful. With 
grouperIsAuthoritative set to TRUE, the deleted groups that have/had 
members are now getting deleted from the resource after the full sync 
runs. So the results for Tests # 2,3, and 4 that I explained in my email 
are a SUCCESS with a full sync run.
Test # 5 is a SUCCESS as well, with just a regular loader run and 
without a full sync run.
For those interested, in our environment, since we have a plugin to 
check for the group name uniqueness in the whole resource before 
creating the group, this means letting our end users know and/or running 
the PSPNG full sync job more often if the need to reuse deleted group 
names "soon" after deletion.

Thanks,

- Marwan

On 02/15/2017 07:53 AM, Michael R Gettes wrote:
> As I continue to pursue my issues I read the following which might help
> explain some of yours.
>
> in the spreadsheet showing the various settings:
>
> https://docs.google.com/spreadsheets/d/1FenN3hICohYR6cvr8Zxuk11VNyt82clvuouZQHgTT-w/edit#gid=0
>
> the default behavior described for the allGroupSearchFilter says “Groups
> are not removed when they are removed from Grouper nor when they no
> longer match the groupSelectionExpression”.  In Description it says
> “FUTURE: How to find all the groups that grouper-proviisioning
> maintains.  If <grouperIsAuthoritative>, then groups found via this
> filter will be removed during a full sync.
>
> What’s interesting to me is if “grouperIsAuthoritative” is true (default
> is false), then why does one need to set the allGroupSearchFilter at
> all?  The default for the filter is null.
>
> I hope this helps.
>
> /mrg
>
> > On Feb 14, 2017, at 3:53 PM, Marwan Shaher 
> > <
> > <mailto:>>
> >  wrote:
> >
> > Hello All,
> > We are experiencing a weird behavior when it comes to deleting groups
> > with PSPNG. More specifically, groups that have members or have had
> > members at any point are not getting deleted from the resource when
> > deleted in Grouper. At first, we suspected it was an Active Directory
> > issue. Then, we pointed Grouper to provision to an LDAP directory
> > where we could review the logs easily on the LDAP side, and we are
> > experiencing the same behavior. We are on the latest API and PSPNG
> > patches as of today. We are wondering if anyone has experienced
> > anything similar, or if this could be specific to our environment.
> > We've tested it with both flat and bushy structures, as well as using
> > group full names instead of group extensions in the group creation
> > ldif template, with similar results.
> > My apologies in advance for the long email, but here are the
> > configuration settings and scenarios we followed with the results:
> >
> > --Begin: PSPNG settings --
> > changeLog.consumer.pspng_LDAP.quartzCron = 0 * * * * ?
> > changeLog.consumer.pspng_LDAP.ldapPoolName = PSPLdap
> > changeLog.consumer.pspng_LDAP.isActiveDirectory = false
> > changeLog.consumer.pspng_LDAP.memberAttributeName = uniqueMember
> > changeLog.consumer.pspng_LDAP.memberAttributeValueFormat =
> > ${ldapUser.getDn()}
> > changeLog.consumer.pspng_LDAP.groupSearchBaseDn =
> > ou=Groups,dc=colorado,dc=edu
> > changeLog.consumer.pspng_LDAP.allGroupsSearchFilter =
> > objectclass=groupOfUniqueName
> > changeLog.consumer.pspng_LDAP.singleGroupSearchFilter =
> > cn=${grouperUtil.extensionFromName(name)}
> > changeLog.consumer.pspng_LDAP.groupCreationLdifTemplate = dn:
> > cn=${grouperUtil.extensionFromName(name)}||cn:
> > ${grouperUtil.extensionFromName(name)}||objectclass: groupOfUniqueNames
> >
> > changeLog.consumer.pspng_LDAP.userSearchBaseDn = dc=colorado,DC=EDU
> > changeLog.consumer.pspng_LDAP.userSearchAttributes = displayName,
> > cuAccountUniqueID, displayName, uid, givenname, sn, dn
> > changeLog.consumer.pspng_LDAP.userSearchScope = SUBTREE
> > changeLog.consumer.pspng_LDAP.userSearchFilter =
> > cuaccountuniqueid=${subject.id}
> > --End: PSPNG settings --
> >
> > - In Grouper we created 5 groups: Test20170214_01 through Test20170214_05
> > - Test20170214_01 & Test20170214_05 are left empty, and the rest with
> > a couple of members added to them.
> > - On the resource side (LDAP or AD), the groups are getting created
> > successfully, mirroring the Grouper side. This by the way happens via
> > "provision_to" attribute-based definition on a folder/stem in Grouper.
> >
> > - Test # 1: Deleted the empty group Test20170214_01 in Grouper
> > -- Begin: Test #1 LDAP log ---
> > on the resource:
> > [14/Feb/2017:10:17:00 -0700] SEARCH REQ conn=9160 op=20 msgID=21
> > base="" scope=base filter="(objectClass=*)" attrs="1.1"
> > [14/Feb/2017:10:17:00 -0700] SEARCH RES conn=9160 op=20 msgID=21
> > result=0 nentries=1 etime=0
> > [14/Feb/2017:10:17:00 -0700] DELETE REQ conn=9160 op=21 msgID=22
> > dn="cn=test20170214_01,ou=groups,dc=colorado,dc=edu"
> > [14/Feb/2017:10:17:00 -0700] DELETE RES conn=9160 op=21 msgID=22
> > result=0 etime=10
> > -- End: Test #1 LDAP log ---
> > Result: SUCCESS. Test20170214_01 is deleted from LDAP
> >
> > - Test # 2: Deleted Test20170214_02 in Grouper without first removing
> > the members from the group
> > -- Begin: Test #2 LDAP log ---
> > [14/Feb/2017:10:19:59 -0700] SEARCH REQ conn=9160 op=22 msgID=23
> > base="" scope=base filter="(objectClass=*)" attrs="1.1"
> > [14/Feb/2017:10:19:59 -0700] SEARCH RES conn=9160 op=22 msgID=23
> > result=0 nentries=1 etime=0
> > [14/Feb/2017:10:19:59 -0700] SEARCH REQ conn=9160 op=23 msgID=24
> > base="ou=Groups,dc=colorado,dc=edu" scope=sub
> > filter="(|(cn=Test20170214_02))"
> > attrs="cn,gidNumber,samAccountName,objectclass"
> > [14/Feb/2017:10:19:59 -0700] SEARCH RES conn=9160 op=23 msgID=24
> > result=0 nentries=1 etime=1
> > -- End: Test #2 LDAP log ---
> > Result: FAILURE. Test20170214_02 is not deleted from LDAP. Please note
> > that there was never a "DELETE" operation in the LDAP logs, even
> > though the SEARCH operation had a hit "nentries=1" .
> >
> > - Test # 3: Deleted Test20170214_03 in Grouper by first removing all
> > the members from the group. Waited for the loader to run a few times,
> > then deleted the group in Grouper.
> > -- Begin: Test #3 LDAP log ---
> > [14/Feb/2017:10:34:59 -0700] SEARCH REQ conn=9160 op=30 msgID=31
> > base="" scope=base filter="(objectClass=*)" attrs="1.1"
> > [14/Feb/2017:10:34:59 -0700] SEARCH RES conn=9160 op=30 msgID=31
> > result=0 nentries=1 etime=1
> > [14/Feb/2017:10:34:59 -0700] SEARCH REQ conn=9160 op=31 msgID=32
> > base="ou=Groups,dc=colorado,dc=edu" scope=sub
> > filter="(|(cn=Test20170214_03))"
> > attrs="cn,gidNumber,samAccountName,objectclass"
> > [14/Feb/2017:10:34:59 -0700] SEARCH RES conn=9160 op=31 msgID=32
> > result=0 nentries=1 etime=1
> > -- End: Test #3 LDAP log ---
> > Result: FAILURE. The members are removed from the LDAP group
> > successfully making the group empty again. However, the group is not
> > deleted from LDAP. Again, please note that there was never a "DELETE"
> > operation in the LDAP logs, even though the SEARCH operation had a hit
> > "nentries=1" .
> >
> > - Test # 4: Deleted Test20170214_04 in Grouper by first removing the
> > members and then deleting the group. This is similar to Test # 3,
> > except that here the membership removal and the group deletion are
> > processed in the same loader run.
> > -- Begin: Test #4 LDAP log ---
> > [14/Feb/2017:10:37:00 -0700] SEARCH REQ conn=9160 op=32 msgID=33
> > base="" scope=base filter="(objectClass=*)" attrs="1.1"
> > [14/Feb/2017:10:37:00 -0700] SEARCH RES conn=9160 op=32 msgID=33
> > result=0 nentries=1 etime=1
> > [14/Feb/2017:10:37:00 -0700] SEARCH REQ conn=9160 op=33 msgID=34
> > base="ou=Groups,dc=colorado,dc=edu" scope=sub
> > filter="(|(cn=Test20170214_04))"
> > attrs="cn,gidNumber,samAccountName,objectclass"
> > [14/Feb/2017:10:37:00 -0700] SEARCH RES conn=9160 op=33 msgID=34
> > result=0 nentries=1 etime=1
> > -- End: Test #4 LDAP log ---
> > RESULT: FAILURE. The group is not deleted in LDAP. The members are
> > also NOT removed from the group in LDAP. Again, please note that there
> > was never a "DELETE" operation in the LDAP logs, even though the
> > SEARCH operation had a hit "nentries=1"
> >
> > - Test # 5: Deleted Test20170214_05 in Grouper.
> > -- Begin: Test #5 LDAP log ---
> > [14/Feb/2017:10:48:00 -0700] SEARCH REQ conn=9160 op=34 msgID=35
> > base="" scope=base filter="(objectClass=*)" attrs="1.1"
> > [14/Feb/2017:10:48:00 -0700] SEARCH RES conn=9160 op=34 msgID=35
> > result=0 nentries=1 etime=1
> > [14/Feb/2017:10:48:00 -0700] SEARCH REQ conn=9160 op=35 msgID=36
> > base="ou=Groups,dc=colorado,dc=edu" scope=sub
> > filter="(|(cn=Test20170214_05))"
> > attrs="cn,gidNumber,samAccountName,objectclass"
> > [14/Feb/2017:10:48:00 -0700] SEARCH RES conn=9160 op=35 msgID=36
> > result=0 nentries=1 etime=0
> > -- End: Test #5 LDAP log ---
> > Result: FAILURE. Test20170214_05 is not deleted from LDAP. This is an
> > empty group that never had members added to it just like Test20170214_01.
> > In other tests we conducted, empty groups are getting deleted from the
> > resource successfully as long as
> > 1- the group never had members added to it at any time
> > 2- between the group creation and deletion, no other group with
> > members was deleted.
> >
> > In all test cases above, there were no errors or warnings in the
> > Grouper logs.
> >
> > Thanks,
> >
> > Marwan