I’ve got proxyAddress to work in the CREATE rule, but I also need it to work in the UPDATE function. However, the problem is that the address has a $uniqueCounter field which is present in the CREATE but not the UPDATE, and the UPDATE occurs immediately after the CREATE meaning two sets of values are being populated.
ie:
Is there a way to prevent the UPDATE function from running after the CREATE, because this is the cause of the problem.
If not, I think that I’m going to have to remove it from the UPDATE and write an afterModify rule instead
Hi @ashutosh08 ,
Its triggering at the end of the create the process, which seems odd, and not something that I would expect to be happening.
These are the last four actions in the Create process
Add msDS- is a create process
Add proxyAddress is a create(79@ values) & an update (69@ values) process
Add uid - is a create process
Add AC_NewParent is an update process
I have seen this behavior, if the identity has the role then the identity refresh task happens periodically and triggers the update operation.
This could also be happening because of single account aggregation that takes place after the creation of the user in target application.
Is there a particular reason for which you have proxy address in update provisioning policy, normally this does remain static for the user unless there are scenarios like rehire where email and proxy addresses needs to be regenerated.
For these scenarios where proxy address needs to be regenerated, i would suggest to handle it in before provisioning rule where you can identify whether the user needs new email or proxy address and then only include in the provisioning plan.
If before provisioning rule is not the solution for you then you can use after modify script to handle proxy addresses via powershell script. For this you can handle it for both create and modify operation and just add the proxy address attribute excludeFromProvisioning block in the AD source and then handle it completely from powershell script.
Including this attribute in UPDATE provisioning policy will anyways try to modify it for all the users on each identity refresh and may have performance impacts.
I hope this helps. If you have more queries, please let us know.
I was checking and it seems to be default behavior where your account is created with few attributes and then for other attribute it seems to be pushed via update operation.
How you are trying to use “$uniqueCounter” and what is the error that you are getting?
Hi @vguleria,
The client has over 1200 email domains, and movement between entities (and multiple entities) is expected on a frequent and regular basis. Hence the need to update proxy addresses for each move - this is also the reason why ‘AC_NewParent’ is in the update profile as moves might happen without the lifecycle state changing.
I’ve started looking at writing a beforeProvisioning rule, but I might have to revert to expert Services for that as its not a strong point with me
Hi @ashutosh08,
$uniqueCounter only goes as far as 50 and this is a Sailpoint hard limit.
However, the client wants to have a 3 digit number on the end of the prefix, and the only way I could see to do this was to add a random 2 digit number, then apply the $uniqueCounter to create the sAMAcccoutName. This works perfectly inside the create profile, but when the update profile runs for the first time, the values have not yet been set inside the identity, so the prefix transform generates another random 2 digit number, (as can be seen with the ‘79’ and ‘69’ values).
Yes, then it make sense to try to cover this logic in before provisioning rule. Ideally, i believe you should then cover account move, email regeneration and proxy addresses in before provisioning rule as that would be the ideal scenario.
The after modify rule is also another approach but then you will need to write the powershell script and still might need some attributes to be included into the provisioning plan to perform the checks in ps script.
So, it will be better to align with Expert services, as they can suggest other approach as well by looking into your system and use case.
For any future people. This issue was resolved by putting in a check that the AD account was on the cube, and only running the UPDATE if it is present:
