A customer has brought up a special request that 1IM must coexist with their homed IDM system for at least 6 months. Workday will feed HR data to both 1IM and the homed IDM system. But 1IM must be in read-only mode (no write operations selected) to AD domains (2), and homed IDM system operates all of tasks (CRUD) in AD domains.
With that request, two issues were found.
- the homed IDM system created an account in native AD meanwhile 1IM created the same account in ADSAccount table with “no write operations” selected – below is what’s happening
- Workday adds new employee to 1IM. 1IM then assigns the role with AD resources to that employee and create accounts in ADSAccount table but the insert process (provisioning account to native AD) won’t be executed because of “no write operations” selected. The ObjectSID value in ADSAccount table for new created account could never be populated from native AD.
- Meanwhile outside of 1IM, the homed IDM system created new account in native AD based on the same Workday data 1IM received.
- When 1IM AD sync runs, 1IM throws the exceptions and errors out saying a duplicate SAMAccountName already exists. 1IM behaves appropriately because 1IM is not award of account created in step b) and handles it as another different account as not the account created in step a)
- the homed IDM system created account was synced into 1IM ADSAccount table, and later Workday tries to add the employee record with the CentralAccount identical to SAMAccoutName generated by homed IDM system. It failed because of “QER\Person\CentralAccountGlobalUnique” set to 1.
The customer requirements:
- the procedure to avoid what has happened to case 1; and what need to do for resolving the error / exceptions if case 1 situation occurs
- With “QER\Person\CentralAccountGlobalUnique” set to 1, what is another mean to allow Workday to add new employee with CentralAccount match to SAMAccountName already in 1IM
Any suggestions or inputs are truly appreciated!!!
Customer runs 1IM v6.1.4.
