My client has reported intermittent issues concerning the creation of their Active Directory (AD) accounts within their contractor (NELM) system. When an account is generated in the NELM source via ServiceNow, it undergoes a lifecycle state within the ProvisionService where an access profile is assigned, triggering the creation of the account in AD. The account is placed correctly within the designated Organizational Unit (OU). However, in instances of the issue, the account is not transitioned to the intended lifecycle state of ActiveHasService; rather, it is placed in ActiveNoService. Consequently, this I believe is caused by the inability to detect the userAccountControl value of 512 on the account record on the cube of the user.
Upon examination of the AD account through the accounts tab in IdentityCube, the field appears blank, despite being populated in AD. Aggregating the account information resolves this discrepancy by pulling in the appropriate values and self-correcting the issue.
The problem arises from the system incorrectly assuming the absence of an AD account, subsequently leading to the creation of a duplicate account within approximately one hour. Upon aggregation, both accounts are retrieved, resulting in a new lifecycle state termed multiAccounts.
This issue is not universally replicated across all accounts and attempts to recreate it in a sandbox environment have been unsuccessful so far. It is my understanding that upon the creation of an AD account, there should be an automatic refresh within the cube and aggregation of the account from AD.
If I understood your implementation correctly, LCS is managed through AD account availability of user with help of UAC. But why, I have seen/implemented multiple implementations using user status/startDate/endDate.
The problem is due to LCS incorrect calculation for some users, causing duplicate AD account.
I believe SamAccountName, UPN, email, DN are generated at create account provisioning policy, that is why duplicate account. What if some attributes are generated at identity side then duplicate account creation will be failed.
Also, AD account creation,
Instead of adding Access Profiles in LCS, it is better to create Roles with additional criteria.
We have successfully identified and rectified the issue.
The problem stemmed from the Active Directory source exclusively directed towards a Global Load Balancer. This configuration posed difficulties when retrieving data to facilitate lifecycle state settings. The process attempted to retrieve information from a Domain Controller (DC) lacking replicated account data. Consequently, it appeared as if the account didn’t exist, leading to the unintentional creation of duplicate accounts.
Our resolution involved reconfiguring the setup to encompass every Domain Controller server in the server list. The primary adjustment ensured that the read/write DC took precedence in this list, resolving the issue effectively.