We have an Active Directory Source and would like, for some identities only ( administrators), to provision two different AD accounts on the same source.
The first account is created normally according to the existing provisioning rules.
The second account should be created only when a specific identity attributeisAdmin, is set to true. In that case, we want to provision an additional AD account on the same source, but:
in a different OU : OU=Admins,DC=domain,DC=com
with some different attribute calculations.
and with a different UPN naming convention.
For example, for the admin account, the UPN could be something like: admin-username@domain.com
Is it please possible to trigger the creation of this second account on the same source through a role or access profile, for example using a memberOf entitlement or by workflow?
We really don’t want to create a second source for this need please, Has anyone implemented this kind of setup before?
I appreciate that this is not answering your question, but you are asking for something that ISC simply does not support OOB and any “solutions” will just be storing up trouble for you.
If you could give your reasoning for not wanting to create another source, that may help frame the discussion.
The work for a second source is the right course forward in my opinion.
By creating an “Active Directory - Admins” source, you gain the native capability to isolate the provisioning logic entirely
A distinct Create Profile: It will have its own Create Profile where you can hardcode the OU=Admins,DC=domain,DC=com directory string.
A separate Attribute Calculations: You can apply a completely different Account Profile and generator logic to output admin-$username@domain.com for the UPN.
Native Lifecycle Triggers: You can create a Role with the membership criteria isAdmin == true. This Role will encapsulate an Access Profile from the Admin source. When the identity attribute flips to true, ISC natively generates a Create plan for the new source, provisioning the secondary account exactly as defined.
This also cleanly separates standard entitlements from privileged entitlements in your governance model, preventing accidental assignment of admin groups to standard accounts.
It is a bit surprising that ISC cannot easily support this use case. In many other IAM solutions and even in IdentityIQ it is possible to provision multiple accounts for the same identity on the same target source…
If this is not possible in ISC, the workaround would be to create multiple sources pointing to the same Active Directory, which is not ideal from a maintenance and scalability perspective.
For example, today we only need to create a second admin account, but in the future we may also need to provision other types of accounts such as supplier accounts or other specific-purpose accounts =>
This would quickly lead to creating many different sources for the same Active Directory, which would make the configuration harder to maintain and scale over time.
I was just wondering if this could be achieved using a Before Provisioning Rule .for example, when the identity attribute isAdmin = true, the rule could:
Change the operation from Modify → Create
Generate a new nativeIdentity
Apply a different UPN naming convention
Set the OU to OU=Admins,DC=domain,DC=com
Adjust any other required attributes for the admin account
This could allow the connector to create an additional AD account on the same source.
However, I’m not completely sure how practical or recommended this approach is in a real implementation.
I opened an AAA session a couple of weeks ago on this topic, I was told you have to do it with two sources to AD, one checks standard-user-OU and other checks admin-user-OU.
This only gets messy in my opinion, when there are shared entitlements e.g. normal-user-entitlement assigned to admin-user-account (though in a properly split environment where admin accounts do not get access to normal-user-resources this should not be a problem).
We’re not saying that ISC cannot support provisioning of multiple accounts on the same target source; we’re saying that the way it is done is to use multiple ISC Sources, just as you would create multiple Applications in other IAM tools.
When you say
I could quite easily say the opposite. For instance, you want to manage admin accounts, right, which ideally should have a different delegation of administration model from normal accounts, so would imply (from a least privilege perspective) a different service account, which would imply another connector. Together with different reporting and auditing and retention, etc. etc.
ISC’s approach is less code, handle via configuration. i.e. Scale via configuration. Arguably lowersng the skill requires to handle different account type / buckets. Historically, on the IIQ side, you would have to have configuration (where) and code (what and how) level knowledge to decipher how an environment is handling multiple account types per application definition. Also, with IIQ, you would have to code your provisioning handing differences in the rules and CRUD provisioning profiles, which had a risk of impacting the other account types of that application if not properly [regression] tested. Account selection rules was another layer of code complexity as well.
This aligns better with the Configuration as Code approach to scale up as needed. i.e. Automate your source configuration scaling.
Just a different way of catching the fish I guess. …and this approach with ISC is to save on the compute cost that would otherwise be required to evaluation which bucket an account is / isn’t in.