Hi @sergiocartamilgolpe
I went to this dilemma before, like 4 to 5 years back so first I needed to understanding the Issue then decide how to resolve it with the suitable way for the project and also with some best practices
– How IIQ Tracks Entitlements? and Why It Matters?
In IIQ, entitlements are managed as Application Attributes that define the permissions or access rights assigned to an identity in a target system (e.g., AD). When an entitlement is assigned to a user via LCM, Roles, or Direct Assignments, IIQ maintains a record of this assignment in multiple places:
A. Identity Object: The user’s identity in IIQ stores assigned entitlements.
B. Application Account Links: Each identity has an account link to the corresponding system (e.g., AD).
C. AttributeAssignments Table: This maintains entitlement assignments, even if the user no longer has the actual access in AD.
D. Provisioning Plan & Tasks: The provisioning Engine executes entitlement assignments based on business logic.
When you manually remove an entitlement from AD, IIQ is not automatically aware of this change unless it is explicitly told to remove it.
This results in the following behavior:
- During Aggregation (Data Collection from AD → IIQ):
- IIQ correctly marks the removed entitlement as missing because it no longer exists in AD.
- A warning is shown in the UI: “This entitlement does not exist in the account.”
During Identity Refresh (IIQ Enforcing Governance Rules):
Since IIQ still stores the entitlement in AttributeAssignments and Identity Mappings, it believes the entitlement should still exist.
The system creates a provisioning request to restore the entitlement back to AD, even though it was manually removed.
Why is IIQ Re-Provisioning the Removed Entitlement?
The key issue here is that IIQ believes the entitlement was unintentionally removed and attempts to correct it by re-provisioning it during Identity Refresh.
This most probably happens because:
A. IdentityIQ Uses “Sticky” AttributeAssignments
When an entitlement is assigned via LCM, it is stored in AttributeAssignments.
If an entitlement is missing in the aggregated account but still exists in AttributeAssignments, IIQ assumes it was removed by mistake and attempts to restore it.
This is why you see the warning in the Identity UI (entitlement is missing) but IIQ still adds it back.
B. Identity Refresh Task is Configured to Restore Missing Entitlements
The Identity Refresh Task evaluates identity data and ensures users have the correct entitlements.
If an entitlement is missing in AD but still exists in IIQ’s data model, the task triggers provisioning to fix the inconsistency.
This happens because LCM believes the entitlement should be enforced.
C. No Automatic Cleanup of Stale AttributeAssignments
Even after aggregation detects that the entitlement is missing, IIQ does not automatically remove it from the AttributeAssignments table.
This leads to IIQ restoring the entitlement because it believes it is still valid.