Share all details about your problem, including any error messages you may have received.
Having a horrible time with one application and multiple accounts. For simplicity, I won’t include all account types, just enough to explain the problem.
Application: Active Directory - Privileged
Account Types: DA (Database Admin), WA (Workstation Admin)
I have requestable roles for each account type. Here is a diagram showing the expectation and reality:
I need to know why the Account Selector rule isn’t being triggered to create a new account and simply just overwrites the existing one. We have the “Allow multiple application accounts checked on the given role” checked on each role underneath the application we want to create multiple accounts for.
To my knowledge, we do not have entitlements differing entitlements attached because we have to add AD groups specifically to those accounts because of how they are used in our environment. We aren’t doing that in IGS.
Please share what you all have done to make this possible and help me understand why this overwrite is happening and how to fix it. SailPoint has documentation that is very clear about this capability, and I am just not doing it right.
@kalyan_dev32 Have you been able to solve this issue? If you have example code or links to discussion posts that answer this, I would greatly appreciate it.
This feature is really essential for us and my manager is not happy that we cannot utilize an ‘out of the box’ feature.
I really appreciate you taking your time to look at this. Here is the account selector rule. This rule is really basic because we are trying to just get another account to show up. We have put in logging statements and taskoutput statements, but we have not been able to get the rule to fire off. Here is how we have the role setup associated with this AccountSelector rule:
Active Directory - Priv (Organizational Role)
Account Selector Rule (General): None
Allow Multiple Accounts : False
Resource Admin (IT Role)
Account Selector Rule (General): Test-3
Allow Multiple Accounts : True
Resource Admin Account (Business Role - Requestable)
Account Selector Rule (General): None
If there is something on the app level you would like to see, let me know. My hunch is that there is something happening that is matching a ‘new’ account to an already created one and is just updating attributes. If there is something that needs to be done to differentiate the accounts, then that might be it.
Account Selector Rule
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule created="1741040984237" id="0ad214e9955d1d9381955e2120ad0ae4" language="beanshell" modified="1741629438092" name="Test-3" type="AccountSelector">
<Description>AccountSelector Rules are used by the role modeler to automatically select a target account for provisioning when there are multiple candidates.
The return value is a Link instance that represents the selection. Value can be:
null - indicates that no automatic selection can be made
"prompt" - indicates that a separate account selector should be presented for the role
existing Link - the selected Link from the list of possible target Links
a new Link instance - indicates that a new account must be created with the identity specified by the create policy, or manually; in this case, the Link instance returned will have a null nativeIdentity attribute</Description>
<Signature returnType="Link">
<Inputs>
<Argument name="log" type="org.apache.commons.logging.Log">
<Description>
The log object associated with the SailPointContext.
</Description>
</Argument>
<Argument name="context" type="sailpoint.api.SailPointContext">
<Description>
A sailpoint.api.SailPointContext object that can be used to query the database if necessary.
</Description>
</Argument>
<Argument name="source">
<Description>
The application doing the provisioning.
</Description>
</Argument>
<Argument name="role">
<Description>
The IT role being provisioned.
</Description>
</Argument>
<Argument name="identity">
<Description>
The target identity.
</Description>
</Argument>
<Argument name="application">
<Description>
The target application.
</Description>
</Argument>
<Argument name="links">
<Description>
A list of the possible target Links.
</Description>
</Argument>
<Argument name="isSecondary">
<Description>
True if this is not the first assignment.
</Description>
</Argument>
<Argument name="project">
<Description>
The provisioning project.
</Description>
</Argument>
<Argument name="accountRequest">
<Description>
The account request.
</Description>
</Argument>
<Argument name="allowCreate">
<Description>
True if account creation is allowed.
</Description>
</Argument>
</Inputs>
<Returns>
<Argument name="selection">
<Description>
A Link instance that represents the selection. Value can be:
null - indicates that no automatic selection can be made
Link - the selected Link from the list of possible target Links
a new Link instance - indicates that a new account must be created with the identity specified by the
create policy, or manually; in this case, the Link instance returned will have a null nativeIdentity attribute
</Description>
</Argument>
</Returns>
</Signature>
<Source>import sailpoint.object.Link;
return new Link();</Source>
</Rule>
also, if there is a good whitepaper on implementing multiple accounts onto one application, that would be very helpful. There is just something we are not setting up right where it is not firing off.
@acrumley Not sure, It’s possible that the provisioning policy could be part of the issue, as it supplies the identity data needed to create an account. If your IdentityIQ (IIQ) setup already includes logic to generate unique attributes like samAccountName, DN, or any other attributes you want to include, that might resolve the problem. I suggest reviewing the provisioning policy to confirm this.
For testing purposes, you could mark an attribute as “review required” in the provisioning policy.
When requesting a role for a user, if you’ve marked an attribute as “review required,” it will trigger a pop-up. This pop-up displays the provisioning policy attributes being sent to the target system (e.g., Active Directory), allowing you to verify the data being passed.
I recommend checking out this community document: Roles and Multiple Accounts.pdf - Compass It should provide valuable insights into implementing multiple accounts for a single application.
Let me know if you need further guidance! Hopefully, the suggestions above help resolve your issue.
Hi @acrumley
You mentioned that you believe that you account selection rule is NOT triggered, right?
If this is the case, try putting a logging statement in your rule(with that logger turned to the right loggin level) or even simple System.out statement to confirm IIQ is running that rule. Please report on results
Regards
Alek
For the app level, what do you have set as the native identity?
We are using the distinguished name. The biggest issue is that when we add the second role attempting to create the second account, we can’t get it to map differently. On the access request, the first one has a native identity (that is correct). On the second, the distinguished name is blank and the “Account” column is labeled as “New Account”.
On the role level, we do not define the distinguished name because it is already defined on the app level. Is this the wrong thing to do?
For the role that you want the new account to be created, in account selection rule try returning new link but on that new link set desired new dn as native identity of the new account (obviously different than dn of existing account)
Very simply System.out.println(“Test message”); should print directly to output log of you tomcat server (Only for testing, please remove such stuff from code when going in to production).
With logger you need to set logging level in log4j.properties file in your build.
I’ve put in the stdout and logging. However, it is not firing. What conditions upstream would prevent an Account Selector rule from firing when assigning the role?
Since the distinguishedName is the native identity for our app, should I also have this changed in the schema in the provisioning policy on the role level as well?
i’ve been really banging my head against a wall here today.
When I try to add the second role that should provision a different account under the same app, it just maps itself to the account that already exists and tries to set attributes.
Does your provisioning policy have logic in place to check if accounts already exist in IIQ or by directly querying AD with the same DN or samAccountName? If not, add logic to append a counter (e.g., “jdoe-DA-2”) if duplicates are found. Then, update the provisioning policy to reflect this logic. Afterward, request the roles and confirm that new accounts are created with unique DNs. If the issue persists, examine the provisioning plan in the logs and look for errors in the access request.
In the provisioning policy for the application, we assign the DN using a random number generator + the identity’s badge number. Therefore, we have unique DN’s at the app level
We use the same exact logic in the Role Provisioning policy.
We just cannot get the account selector rule to fire off. As per the code above, we return a link with null native identity, it should create an account versus trying to update the account that is on the cube in the app.
on the role side, do the Direct Entitlements need to be unique between the two roles that we need separate accounts for? Would this cause SailPoint to automatically map to the same account because that entitlement already exists?
Yo another thing. In our BeforeProvisioning rule, our code just prints out the provisioning plan. Would we need to attempt to modify or update the plan to create a new account at that level? Is this what you mean by updating the provisioning policy logic?
It just seems that there is something upstream that has been bugging us. Do you have logic in our Provisioning rules in your Application to create another Link/Account?
