I am sure this wont be the first time you hear about this but we have a client requirement to move accounts based on lifecycle states. According to best practises, Best Practices: Active Directory Account Moves - Compass , we are supposed to be using a Before Provisioning Rule to move OUs. One potential drawback on this approach is that if we ever need to update or troubleshoot, our new iterations will have to go through the verification process.
In that same post Sailpoint recomments using Before Provisioning Rule over the Account Profile route, which includes adding the AC_NewParent in the UPDATE provisioning policy and attaching it to an identity attribute.
My question is, why does Sailpoint advices against the Account Profile solution? Looking at the suggested rule, after of course performing the newOU calculations which if complicated are easier done in a rule, it comes down to this line ( if I am oversimplifying it please let me know ) :
Unless I am horribly mistaken when we are updating attributes we indeed creating a new ProvisioningPlan which also adds AC_NewParent in this case. Why is Sailpoint against using the UPDATE Provisioning Policy route? Seems easier and more logical especially if your required calculations are not complicated.
Can we have more explanation on the following part from the Best practices post? I assume this is the argument but I don’t fully understand it.
" It is not recommended to go through the account profiles because attributes set there go through a verification stage after provisioning. Since AC_NewParent and AC_NewName are not read via the connector, they can never be verified. This results in “stranded” account activity entries within the IdentityNow tenant. "
Hi Spyros - this is a great question! This recommendation from SailPoint is because of the verification of provisioning activities. Let me expand on the quote you had.
AC_NewParent is not a verifiable attribute. This is because it’s not in the schema as something it’s tracking, AC_NewParent goes to the connector to perform the moves.
“stranded” account activity entries - Because IDN uses the DN as the account ID attribute - changing the AC_NewParent will functionally be treated as a new/different account.
Verification stage - the connector is going to read accounts to verify its provisioning activities occurred, but if the change we’re making results in a technically new account, we can’t verify this attribute change on the original step.
Now we have had some changes that improve AC_NewParent functionality at least, but they don’t fully address the above items.
“CONETN-4261 -The Active Directory connector now instantly returns the Resource Object to IdentityNow on any OU changes done by the AC_New Parent, which can be further utilized to any rule to work with the updated Resource Object data values.”
All in all - I would recommend using the Standard Services Before Provisioning rule so you can make changes without having to submit more rule reviews.
In my understanding is not 100% reliable so while it does work it is not guaranteed to work especially under heavy workload. That’s fair. I assume it can still be used as a last measure if you need to change some accounts but again that is a very special case which can also be done manually on the target system anyway.
Can you please elaborate a bit on the “Standard Services Before Provisioning rule” part? Is there a different process to update the rule once deployed? It is an AD OU move so once configured I wouldn’t expect many changes, if any, but at least during initial testing/prototyping it will be beneficial if we can speed up the process like you mention. I was under the impression that the rules must be resubmitted each time. Maybe there is an API call to simulate its behaviour like there is one for filters?
It’s reliable to use the account profile - but you’re going to have distracting information or warnings from the “stranded” account activity entries since verification will not be possible.
The Standard Services Before Provisioning rule is a rule developed by SailPoint PS that allows you to modify configuration on the source configuration. So if you want to change what OUs it’s being moved to, you can update sources & transforms instead of rules. The rule itself reads the configuration on the application source object. You can have SailPoint deploy this to your tenant through a CS tenant and they can provide the documentation.
Ok thanks for the additional information. We must examine our options. If I need more assistance I will either post in forums or reach support directly. Again thanks for the clarifications
