// Max counter for unique CN.
int CN_UNIQUE_CHECK_MAX = 100;
public String generateCN(String applicationName, String currentCN, String OU, String nativeIdentity) {
String newDN = "CN=" + currentCN + "," + OU;
if (null != nativeIdentity && nativeIdentity.equalsIgnoreCase(newDN)) {
return null;
}
boolean accountExists = idn.accountExistsByNativeIdentity(applicationName, newDN);
if (!accountExists) {
return currentCN;
}
String newCN = null;
// Iterations for unique values.
for (int i = 1; i < CN_UNIQUE_CHECK_MAX; i++) {
String tempCN = currentCN + " " + i;
newDN = "CN=" + tempCN + "," + OU;
accountExists = idn.accountExistsByNativeIdentity(applicationName, newDN);
if (!accountExists) {
newCN = tempCN;
break;
}
}
return newCN;
}
Can be called by generateCN(application, <new CN after namechange>, ou, plan.nativeIdentity()). You shouldn’t need to promote anything since DN is the account ID by default. Only constraint is that this OU must be fully read into the source so all accounts are visible by IDN.
I typically use this for movement, but can work for name change with a few modifications.
Keep in mind that if you are going to be moving users into different OUs during their lifecycle, best practices suggest to keep the DN unique across the entire domain.
Also, keep in mind that if you change the FQDN, it will uncorrelate the previous AD account. If you have multiple changes that are occurring simultaneously with the DN change, you may see duplicate accounts being created as they may occur while the account is uncorrelated.