Modify a AD account after moving OU

Implement & Extend
, , ,
1

When we have to enable/disable user in active directory, we must move the user between diferent OUs. We have done that without many problems and the user is placed in the correct OU when it is enabled/disabled. But the problem comes after this, when we need to do something else with the user. Usually it is to change the password, but it can be other operations, since these users are managed manually.

The problem is that when we try a second change, IIQ still thinks that the user is in the previous OU and does not find it to change. When we perform a full reconciliation everything works again till we move the user again. As you can imagine, this is not a viable way since there are multiple user request and the full aggregation takes about an hour.

We have tried to perform a single account aggregation using the after provisioning rule, when the  request involves an ou movement and the request completes ok. But this creates two ad accounts linked to the user (moreover, if you want to do anything with any of these accounts the modification still fails).

Is there any way to get the AD account ready to modify just after a ou change?

This is the code we use to perform the reconciliation in case there is something wrong in it:

public boolean agregacionIndividual(SailPointContextcontext, Stringaccount, Applicationapplication) {

Stringmetodo =".agregacionIndividual(): ";

boolean resultado =false;

logger.info(regla +metodo +“INICIO”);

logger.info(regla +metodo +“Parametro account: [” +account +“]”);

logger.info(regla +metodo +“Parametro application: [” +application.getName() +“]”);

try {

ConnectorappConnector = sailpoint.connector.ConnectorFactory.getConnector(application,null);

ResourceObjectrObj = (ResourceObject)appConnector.getObject(“account”,account,null);

logger.info(regla +metodo +“ResourceObject: [” +rObj.toXml() +“]”);

if (rObj !=null) {

logger.info(regla +metodo +“El objecto no es nulo. Recuperando regla de customización”);

RulecustomizationRule =application.getCustomizationRule();

logger.info(regla +metodo +“CustomizationRule: [” +customizationRule +“]”);

if (null !=customizationRule) {

try {

logger.info(regla +metodo +“Entrando en la ejecución de la custom rule”);

// Pass the mandatory arguments to the Customization rule for theapp.

HashMap ruleArgs =new HashMap();

ruleArgs.put(“context”,context);

ruleArgs.put(“object”,rObj);

ruleArgs.put(“application”,application);

ruleArgs.put(“connector”,appConnector);

ruleArgs.put(“state”,new HashMap());

// Call the customization rule just like a normal aggregation would.

ResourceObjectnewRObj = (ResourceObject)context.runRule(customizationRule,ruleArgs,null);

logger.info(regla +metodo +“Regla ejecutada”);

// Make sure we got a valid resourceObject back from the rule.

if (null !=newRObj) {

rObj =newRObj;

logger.info(regla +metodo +“Asignando nuevo objeto: [” +rObj.toXml() +“]”);

}

}catch (Exceptionex) {

logger.error(regla +metodo +“Se ha producido una [” +ex.getClass() +“] ejecutando la regla de customización”);

ex.printStackTrace();

}

}

// Aggregation

logger.info(regla +metodo +“Entrando en la agregación”);

sailpoint.object.Attributes argMap =new sailpoint.object.Attributes();

argMap.put(“promoteAttributes”,“true”);

argMap.put(“promoteManagedAttributes”,“true”);

argMap.put(“correlateEntitlements”,“true”);

argMap.put(“noOptimizeReaggregation”,“true”);

argMap.put(“checkDeleted”,“true”);

logger.info(regla +metodo +“Creando agregador con parametros: [” +argMap.toString() +“]”);

Aggregatoragg =new Aggregator(context,argMap);

logger.info(regla +metodo +“Ejecutando agregador”);

TaskResulttaskResult =agg.aggregate(application,rObj);

logger.info(regla +metodo +“Agregacion terminada”);

if (taskResult !=null) {

logger.info(regla +metodo +“Usuario agregado”);

logger.info(regla +metodo +“Resultado tarea: [” +taskResult.toXml() +“]”);

logger.info(regla +metodo +“FIN”);

resultado =true;

}else {

logger.info(regla +metodo +“No se ha encontrado el usuario”);

resultado =false;

}

}else {

logger.info(regla +metodo +“No se ha podido reaizar la agregacion”);

resultado =false;

}

}catch (Exceptione) {

logger.error(“Error genérico: [” +e.getClass() +“]”);

e.printStackTrace();

resultado =false;

}

logger.info(regla +metodo +“Resultado: [” +resultado +“]”);

logger.info(regla +metodo +“FIN”);

return resultado;

}

