Hi All,
Working on an Active Directory Before Provisioning rule. I’m using AC_NewName to rewrite the CN on objects during name changes. I’ve created a function to generate the CN and check for uniqueness. The generation works great, but when I tested uniqueness it didn’t work as intended.
Using test accounts. I had an existing account CN=Jimmy Twotimes,OU=orgUnit,DC=domain,DC=com. I renamed an account with the same name in the same OU. It re-wrote the CN appropriately to CN=Jimmy Twotimes, but I expected CN=Jimmy Twotimes1 (adding a number 1 to the end of the CN). The issue is it broke the original test account and stole the CN=Jimmy Twotimes.
Would anyone be able to assist with the logic?
Hoping to get some help here before going through support, requesting logs, modifying rules, resubmitting the rule, and continuous testing loop. I’m not going to post the entire rule for the sake of having to not sanitize the entire thing. I can if needed, but the issue should really lie in the function below.
As a note, I know canonical name is not common name in AD. It was a mistake in wording on the original engineer. Our adCanonicalName identity attribute example would be “Jimmy Twotimes” being a common name. I also know “CN=first last” for CN isn’t best practices, but it is what it is in our environment.
I have a feeling the issue is in this line, but after looking at the java docs, it looks right to check if the CN already exists.
if (idn.isUniqueLDAPValue(identity.getId(), application.getId(), "cn", cn))
import sailpoint.object.ProvisioningPlan;
import sailpoint.object.ProvisioningPlan.AccountRequest;
import sailpoint.object.ProvisioningPlan.AttributeRequest;
import sailpoint.object.Identity;
import sailpoint.object.Application;
import sailpoint.tools.Util;
import sailpoint.thunderbolt.service.LDAPConnectorService;
import sailpoint.thunderbolt.service.module.ServiceModule;
import sailpoint.tools.GeneralException;
import sailpoint.rule.Account;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
int MAX_ITERATION = 200;
String adCanonicalName = identity.getAttribute("adCanonicalName");
public String generateCN(String adCanonicalName, int iteration) {
if (adCanonicalName == null) {
log.info(RULE_INIT + "adCanonicalName identity attribute is null " + iteration);
return null;
}
// This will hold the final CN;
String cn = null;
log.info(RULE_INIT + "generateCN, iteration " + iteration);
if (iteration < 1) {
cn = "CN=" + adCanonicalName;
} else if (iteration >= 1 && iteration < MAX_ITERATION) {
cn = "CN=" + adCanonicalName + iteration;
} else {
log.info(RULE_INIT + "Failed to generate CN, returning Null");
return null;
}
if (idn.isUniqueLDAPValue(identity.getId(), application.getId(), "cn", cn)) {
log.info(RULE_INIT + "Generating CN was successful: " + cn + " interation number: " + iteration);
return cn;
} else {
log.info(RULE_INIT + "CN was not unique retrying: " + cn + " interation number: " + iteration);
return generateCN(adCanonicalName, iteration + 1);
}
}
// Checking if the user's Name changed
if (attributeRequestName != null && "sn".equalsIgnoreCase(attributeRequestName)) {
String attributeRequestNameValue = req.getValue();
if (attributeRequestNameValue != null && !nativeIdentity.contains(lastName)) {
log.info(RULE_INIT + "Last Name changed. Updating CN");
newCN = generateCN(adCanonicalName, 0);
}
}
This is a screenshot of the original Jimmy Twotimes. The second test account was CN=Joan Jett, before I renamed it to “Jimmy Twotimes”. The collision caused some weirdness overall.
