We have a requirement where we have to remove multiple accounts of a user based on a single authoritative source feed. E.g. User1 has to remove two accounts - AD1 and AD2, while all other accounts of the user remains untouched.
Via the workflow approach, we are unable to remove the birthright roles for AD accounts.
Thus, we wanted to check if its possible to use lifecycle state to achieve this. Here is a thought - we create LCS1 to disable AD1 account and LCS2 to AD2 account. However the question is , how to invoke/trigger both LCS1 and LCS2 sequentially ?
I did not get LC1 and LC2 to invoke sequentially. Is that also a requirement to disable them sequentially?
One of the approaches we follow to manage multiple accounts from the same source, we split AD sources into two sources. If you can differentiate AD1 and AD2 based on AD attributes
You can filter them in source configuration and aggregate only AD1 and AD2 accounts.
Keep all other accounts you don’t want to touch in a different source.
Or You can have 3 sources and aggregate AD1, AD2, and other ADX accounts.
This will help you configure LCS states only for AD1 and AD2 without impacting any other accounts.
We can disable accounts, not delete/remove. Currently IDN doesn’t support account deletion even workflows doesn’t support. Delete Account supports only for delimited sources.
What is your requirement, delete or disable ? before looking further.
Can you provide some background on under what circumstances you want to disable the accounts in AD1 and AD2? If you can relate it to a date, then you can create a transform that will compare the specific date to current date and return LC1 or LC2. e.g. return LC1 after 1 day and LC2 after 2 days
yes, the requirement is to disable them one by one.
Yes we have 2 different AD sources and we are already doing it.
My question is - is there a way to dynamically pass in the accounts to be removed in LCS state? What I mean is, can I take the AD account to be removed as input from the authoritative source feed dynamically and only disable that particular AD account.
Our requirement is to dynamically deprovision accounts. E.g if the authoritative source feed requests to deprovision AD1, we only want to deprovision AD1 and so on.
For this, we wanted to explore if we can use LCS. The reason being that workflows have their own limitations. Our requirement for AD deprovisioning is that the user must be moved to Disabled OUs, the user account is set as disabled (IIQDisabled = true) , and all entitlements (including birthright are removed). With workflows we see below challenges -
We cannot remove BR roles/access profiles/entitlements. Manage Access action throws error when removing BR roles/access profiles/entitlements.
Unable to move user account to disabled OU
We already have LCS state configured to fulfil all deprovisioning requirements mentioned above and hence we wanted to reuse that.
However with LCS approach, the challenge we are facing is , e.g. a user has 3 target accounts - AD1 , AD2 and targetSystem1. Say the authoritative source feed only indicates to remove AD1 and AD2, how to invoke LCS in a way that only AD1 and AD2 are deprovisioned.
I understand one of the ways is to configure LCS with multiple combinations of target systems to be deprovisioned, however this is not an elegant way. The number of possible combinations are huge and also in future if new target sources are integrated, we will have to add in more LCS.
Even if you are successful in removing Birthright Roles using Workflow, user will get those Roles again due to the assignment criteria.
Removing birthright Roles through any custom/OOTB way is not a correct practice. Add LCS condition, so that birthright Roles get removed automatically.
You should handle this in Before Provisioning Rule using AC_NewParent.
You can have multiple LCS as per your requirement and add the sources to disable accordingly. If it is going to result more LCS then it is not a good practice.
You should try to disable accounts using Workflow.
Alternative is, create Identity attributes for UAC for all AD sources, calculate 512/514 based on your feed, enable attribute sync for the respective sources. When it tries to disable AD account, it will execute Before Provisioning Rule which has logic for OU movement as well.
Does this mean the Source name where the account needs to be disabled comes as an attribute from Auth Source and the value is mapped to an Identity Attribute?