2

Is there any obstacle preventing the consolidation of these operations? For instance, usually when deactivating an account, you relocate it to the disabled OU while also scrambling the password and deactivating the account. All these tasks could be executed within a single plan.

Similarly, when enabling the account, the same approach can be taken. As far as I know, the distinguished name change occurs in real-time now, at least that’s the case for IDN. You can verify this in the connector guide.

Even if it’s not immediate, utilizing a single account aggregation or native rule should assist you in executing any additional operations required after the account is relocated.

3

We cannot consolidate these operations. These accounts are manged manually, sometimes we need to change the passwords, sometimes not. Sometimes we need to give the user some entitlements, sometimes not. Anf everything like that, what we need is that we can modify the AD account as soon as we move it.

We also tried to do a single account aggregation as I said in the first post (I also copied the code used for that) but the problem is that after it, two accounts appear in IIQ and the don’t work properly. It should be only one, we don’t know why the aggragation duplicates de account.

4

So we have a couple of things that move accounts and then does actions against them, all are workflow based so have steps.

Leavers are modified and then they are moved in different steps so in your scenario can you change the password then move the account to another OU?

Returners - again we have a separate step that moves the account out of inactive OU to an active OU, run the single account aggregation for the account ( this works for us) and then in subsequent steps we update other attributes.

Additionally we have another scenario for returners whereby we update the nativeidentity of the account that has been moved after it has been moved so that IIQ doesnt try and use an incorrect DN / create an new account

5

My thoughts:

1) I would recommend do not try to manipulate (modify) identity or links inside before- after- provisioning rules. These rules create theirs own contexts, and an attempt to update identity/links inside them may (however, not “will”) cause unpredictable side effects.

2) To modify OU and CN (“AC_NewParent”, “AC_NewName”) you can use “Disable” and “Enable” application forms. This is very convenient place, because regardless how you initialize your operation to change the account status the OU will always be recalculated properly.

3) Switching NativeIdentity from “DN” to “objectguid” allows to avoid multiple problems related to DN change. In my projects I always use “objectguid” (for accounts and groups).

4) If you use DN as NativeIdentity your approach is correct - after you change DN (CN or OU) you can launch a single aggregation for that changed account. That aggregation will update (correct) links inside Identity and IdentityEntitlement objects. You set even more flags than required to aggregate changes you need. I set the following flags:

if (application.getAccountSchema().getObjectType().equalsIgnoreCase(objectType))
{
  taskArgs.put("correlateOnly", application.isAuthoritative() ? "false" : "true");
  taskArgs.put("correlateEntitlements", "true");
  taskArgs.put("noOptimizeReaggregation", "true");

  Aggregator aggregator = new Aggregator(context, taskArgs);
  taskResult = aggregator.aggregate(application, resourceObject);
}

5) What is important - I would suggest to launch the Single Aggregation inside your workflow, which initiate a provisioning operation which may lead to DN change.

6

We finally decided to use the objectguid as the identity attribute. We tested every operation and it works without any problem.

We couldn’t manage to get the aggregation perfom correctly, without duplicating the account in IIQ, so this is the best solution we got.

7

A wise decision. :slightly_smiling_face:

If this is a new project, you won’t have any problems at all.

If you need to migrate your existing production environment, please test the process in your development environment, because this process may be quite interesting task (it’s needed to change NativeIdentity attribute for all accounts and groups, update all links to them (inside Identity, IdentityEntitlement), close or manually (using some sciprt) update existing open access requests, etc.).

8

Are there any consideration or challenges we need to consider before switching from AD DN to Objectguid?