Hi.
We have this use case for rehire in which we should be creating a new AD account with new sAMAccountName via attribute generator rule instead of enabling the old AD account from the same source belongs to this user. Can we have input and advice on this matter?
Thank you.
Hello @sjoyee , this is only possible if you could de-link the old AD account from the user’s identity in IDN using correlation rule. Make sure you set a criteria which the new AD account meets and the old one doesn’t.
Do you know any AD attribute which can be used to distinguish an old account from a new account?
Hi Jo,
IdentityNow does not support two accounts in an source. What you could do is on leaver delete its existing account and when the user rejoins create a new account.
Thanks
Rakesh Bhati
Hi Rakesh,
Thank you for the input. Can I know is there any method that we can delete the account in the rule (cloud-executed/connector-executed) ?
Hi Gaurav,
Thank you very much for the input.
Will this correlation rule only works when we try aggregate from the Active Directory (non-authoritative source) ?
You can do this using beforeProvisioning rule. When you configure Disable Account for AD in the Lifecyclestate you can change the operation from Disable to Delete and delete the account in AD.
Hi Rakesh, thank you for the advice. I also read this article stating this option, just a bit of a difference.
Solved: IdentityNow Delete Active Directory Account - Compass (sailpoint.com)
However, the statement of “change operation to Delete” is something I am not familiar of. Can I have some advice on this? Thank you.
You should be able to achieve your requirement by using the before provisioning rule to change the disable operation to delete.
I believe you are disabling accounts in inactive/terminated LCS. IDN will send disable operation to the connector which will generate the provisioning plan and use before provisioning rule to modify the plan so that it will change the disable operation to delete.
Deletion of account is one option for sure.
You can achieve this by using service standard before provisioning rule also.
another option is to change the value of attribute which you are using for correlation is business allows that on disable operation.
Hi Rakesh,
Thank you once again for your input. However, I think in our requirements, we will only choose to delete the previous account if it hits a rehire case (via a flag attribute). We can go with the enable lifecycle state suggested by the article and change operation to delete. But want to reconfirm should the code be like this:
for ( AccountRequest accountRequest : plan.getAccountRequests() ) {
if ( accountRequest.getOp().equals( ProvisioningPlan.ObjectOperation.Enable ) ) {
accountRequest.setOp( ProvisioningPlan.ObjectOperation.Delete );
}
}
Will this delete the previous AD account, and allow the new AD account with new sAMAccountName to be provisioned?
Yes, this will change the operation to delete and delete the AD Account. Once the account is successfully deleted and all dependencies cleared, you should be able to reuse the sAMAccountName.
Hi Sunny,
Thank you for the response. So meaning, after the next identity refresh task runs, then only it will provision a new AD account depending on the latest info from the authoritative source after all role criteria fulfil for that AD source?
Note: We are using role-based provisioning.
Any input if we can directly create a new AD account (could be the same or different sAMAccountName) right after this without any further aggregation / waiting for next refresh afterwards?
Regarding your initial question about rehires and the need for new AD accounts: If the protocol for rehires necessitates the creation of a new AD account, why isn’t the existing account deleted as part of the termination process?
In response to your query, a potential solution could be to implement a process where, upon account deletion, a native rule triggers the execution of a PowerShell script. This script could initiate an identity refresh for the user, thereby eliminating the need to wait for the next scheduled refresh cycle
Hi all,
It seems that when I use this code snippet in the Before Provisioning Rule, it will still enable the account without changing it to Delete operation which is expected to delete the account directly. Appreciate any input on this.
Hi @sjoyee
I see couple of responses and most of them are about deletion. I would like to try below options,
1. Deletion:
Anyway you decided to create new AD account instead of enabling the current one, why don’t you delete AD account during leaver itself using a workflow ? If user comeback, it fall under rehire and you will create new account.
2. Correlation Rule
You can uncorrelate an AD account once it becomes disabled with some more conditions like looking at end date. Then user doesn’t have AD account at all. This needs cloud deployment and it’s not a good approach to use a Rule just for rehire purpose which is very less number of users. Please note that, SailPoint is recommending to avoid depending on the Rules.
3. Multiple Accounts
There is no selector in IDN, so we cannot create multiple Accounts. What if you re-generate values for DN, SamAccountName and try to create new AD account. If native identity is different, by default it should create new account. In case if the operation is not create, try changing the Account Request operation in Before Provisioning Rule. See if that works.
Thanks
Krish
Hi Krishna,
Thank you for your input. Really appreciate it! However, it will be due to business requirements and we will go ahead with deletion when rehire is needed instead.
Just a new update, while testing the “enable converted to delete operation” in before provisioning rule after the new updated rule is deployed, it deletes the AD account directly and provision a new account without needing to trigger a new aggregation / identity refresh, which fulfil our expectation.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.