We are a small development team with a lot of apps to onboard and many different account types that are forced by our environment. We have Active Directory that has standard accounts and multiple different types of elevated accounts. We have AD working fine, but we want to have a separate app for the “Active Directory - Privileged” accounts. Our issue is as follows:
We have two roles that are supposed to provision two separate accounts under the same application Active Directory - Privileged. However, we are consistently getting this behavior no matter what combination of role characteristics we try (different entitlement assignments, multiple assignments allowed, etc.)
First role will provision Account_Type_1. The second role will attempt to modify Account_Type_1 with the attributes of Account_Type_2. In provisioning plan language, the first one is always create and the second is always modify. We want create and create to get two accounts under the same app.
We have an account selector rule in place that has never fired. We have logging statements, System.out statements, and everything to see if it will work. So far, we have had no luck, and we do not know what is happening.
We want two roles that provision two different accounts under the same app. How did you guys do it?
NOTE: We do not have a mechanism in place to create the first account under the Active Directory - Privileged app. We want a requestable role (business role) to create each account.
Given the context of that error, here is the full XML of that rule:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule created="1741040984237" id="0ad214e9955d1d9381955e2120ad0ae4" language="beanshell" modified="1742916327707" 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;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
Logger logger = Logger.getLogger("ACCOUNT-SELECTOR TEST-3");
logger.setLevel(Level.DEBUG);
logger.debug("ACCOUNT SELECTOR TEST 3: FIRING");
Link lnk = new Link();
lnk.setNativeIdentity(null);
return lnk;</Source>
</Rule>
Final note. Do you have multiple business roles to get multiple accounts? Or do you have multiple IT roles with individual business roles?
Example 1:
IT role 1
- Business role 1 -> Creates Account Type 1
- Business role 2 -> Creates Account Type 2
Example 2:
IT role 1
- Business role 1 -> Creates Account Type 1
IT role 2
- Business role 1 -> Creates Account Type 2
The account selector rule is managed at IT role level and so in my case I have Business Role 1 → IT Role 1 → Account selector rule
Business Role 2 → IT Role 2 → Account selector rule
I assume you have application provisioning policy configured to make sure you set the right account type for each role. My account selector rule looks very similar to yours where I am creating a new Link object and returning it.
I really appreciate the help. I think the provisioning policy has been messing me up.
The native identity is the distinguishedName property for us. What does your provisioning policy look like at each level? In this case, if I am creating two separate account types under the same app, what level should define the provisioning policy? (I would think its at the Business role level).
What properties would need to be set at the app level? I have tried to just remove the application provisioning policy and set all properties at the Business role level, but then I get the Cannot create identity with Null Native Identity type error. I am new to SailPoint and the inheritance model of provisioning policies has confused the life out of me.
WAIIIT. Could you please tell me what policies at the app level that you have in place to determine the account type??? This detail you mentioned could be vital to figuring this out.
This maybe our issue the entire time. Is there a way to check for what role is being applied and then change the attributes based on that role type?
We have tried to set all account-specific attributes at the role level. I’d love to get an explanation of the architecture here.
Defining the attributes at role level should also work. But I am not sure if nativeidentity from role provisioning policy will be evaluated or the account selector rule. If account selector rule is evaluated then it will set the nativeIdentity to null from your rule. You can try to set the nativeIdentity in your rule itself. You may have to use 2 different rules for each role or use the role argument present in the account selector rule to determine the native identity (DN to set ). In my case I am setting the nativeIdentity in Rule as it is role dependent and all other attributes are being set from application provisioning policy.
Understood. We have just had a tremendous problem in getting the account selector rule to fire. we have logging statements, printout statements, etc. to get output from it. However, we never seem to get them to output.
Are there global settings that need to be ticked at all in IdentityIQ for Account Selector rules to work?
