Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
Hello Members,
I am looking for guidance on the recommended approach for generating unique Active Directory UPNs during account creation in SailPoint Identity Security Cloud (ISC).
The tenant contains multiple identities where duplicate first and last names can exist. Therefore, the AD UPN must always need to be unique. like if another user with same FirstName and LastName is coming the UPN should be created like firstname.lastname1@company.com , firstname.lastname2@company.com. A counter needs to be appended to make it unique as usually everyone of you follows.
We have created a cloud rule(attached) for the same as we have some limitations in using the Username Generator Transform and Create Unique LDAP Attribute operation.
However, we are encountering situations where ISC still attempts to provision a UPN that already exists in Active Directory, resulting in an AD provisioning failure.
When the first user is created everything looks good :
I have searched the community for a proper guidance or solutions and didn’t find anything (maybe missed) which help me to solve this issue. There is not validation errors, I am able to validate it successfully. I am also confused that any more configuration modifications or enabling any kind of features is needed for this rule to check the uniqueness properly. We have another AD sources which Similar rule working without any issue. I have attached the complete Attribute Generator rule below for review. Any suggestions on potential flaws in the uniqueness validation or counter logic would be greatly appreciated.
Hello Jerin. I would follow @iamnithesh’s check first. From the screenshots, the second request is generating the same UPN instead of incrementing it, which suggests the uniqueness lookup is either not finding the first account or its result is not being handled as expected.
Since similar logic already works on another AD source, I would compare the searchable-attribute configuration between the working and failing sources. If the rule uses idn.attrSearchCountAccounts(), it reads the promoted account attribute in ISC, not AD directly. I would check:
Confirm this source’s userPrincipalName is mapped into the promoted/searchable attribute that the rule is querying.
A non-optimized aggregation was run after adding that search attribute; otherwise existing accounts are not seeded with the promoted value.
Timing: a newly created account is not available through that promoted search data until it is aggregated, so another request shortly afterward can still return zero.
For this AD-only requirement, I would prefer isUniqueLDAPValue(), since it queries the LDAP connector directly and does not depend on the promoted data being current:
The docs also show this being used in Create Profile field-level rules for uniqueness checks. Please verify the LDAP search scope. By default, isUniqueLDAPValue() uses the source’s configured root/search DN. If needed, cloudUniqueSearchDN can be used to change the search base.
In the account attribute generator cloud rule for UPN, i would recommend to use “Non-Indexed Search attribute” which will store the UPN Values from AD source into it and then, use this non-indexed search attribute inside your cloud rule to perform uniqueness check. If the unique attribute does not exists, then, add a number to “firstName.lastName(Number)” and perform the search again till you find the unique value in AD.
Follow the below steps.
Create a Non-Indexed Search attribute using ISC REST APIs through POSTMAN Client or VS Code ISC Plugin.
{
"name": "UPNPrefix",
"displayName": "UPNPrefix",
"applicationAttributes": {
"<SOURCE ID OF RESPECTIVE MS AD Source>": "userPrincipleName"
}
}
Refer the attached Text file which contains a Sample Generator Rule Code for UPN Prefix generation. Note that in the attached code, it also contains the logic of including middleName which is not the requirement in your case but still for reference, you can use the code. In the attachec code, I have used the SailPoint ISC Java API Method named as attrSearchCountAccounts. Refer the below screenshot.
Note that when you are creating the SEARCH Attribute for the 1st time, you need to perform non-optimized aggregation for your AD source so that its populated with required data. Also, once the new UPNPrefix is generated, it will not be populated into the non-indexed search attribute till the account is provisioned in AD and is aggregated back into ISC post provisioning. Therefore, if you get 2 users with same firstName and lastName, then, there will be chances of getting the conflicts and AD provisioning failure.
@rohit_wekhande nice example rule, the search attribute approach works well for existing accounts. Small thing in the config you posted: it says userPrincipleName, which should be userPrincipalName. With the typo it won’t throw an error, it just won’t pick up any values, so worth fixing in case someone copies it as is.
On the timing gap you mentioned at the end, adding a live AD check in the uniqueness method takes care of it:
java
public boolean isUniqueUPNPrefix(String upn) {
List sourceIds = new ArrayList(Arrays.asList(new String[]{application.getId()}));
List values = new ArrayList(Arrays.asList(new String[]{upn}));
if (idn.attrSearchCountAccounts(sourceIds, "UPNPrefix", "Equals", values) > 0) {
return false;
}
return idn.isUniqueLDAPValue(identity.getId(), application.getId(), "userPrincipalName", upn);
}
That way, if two users with the same name come in back-to-back, the second one still sees the first account in AD even before it’s aggregated, and gets the next number.
Thanks @punna0001@rohit_wekhande@SivaLankapalli for the suggestions. After investigating further, I found that this was due to a small configuration item I had missed on my side. Promoting the AD userPrincipalName as a searchable attribute resolved the issue. Appreciate all the help and insights shared.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
