Hi all. In one of our use cases, it is required to create a brand new account using a new sAMAccountName to be provisioned in AD source when this user is rehired (same identity).
During a rehire LCS, it was set to Create Operation during enable operation in the Before Provisioning Rule. However, it will be trying to create the same account in the AD that was disabled previously during offboarding and thus throwing errors since this sAMAccountName is already existing in AD.
I wanted to seek input on any possibility to create a new account using the full Create Account Provisioning Policy in the Before Provisioning Rule. Or this can only be done when the account in the AD source is uncorrelated? Any way to remove the account (not deleting in target system) in the BP rule instead of the Correlation Rule?
Hi @sjoyee
Can you provide some more context on what exactly you’re trying to achieve here? If as part of rehire, you’re providing a new account in AD, why not just delete the account when user terminates? That way you won’t run into the issue of finding an account with the same sAMAccountName in the first place. You can send out a delete account plan when your user moves to a specific lifecycle state, like ‘terminated’ through a before provisioning rule. (Send it as Disable from the LCS settings, but in before provisioning, switch it to Delete if the lifecycle state is ‘terminated’ and you have some more HR factors to confirm on the user’s identity, like HR status.)
But if you want to retain that old account on AD, and still be able to create a new one when users are rehired, then move that old account on termination to an OU that IDN does not see, i.e. set an aggregation filter to exclude that terminated users OU. That way, when your user account moves to that OU during termination, upon next scheduled aggregation, the account would no longer show up correlated to the identity. That way on rehire, you will be able to create a new account.
However, I’d not recommend the second approach as you’re creating duplicate accounts, but you can take a call on what’s best for your specific case.
Thank you for your input. It is our policy to not delete accounts and only disable the accounts during offboard. Not to focus on just the rehire use case, during offboarding, we want to remove the account (uncorrelate) from the identity, the only way to be done is through correlation rule? Or it will be possible via BP rule?
As for your second suggestion, we should aggregate the users reside in disabled OU into IDN as well for records, so we would not be able to take this option.
I see that deleting AD account is not an option for you.
If you maintain multiple accounts from same source in an identity, then you need to update all Transforms in selecting the correct account. So you need to use accountFilter or accountPropertyFIlter in your transforms. Please note this.
What if you update the value for attribute you used in AD correlation, then it will automatically uncorrelate ?
In your rehire LCS, you might have selected enable AD source and trying to manipulate that plan in BP Rule.
For enable operation account request, change it to modify and update the value of attribute used in correlation, appending _old something like that. See if it can be feasible.
If appending correlation attribute value is not a feasible option, then just change the operation to disable instead of enable, so that old account remains disabled.
Add one more account request for this operation, calculate unique values for SamAccountName, Email and UPN. it should create an additional account.
For #3, can I know how do we add another account request, where the sAMAccountName and email are generated using cloud executed Attribute Generator rule? Does this mean once another account request is added under this operation, it will go through the provisioning policy and create another account in the same source?