We are currently evaluating controls in SailPoint Identity Security Cloud (ISC) to reduce the risk of mass‑mutations to Active Directory caused by misconfigurations, bad input data, or faulty aggregation / provisioning logic.
Is there a way in SailPoint ISC to detect and block provisioning runs that would cause a large number of changes (e.g. more than 50 writes?) to Active Directory?
Can ISC require an approval or automatically fail a job if a provisioning operation exceeds a defined change threshold?
Is it possible to prevent null/ empty values from being written to critical AD attributes such as userPrincipalName?
If ISC has no native protection for this (I think that it does not), what are the recommended best‑practice patterns to avoid accidental mass‑mutations in AD?
Normally mass-write actions happen due to bad Role setup or bad Transform logic. Two tips:
Deploy your roles in Sandbox as they will exist in PROD so you can identify this early
Run a search query for your Role assignment criteria to determine who will get the role and make sure it looks ok
For Transforms, don’t enable attribute sync until you’ve done a ‘Calculation’ on the attribute.
Once it’s sent out, it’s nearly impossible to roll back. Better to be sure that you have your ISC config set up correctly before you start provisioning.
I’m with you - having a “breaker” that prevents updates beyond a certain number or percentage would be ideal. It’s available for preventing deletion of source accounts in ISC, but not for attribute changes or role syncs. That’s why tools like these have been created:
The attribute sync preview does not require that the sync be enabled, it just has to be mapped in the create profile. Run the script and it will show you which accounts will be updated. This is helpful when you make changes and want to be safe before turning on new configurations in prod.
However, what this still does not solve is the potential for source data issues (i.e., suddenly getting an empty job title on every record, or something similar) that get propagated to target systems. It’s just not a supported feature in the SP connectors.
You can also enable the role with just the assignment criteria first and no access assigned to ensure the people you expect to get it assigned actually do
Yes I completely agree with what you’ve written here - most specifically what happened to me was an error in the cloud-rule, it seems that it behaved differently in Prod to Sandbox (currenlty investigating with SP), even though the given values are the same.. But yeah in the end, I think that the safeguard was to not have attribute-sync enabled at that time.
What Matt wrote is also what I thought was interesting - for aggregation/ account deletion, there is a safeguard so I thought perhaps there may be something for attribute sync as well. I once heard that in IIQ there was this feature (but I never used IIQ so I don’t know if it’s true!).
Also fine for me. Seems there aren’t really technical safeguards beyond using sandbox environment first, as well as disabling attribute-sync when there could be changes to attributes (such as changing transform, or changing cloud-rule). Of course also verification using the identity profile page. These safeguards should be enough!
Thanks everyone for your inputs and best wishes,
Oliver