We are having an problem in SAM Account attribute in Active Directory from IDN.
Case 1:
we did the rehire for the user who was terminated less than 6 months and the account get enabled with the same information in AD (no issue in this scenario)
Case 2:
We did the rehire for the user who was terminated more than 6 months ago but the user account still in disabled state also new account got created for the same user with new information and employee id is same for both users.
Welcome to developer forum and thank you for posting.
Can you add more details to the process being followed after termination gets past 6 months?
Do you do OU transfer after 6 months? If yes, are they in SP search scope?
Are you using Lifecycle Provisioning to enable the account?
The user was in uncorrelated in IDN and it present in Disabled OU before rehire.
And in our environment If the user gets terminated/hired in workday and then IDN will be moving the user account into disabled/active ou via BPR rule in AD as per their life cycle change.
Run an Unoptimized Aggregation through API so that correlation can happen.
URL:- {{api-url}}/cc/api/source/loadAccounts/{source-id}
Body(form-data):- disableOptimization: true
Have you checked if the attributes are properly populated in AD. Also, there should be 1-1 match on account and identity for the correlation to work. If same empid is present in 2 accounts, correlation won’t work.
There is no other account with the same identity ID in IDN but make me understand is there any posibility that if the user is not present in workday source in IDN but present in workday tool so is that’s the reason the account is not getting correlated and creating new account?
Hi Faizullah,
Are you aggregating the Disable OU into IdentityNow ? You can check the Active Directory configuration and see what all OU you are configuring ?
Hi Faizullah,
So after 6 months does the workday account gets aggregated in IdentityNow? The account is going in uncorrelated state means that it is not able to match the correlation logic.
Actually we have configured the AD source newly in our environment and workday source is already been there however not sure why the correlation is not happening as we have set the correct logic in there
I am not sure where it is taking long time to find the existing account in AD but till the old account find by IDN new account is getting created for the user and old account also getting correlate after some time but its in disable state and error is [“Failed to update attribute AC_NewParent Error - The object already exists.\n”]
First a comment. I wouldn’t have the AD users search scope set so broad. We did that and IDN is pulling in thousands of Generic and Service’s accounts. As a result we have 10,000+ uncorrelated AD accounts and no way to know if any of those are human identities. We have a project to go back and limit the AD Search Scope to just OUs where human identities are. Those are the identities we are trying to manage with IDN so IMHO those are the only AD accounts we should pull in to the system. At least in that source.
Second, help us understand the workflow in your system. (1) “today” a user in Active in Workday, in the Users OU, and active. The identity is active using the Workday Identity Profile and has the AD account correlated to the identity.
(2) Tomorrow the user terms. So they go inactive in Workday, to a terminated Life Cycle State, AD is disabled, AD is moved to the disabled users OU.
(3) 4 month later they are still terminated in Workday with an inactive Identity and AD disabled in the disabled users OU.
(4) 5 months later they are rehired so they go back to Active in Workday and to an Active Life Cycle State.
At step 3 is AD still correlated to the Identity?
How are you determining the sAMMAccount name for the AD account? It sounds like the Old and New accounts have different sAMMAcount names. You can’t have a duplicate sAMMAccount name in AD. Is the rehired user getting a new value for the sAMMAccount anme?
(1) “today” a user in Active in Workday, in the Users OU, and active. The identity is active using the Workday Identity Profile and has the AD account correlated to the identity. we configured the AD source recently and those who are in ‘active’ state their account got correlated and those who are inactive their account also correlated
(2) Tomorrow the user terms. So they go inactive in Workday, to a terminated Life Cycle State, AD is disabled, AD is moved to the disabled users OU. yes
(3) 4 month later they are still terminated in Workday with an inactive Identity and AD disabled in the disabled users OU. yes
(4) 5 months later they are rehired so they go back to Active in Workday and to an Active Life Cycle State. yes
Rehire user is getting new user account and after some time the old existing account is getting correlated
(4) 5 months later they are rehired so they go back to Active in Workday and to an Active Life Cycle State. yes
Rehire user is getting new user account and after some time the old existing account is getting correlated
Is this new user account with a new sAMMAcount name? I am assuming it is what is the logic to determine the sAMMAccount name? Why is it different than the old sAMMAccount name?
Is this new user account with a new sAMMAcount name? yesbut with same empid
I am assuming it is what is the logic to determine the sAMMAccount name? we are using create unique ldap for that to create fisrtname.lastname(uniquecounter)
Why is it different than the old sAMMAccount name? because client required the new user account to be created like this fisrtname.lastname(uniquecounter) old users samaccount naming convention is firstinitial.lastname(uniquecounter) which is diff compare to old to new
