Contractor accounts exist in AD, but not yet in NERM or ISC. When bulk loading accounts in NERM for existing AD Accounts, it creates their identities and creates another account as correlation isn’t happening fast enough. The assignment of access through roles is generating the create account.
The work around is to disable the roles / access profiles that could grant access to AD entitlements which would trigger the provisioning to AD. After the disablement, we would aggregate accounts on the AD connector. Once the aggregation is finished and accounts correlated, we would finish up by enabling roles / access profiles.
This is okay for a small environment with only a few roles. What do we do with larger customers with a larger set of Role Models built out? These should be limited use cases / one time operations and hopefully early on in an implementation.
Interesting thought. Ideally, i think it should not boills down to disabling roles and access profiles.
I think this can be achieved like below.
We have to ensure that only one role is responsible for creating the users in AD. For other roles based on membership, then we need to add a criteria that only assigned the role, when user has an AD account.
This can be controlled based on any identity attribute , to me cloudlifecycle state looks like a good candidate here but lets call it identAttr_AD_ACCOUNT. If user has AD Account, then the value becomes YES otherwise NO. For all the roles who are adding access in AD system, you can add this attribute in their membership criteria to assign only when identAttr_AD_ACCOUNT has value YES.
Then in NERM, you can have an attribute created “ALREADY_HAS_AD_ACCOUNT” which can have value 0 or 1.
The role which is used for creating the account in AD, you can have the criteria enabled there where “ALREADY_HAS_AD_ACCOUNT” account attribute value is 0.
This way, you can onboard users who already have access to AD, by setting attribute ALREADY_HAS_AD_ACCOUNT as 1. And the flow should work like this.
Then the role, resposible for creating the users in AD, will not create the account in AD initially because of ALREADY_HAS_AD_ACCOUNT value as 1.
Other roles will not picked up because user does not have an AD account and thus identAttr_AD_ACCOUNT does not have value YES.
Now, once ISC aggregate the account, it will be merged with AD source and thus identAttr_AD_ACCOUNT value should become YES.
Now all the other role membership criteria will kick in and the required access will be assigned.
Here, you may not even need another attribute Iden_Attr_AD_ACCOUNT, but you will have to see whether existing attribute can be made useable here.
I think this approach should do the trick. I hope this helps.
I’ve taken a different approach - instead of the AD connector creating the unique username we’ve been forced (for other reasons) to build the unique username, populate it in an identity attribute, and then create the AD account. For those who already have an AD account when their identity is first created, the AD connector fails to provision, which we then use to trigger a workflow that grabs the specific AD account and reload it, causing it to be correlated.
The hope on what I’m building is a UI that will evaluate the features and allow someone to disable / enable provisioning. Then the customer could do this on their own in those given use cases.
This sounds like a good approach, as long as your duplicate account issue is related to a one-time bulk load, and not an ongoing provisioning issue. Let us know how it goes!
I don’t normally endorse using lifecycle states to solve issues (we have over 35 of them because someone thought it was a good idea), yet this seems to be an elegant solution.
Create a new LCS - NERM no AD, and set it as your first priority.
This will catch all your bulk added employees.
Once the correlation rules have caught up, the identity will naturally move out of the LCS into the next one, preventing additional accounts from being created.
You will just need to add the exclusion of this new LCS to the Role criteria that is used to generate the AD accounts