If there are too many objects changing during provisioning, maybe that is a sign that things are going rogue and should not proceed. Note: totals are based on total provisionable objects.
There are two things to prevent when it comes to provisioners going rogue
- Deleting objects that shouldn't be
- Changing attributes that it shouldn't
There are global defaults for all provisioners
grouper-loader.properties
# if more than this percent of groups are updated or deleted in one sync, then do not proceed. If -1, remove failsafe provisionerDefault.failsafe.maxUpdateOrDeleteGroupsPercent = 20 # if more than this percent of entities are updated or deleted in one sync, then do not proceed. If -1, remove failsafe provisionerDefault.failsafe.maxUpdateOrDeleteEntitiesPercent = 20 # if more than this percent of memberships are updated or deleted in one sync, then do not proceed. If -1, remove failsafe provisionerDefault.failsafe.maxUpdateOrDeleteMembershipsPercent = 20
There are local settings for each provisioner including "allow" for a certain date
# if more than this percent of groups are updated or deleted in one sync, then do not proceed. If -1, remove failsafe provisioner.myLdap.failsafe.maxUpdateOrDeleteGroupsPercent = 20 # if more than this percent of entities are updated or deleted in one sync, then do not proceed. If -1, remove failsafe provisioner.myLdap.failsafe.maxUpdateOrDeleteEntitiesPercent = 20 # if more than this percent of memberships are updated or deleted in one sync, then do not proceed. If -1, remove failsafe provisioner.myLdap.failsafe.maxUpdateOrDeleteMembershipsPercent = 20 # if there is a date configured, allow changes to be made on this date. If -1, remove failsafe. This is how someone would approve # a large number of changes to happen after they have failed. Or they could set the percentages temporarily to 100 or -1 provisioner.myLdap.removeFailsafeOnDateYYYYMMDD =