Removed Entitlement Still Appears After "Remove Entitlement Passed"

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

Hi,

I have a question regarding entitlement removal behavior.

After an entitlement removal request is completed with the status “Remove Entitlement Passed”, the removed entitlement still remains visible in both the Identity Access section and the Account Entitlement Assignments list.

Even after performing an Identity Refresh, the entitlement is still displayed. The entitlement only disappears after running an Aggregation.

In a previous environment with a different source, the entitlement was removed from Access and Entitlement Assignments immediately after the “Remove Entitlement Passed” status was reached.

Does anyone know why this behavior occurs?

Is there a way to make the removed entitlement disappear immediately after the removal request is successfully completed, without requiring an Aggregation?

Thank you.

2

Hello @sxxnex ,

We have experienced the similar issue but for role assignments. What we have noticed is because of the tasks runnings (you can check in “monitor” tab). As if so many tasks are running the changes will not take effect until they are completed.

Is this happening every time for all the sources?

3

Hi @sxxnex

Are you using a Web Services connector ?

If so, does your Get Object operation (single account aggregation) return the user’s entitlements?

After a successful provisioning operation, ISC invokes the Get Object operation to re-aggregate the updated account. If the Get Object response does not include the user’s current entitlement assignments, may be ISC cannot immediately reconcile the account state.

4

Hello Sojeong. Let me try to explain the logical reason behind this behavior.

ISC keeps its own copy of every account’s data, including which entitlements belong to it. When you remove an entitlement, ISC sends that request to the target system and the target system removes it. That part worked, which is why you see “Remove Entitlement Passed.”

But the copy of the account data that ISC is holding doesn’t always get refreshed automatically after that. It depends on the connector type. Some connectors read the account back from the target right after provisioning and update ISC’s copy. Others don’t, so ISC keeps showing the old data until the next aggregation pulls a fresh copy from the source.

That’s also why Identity Refresh doesn’t help here. Identity Refresh works with the account data ISC already has. It doesn’t go back to the source to check what’s actually there. So if ISC’s copy is stale, the refresh just reprocesses stale data.

Your previous environment with a different source probably used a connector that reads the account back automatically after provisioning. This one doesn’t, which is why aggregation is the only thing that clears it.

As a quick test, try a single account aggregation instead of a full one. Go to the identity’s Accounts tab, click Actions on the account, and choose Aggregate Account. If the entitlement disappears after that, the removal is working correctly and the gap is just in how this connector syncs the data back to ISC.

If it’s a Web Services source, the part to check would be the Get Object operation and whether its response mapping returns the updated entitlement data after the removal.

Could you share which connector type this source uses? That would help narrow down the fix.

5

At the moment, we can’t verify whether this happens across all sources because provisioning is not configured for all of them.

Also, we don’t have any role configured in our environment. We checked the Monitor tab, and the only active queue is WPS - HIGH.

6

We are using a JDBC Connector.

When we run the Single Account Aggregation query manually, the user’s entitlement is returned correctly, and the changes are reflected.

However, immediately after the Remove Entitlement Passed operation is completed, the changes are not reflected automatically. We currently have to run the Single Account Aggregation manually for the entitlement removal to be reflected.

7

We are currently using a JDBC Connector.

From what I remember, in a demo tenant where we used both Web Services and JDBC Connectors, the changes were reflected in the ISC UI immediately after the Remove Entitlement Passed operation completed.

8

Thanks for confirming. Since the Single Account Aggregation query returns the correct data and the entitlement disappears when you run it manually, the query and entitlement mapping are working correctly.

The remaining question is with the automatic post-provisioning read-back. It could be getting skipped entirely, or it could be running but hitting the database before the removal is committed and visible.

SailPoint’s JDBC troubleshooting docs list a setting called skipGetObjectAfterProvision that disables the Single Account Aggregation normally performed after provisioning. I would check your source configuration through the API first:

GET /v3/sources/{sourceId}

Look for skipGetObjectAfterProvision inside connectorAttributes. If it’s there and set to true, that would explain the behavior. You can remove it with:

PATCH /v3/sources/{sourceId}
Content-Type: application/json-patch+json

[
  {
    "op": "remove",
    "path": "/connectorAttributes/skipGetObjectAfterProvision"
  }
]

If that setting isn’t present or is already false, then the connector should be running the read-back by default. In that case, I would check the VA connector logs (ccg.log) for the same Remove Entitlement request. Look for whether the Single Account SQL Query runs right after the provisioning step. If it doesn’t run despite the skip setting being absent, that would be worth raising with SailPoint Support. If it does run but still returns the old entitlement, there could be a timing issue where the database hasn’t committed the removal before the read-back fires. Things like transaction delays, triggers, stored procedures, or replication lag can cause this.

Your demo tenant experience is consistent with how JDBC is designed to work. The entitlement should reflect without a manual aggregation when the post-provisioning read-back completes successfully.

9

The skipGetObjectAfterProvision attribute was not present.

I also tested this on a JDBC Connector in another tenant. In that environment, there wasn’t a Single Account Aggregation query either, but as soon as the Removed Entitlement operation completed successfully, the entitlement disappeared from the UI immediately.

Thank you.

10

Since skipGetObjectAfterProvision isn’t present and the other tenant works immediately without even having a Single Account SQL Query, this looks like something tenant-specific or environment-specific on the affected source.

A few things worth comparing between the two tenants before going to Support:

  • How the Remove Entitlement is configured. Whether it uses a removeEntitlementSQL query directly or a JDBC Provisioning Rule, and whether the SQL or stored procedure commits the change immediately.
  • The VA (Virtual Appliance) version and the JDBC connector version on both tenants.
  • The ccg.log from the VA on the affected tenant during the Remove Entitlement operation. This would show whether anything runs after the provisioning step and what it returns.

If the configurations match and the behavior is still different, I would recommend opening a SailPoint Support case. The manual Single Account Aggregation works as a workaround, but it shouldn’t normally be needed after a successful entitlement removal.

11

Thanks for your suggestions and for taking the time to help.

I found that the issue was with the Single Account SQL Query. After updating the query, the entitlement removal is now reflected correctly.

I appreciate your guidance!