Violation rule only one group removed

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about? 8.4

Hello,

In IdentityIQ 8.4, the policy SOD_POLICY_APPs_AD detects two violations for the same identity. For each violation, the rule Rule_SOD_Policy_Apps_AD runs a separate provisioning plan to remove the corresponding AD group from memberOf.

Both groups are removed from the AD account. However, after the policy-check task completes, only one group disappears from the identity in IdentityIQ. The second disappears only after we run a separate Identity Refresh.

We also tested setDoRefresh(true) and setOptimisticProvisioning(true) before provisioner.execute(plan), but the behavior did not change.

Could you help us determine why the two removals are reflected differently on the identity, and advise on a supported way to update both entitlements during the policy-check process without a separate refresh task?

thanks

Code snippet

String applicationName = "AD Rede CGD";
String entitlementName = "memberOf";

ProvisioningPlan plan = new ProvisioningPlan();
plan.setIdentity(identity);

AccountRequest accountRequest = new AccountRequest();
accountRequest.setApplication(applicationName);
accountRequest.setOperation(AccountRequest.Operation.Modify);

AttributeRequest attrRequest = new AttributeRequest(
entitlementName,
ProvisioningPlan.Operation.Remove,
adGroupToRemove);

attrRequest.put("preferRemoveOverRetain","true");
attrRequest.put("assignment","true");

accountRequest.add(attrRequest);
plan.add(accountRequest);

Provisioner provisioner = new Provisioner(context);

provisioner.execute(plan);

I cant understand why just one group is removed from the identity but both are removed from account and only fix the issue after a refresh

2

Hello Ricardo. Since both groups are removed from AD, the provisioning itself appears to succeed. The difference is on the IIQ side after provisioning. Entitlement data on the identity is updated by Identity Refresh, even when the account/Link change is already reflected.

I would still test avoiding a separate Provisioner.execute() per violation. If both groups are available together, add both Remove AttributeRequests to one AccountRequest and execute the plan once. An AccountRequest supports multiple attribute requests (AccountRequest javadoc):

AccountRequest accountRequest = new AccountRequest();
accountRequest.setApplication(applicationName);
accountRequest.setOperation(AccountRequest.Operation.Modify);

for (String group : groupsToRemove) {
    AttributeRequest attrRequest = new AttributeRequest(
        "memberOf",
        ProvisioningPlan.Operation.Remove,
        group
    );

    attrRequest.put("assignment", "true");
    attrRequest.put("preferRemoveOverRetain", "true");
    accountRequest.add(attrRequest);
}

plan.add(accountRequest);

Provisioner provisioner = new Provisioner(context);
provisioner.execute(plan);

I would treat this as removing the separate executions as a variable, not as a replacement for Identity Refresh. Your setOptimisticProvisioning(true) test was reasonable, but as you saw it did not resolve this case.

If the Entitlements tab must reflect both removals immediately, I would not expect Provisioner.execute() alone to guarantee that. In IIQ 8.4, the documented option is Refresh Identity Entitlements for all links. If the rule runs once per violation, each invocation may only know one group. In that case, you may need to collect the removals before provisioning them together.

I would leave your existing assignment=true and preferRemoveOverRetain=true unchanged for now, since both removals are already reaching AD.

3

Hello,

Thank you for your help.

The removals need to be handled as separate executions because a user may have one or more of the groups covered by the policy.

To clarify, the issue also occurs when only one group triggers a policy violation: the group is removed from AD, but it remains visible on the identity’s Entitlements tab.

The policy has two rules, one for each group. Could you advise why the entitlement is not updated in this single-group scenario?

4

Hello Ricardo. Thanks, the single-group test clarifies it. Since AD removes the group successfully, the provisioning is working. The stale part is the IdentityIQ Entitlements view. With direct read-write connectors, the account/Link can update immediately, while entitlement data is not refreshed until Identity Refresh runs.

You are also calling Provisioner directly from the policy rule, and SailPoint documents that policy-violation provisioning does not use workflows. So there is no normal provisioning-workflow refresh step in this path.

Since setDoRefresh(true) did not resolve it, I would avoid assuming which refresh options it applies. If you want to keep the refresh in the same code path, check the IIQ 8.4 Provisioner Javadocs for setRefreshOptions(Map) and the required option. The documented option for this case is Refresh Identity Entitlements for all links.

