Hi all, we have a requirement where the old sAMAccountName should not be used again even after the deletion of this old account in the AD system itself.
Basically we are having similar use case as discussed in the post below, but one issue is that we do not have the sAMAccountName stored in the HR source.
For example,
User A: dummyuser
User B: dummyuser1
User C: dummyuser2
So, before User D is onboarded, User B is offboarded and disabled in IDN, and will be deleted in the AD target system after 30 days.
After 30 days, User D is onboarded. Instead of having the sAMAccountName “dummyuser1”, it should be “dummyuser3” instead.
We were thinking of updating the identity attribute for each user to store the sAMAccountName used when the account is disabled. So, we can check the sAMAccountName for all the deleted users and refrain from provisioning the old ID. However, we are not sure on the feasibility of this to work on IDN.
We have a separate Delimited File (csv) source set up specifically to serve as an answer to the question “what are all the samaccountnames we have ever used?”, mainly because we don’t have identity records for every single account that’s ever existed.
In the create profile, we have a generator rule for samaccountname that checks against both AD and the CSV source for uniqueness, and increments the number after the samaccountname until it finds a unique one in both sources.
To give an example for clearer understanding on what you are proposing,
Identity attribute: adid
Using the first valid operation on the attribute “adid”:
Read the account attribute sAMAccountName from the account source
Read the identity attribute itself “adid”
So, let’s say if the AD account got deleted, and was removed in IDN after aggregation, the transform script will help to read the second valid value, which is the identity attribute itself?
If I understand wrongly, can you assist to further clarify the statement “If not, pull samAccountName from identity attribute”, thank you very much!
We used a combination of the current samaccountnames in AD and combined it with records we had in a personnel database that went back further. Then uploaded that file for the source. In order to keep it up to date, we use the API to add the newly generated samaccountname to the csv source.
If your HR source is scoped to not aggregate accounts after a certain amount of time, it will delete the Identity. So it is possible for prior login IDs to be used if the IDN Identity is removed.
There is a parameter that can be set on the source that will not delete the Identity.