Grouper Users - Open Discussion List

[Dominique Petitpierre <>]

Hello,

On 21.09.20 16:59, Jeffrey Williams wrote:

What baffles me is that it looks like since that patch was released in June 2019 only one other person reported the problem (cf. https://todos.internet2.edu/browse/GRP-2343):
- Is PSPNG used with Active Directory in "production" environments?

 

We have been using PSPNG since we upgraded to 2.3.  We went to 2.4 not long after its release.  We've been able to provision 1500+ member groups to AD targets without any issues the entire time(up to our population size ~30k).  Since it is how we license MS products to our FacStaff and student populations, it's a solid bet someone would have spoke up if  we were only licensing ~5% of everyone ☺.

You can see in the log extract of my second post on that subject (https://lists.internet2.edu/sympa/arc/grouper-users/2020-09/msg00039.html) that the LDAP error is not fatal and the syncing continues without problems if there is truly nothing to synchronize.
In other words, if the incremental synchronization of a group worked properly, the full sync should have nothing to do, but, because of the bug, the provisioner deduces that  the group is empty (Correct/Actual: 1502/0) and tries to add all the members again (ADD 1502 member values) and that operation fails (ENTRY_ALREADY_EXISTS). Since that failure is not fatal it continues and checks the content of the group again with another method that is not bugged, and finds that it is OK (Values on server already 1502) and concludes that the supposedly missing members have been inserted (Stats: ins=1502, which is wrong since the insertions were not necessary). So in that case the bug has no effect on content just on performance because it causes extra operations.

So when the full sync has nothing to do there is no bad consequences.
But if you stop the loader process, remove a member from the group in Grouper, and start "manually" a full sync, then, because of the bug that member will not be removed from the target directory group. In that case (i.e. a change that incremental synchronization did not handle) I believe it is the same problem that Wenlai Wang  reported in https://todos.internet2.edu/browse/GRP-2343: "members never get delete from target system".

So that might be why people have not noticed: incremental synchronization was doing the job, not the full sync.

Can you post a sanitized version of your grouper-loader.properties?

You'll find the effective settings in my second post on that subject:
https://lists.internet2.edu/sympa/arc/grouper-users/2020-09/msg00039.html

Also, have you tried provisioning a 1500+ group using the example config? https://spaces.at.internet2.edu/display/Grouper/Grouper+Provisioning:+PSPNG#GrouperProvisioning:PSPNG-ACTIVEDIRECTORYGROUPS

I have spent the last four days on this issue, and I came to the conclusion that it is not a problem of configuration but it is a bug:
Could you please have a look at the evidence that I provided in https://lists.internet2.edu/sympa/arc/grouper-users/2020-09/msg00042.html ?

I.e. Isn't that line of code a bug?: i.e. it replaces the just set RangeEntryHandler needed for Active Directory by something else.
https://github.com/Internet2/grouper/blob/grouper_2_4_0-a95-u57-w11-p12/grouper-misc/grouper-pspng/src/main/java/edu/internet2/middleware/grouper/pspng/LdapSystem.java#L744

And you can see its effect in the provided log:

searchEntryHandlers=[]

occurring when the bugged performLdapSearchRequest does the request which causes the list of member to be empty ([member[]),
instead of

searchEntryHandlers=[org.ldaptive.ad.handler.RangeEntryHandler@17257]

occurring when the non bugged method performLdapRead does the request.

Regards.

-- 
Mr Dominique Petitpierre, user=Dominique.Petitpierre domain=unige.ch
IT Division, University of Geneva, Switzerland