As a quick check, inspect the Link after provisioning. If memberOf no longer contains the group but the Entitlements tab still does, the remaining step is the Identity Refresh.

5 
Map refreshOptions = new HashMap();
refreshOptions.put("correlateEntitlements", Boolean.TRUE);
refreshOptions.put("promoteAttributes", Boolean.TRUE);
refreshOptions.put("refreshIdentityEntitlements", Boolean.TRUE);
 
// Neste teste, não voltar a avaliar policies durante o refresh.
refreshOptions.put("checkPolicies", Boolean.FALSE);
 
// Evita que o refresh desencadeie novo provisioning.
refreshOptions.put("provision", Boolean.FALSE);
 
Provisioner provisioner = new Provisioner(context);
provisioner.setDoRefresh(true);
provisioner.setRefreshOptions(refreshOptions);
provisioner.execute(plan);

Hey I tried like that but he issue remains

6

Thanks for testing that. Since those refresh options did not change the behavior, I would check the Link state next. After the policy task finishes, open the AD Link in Debug and check memberOf:

  • If the group is still on the Link, IIQ still has stale account data. I would reaggregate that account from AD. Account Aggregation reads the current accounts and entitlements from the source:.
  • If the group is already gone from the Link but still appears on the Entitlements tab, then the provisioning and Link update are fine, and the remaining issue is the entitlement recalculation. SailPoint documents that the Entitlements tab is updated by Identity Refresh.

There is also a documented refreshLinks=True Identity Refresh task argument, but I would not assume it is the same option for Provisioner.setRefreshOptions(Map) without confirming it in your 8.4 Javadocs: IIQ Console Commands.

I would check the Link result first. That should tell us which path to troubleshoot next.

7

The group is already gone from the Link but still appears on the Entitlements tab and after refresh the Entitlements tab is updated and the issues is fixed
But I would like that when the policy/rules runs the groups dissapear also from Entitlements tab without refresh

8

@RIsidoro Have you checked in the debug as well if the assignment is still showing or not? Sometimes, due to cache UI may not show you the updated details but debug xml should be updated.

9

Hello Ricardo. Since the group is already removed from AD and also gone from the Link, your provisioning is working. What is left is the IdentityIQ entitlement recalculation.

I would still do the Debug check Neel suggested. Check whether the AttributeAssignment is still present on the Identity, and if needed look at the related IdentityEntitlement separately. For the Entitlements tab itself, SailPoint states that provisioning does not refresh the detected entitlement data on its own. Identity Refresh is what updates it: Updating Identity Cube.

So I would look at it this way:

  • avoiding a separate or manual refresh task is possible;
  • avoiding Identity Refresh processing completely is not the documented path.

If you want this to happen automatically, I would trigger a refresh for just that identity after the provisioning completes. IIQ 8.4 has a documented refreshIdentity workflow-library method for refreshing a single identity. Policy-violation provisioning does not automatically invoke a workflow, so you would need to call the refresh explicitly as part of your custom remediation flow.

I think that is the cleaner direction here rather than trying to make Provisioner.execute() update the Entitlements tab by itself.

10

HEllo harish Punna and Neelmadhav Panda
In fact in the debug there is no mention regarding the removed groups .

Should I use Provisioner.execute() to start a refresh ?

11

Hello Ricardo. No, I would not call Provisioner.execute() again just to refresh. That part is already doing its job because the AD change is successful.

I would check one thing first in Debug: look at the IdentityEntitlement object separately from the Identity and its AttributeAssignment.

  • If the IdentityEntitlement is already gone, IIQ has the correct persisted state, and I would first reload the identity or session before adding more logic.
  • If it is still there, then the missing piece is the Identity Refresh that recalculates the Entitlements view.

If you want that refresh to happen automatically, IIQ 8.4 has the refreshIdentity workflow-library method for refreshing one identity. Since that is a workflow-library method, I would trigger a small workflow after the remediation rather than trying to call another Provisioner.execute() from the policy rule.

I would check the IdentityEntitlement first. That should tell us which path you actually need.

12

@RIsidoro If it is not available in the debug, you don’t need to do anything. It is just a cache issue that’ll auto update in few seconds. If someone, starting a fresh session, it will not show the assignments even in the UI.

13

Hello all

Thanks for your support