afterModify rule and account aggregation

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hello All,

I have following use case:

  1. After change of department/region/etc new DN (distinguishedName) is calculated via transform
  2. new DN is pushed to AD in prov plan
  3. Due to very specific request from customer:
    • beforeModify rule is triggered,
    • bM rule is triggering additional PS script
    • PS script is creating new OU based on new DN and then moving AD object/account to new DN

Considerations:

  1. Account ID is set for objectguid, correlation is based on sAMAccountName
  2. Network connection from IQ server to tenant is blocked

Spotted Issues:

  1. While beforeModify rule is triggered correctly, ps script is running properly and object is moved to new OU, rest of the attributes in provisioning plan can’t be updated
  2. Obviously ISC do not know that what is the new dn until next aggregation even if nativeIdentity is set for objectguid
  3. After manual single account aggregation dn is refreshed and rest of the attributes are properly updated

Question:

  1. Can i trigger single account aggregation via afterModify rule just with java bean shell without need of additional PS script that will call API?

Many thanks for support on that case
Best Regards
Radek

2

This is a great question. You have correctly identified the gap between what your beforeModify rule & PowerShell script can do (move the object to a new OU) and what ISC knows about the account afterward. Because ISC doesn’t refresh the DN until the next aggregation, the rest of the provisioning plan fails.

Why did it happen in the first place?

  • Provisioning plan execution assumes the DN in ISC matches the DN in AD.
  • When your PS script moves the object, ISC’s cached DN is stale.
  • Even if nativeIdentity is set to objectGUID, ISC won’t requery AD mid-plan.
  • That’s why only after a manual single account aggregation does the DN refresh and subsequent updates succeed.

Can you trigger single account aggregation in an afterModify rule?

  • Directly in BeanShell (afterModify): No, there isn’t a built‑in API call exposed to rules that lets you invoke aggregation. Rules operate within the provisioning engine, not the aggregation engine.
  • Via REST API: Yes, ISC exposes endpoints for single account aggregation (/accounts/{id}/refresh in v3). But calling those requires an API client, typically a PS script or external job.
  • Without external script: Not supported. BeanShell rules don’t have native methods to trigger aggregation jobs. They can manipulate provisioning plans, but they cannot launch aggregation tasks.
3

Hey @shahm2 !
Thanks for response and clarification.
I was wondering if it is possible to use a workflow that catches provisioning event (filtering only for dn change) and the reload account?

4

Yes, you can do that. Please follow the below options for the workflow method:

  • Create one identity attribute which holds DN value
  • Create an workflow with Identity Attribute Change trigger
  • Use the created identity attribute to filter the workflow
  • Next Get identity
  • Using getIdentity get the Identity ID
  • Use HTTP Operation to run the reload account

LMK if this helps.

5

That may help, but i see potential “race condition” here: at the same time two operations are triggered:

  • beforeProvisionig rule with script
  • workflow that will reload account

I’m wondering how can i be sure that reload will happen after change in dn?
Only thing that comes to my mind is “wait” operator for workflow.

6

The identity attribute change will trigger when only the DN value changes. But for safety purposes, wait for 5 min and then continue other operations.

I have done this same when the AC New Parent (New DN) change will add the specific role and send mail to the manager.

7

Will give a try and i will let you know how it went

8

Hi Radek,

Interesting use case.

From what I understand, the main issue is that ISC is not aware of the DN change immediately after the move, so the rest of the provisioning plan doesn’t apply until the next aggregation refreshes the account.

As far as I know, triggering a single account aggregation directly from a rule (like afterModify) is not something ISC supports natively via BeanShell. Aggregation is usually handled as a separate process and not designed to be invoked inline during provisioning.

Because of that, calling the API (as you mentioned) or relying on a follow-up aggregation step tends to be the more common approach.

One alternative you might consider is whether the DN move can be handled entirely within the provisioning plan itself (if supported by the connector), so ISC remains aware of the change during execution.

Thanks!

9

Hi @Gxurav713
We initially plan to use classic beforeModify and keep it as simple as possible (just move objects/change dn) but issue is that dn is build from 4 different variables that can change separately from each other. That required powershell script that willl create those new OU’s based on that variables.