| 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:
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 <> 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
|
