ISC: Access profile "Apply changes" doesn't assign new APs to identities

Feedback Bugs
, ,
1

What problem are you observing?

We have created multiple access profiles.
They were created as enabled, not available for request, each AP contains exactly one entitlement. Multiple users have these entitlements.

After creating them we have clicked on “Apply changes” on the Access profiles page (xxx.identitynow.com/ui/a/admin/access/access-profiles/landing)

grafik
grafik565×123 5.73 KB

We have waited a couple of minutes, after which there was no monitor tasks visible.

We have tried to create certification campaigns for these access profiles, but NO identities appeared to have them. Going to the Access page for an identity, we saw that NO access profiles were present, although they had the entitlements present.

grafik
grafik1341×471 18.8 KB

Clicking on “Apply changes” again did NOT help.

After triggering an unoptimized aggregation on the authoritative source, the APs finally appeared both on the identities and in the certification campaign.

What is the correct behavior?

When we create/modify/delete access profiles and we click on “apply changes”, the changes should reflect in the entire system (identities, search, campaigns etc).

What product feature is this related to?

ISC access profiles, identities, campaigns, search.

When you create or edit identity profiles, roles, or access profiles, you must manually initiate identity processing to update your identities. This is required to apply your access model updates to your identities and recalculate access requirements, even when the identities have not changed.

What are the steps to reproduce the issue?

  • Create AD entitlement
  • Assign AD entitlement to AD account
  • Assign AD account to identity
  • Create access profile, containing the AD entitlement
  • Click on “Apply changes”
  • Wait for the (unspecified) time until the changes are applied
  • Check on the access page for the identity if the access profile is present or not

Do you have any other information about your environment that may help?

Many unanswered questions for SailPoint. It seems they keep optimizing the processing on their side, but we remain with unexpected behaviour that it is time consuming to debug.

2

2024-11-25:

This is to update that the case has been picked up by engineering team and they have started to work.
I will keep a tab on the updates and relay on this case.

2024-11-28:

This is to provide a followup that after a deep dive , the internal case has been moved to a new team who specifically owns refresh microservices.

They are yet to review the logs that have been transferred, I will send another update soon.

2024-12-09:

We are still waiting for the engineering to come back with an ETA

We’ve seen a similar issue where entitlements modified on the backend are not getting overwritten by roles defined in ISC by the period “refresh”, only if you re-process the identity individually.

3

SailPoint Support (emphasis mine):

Upon further checking as per design, apply changes on access profiles are brought into affect when there is atleast a single role in enabled state,

Who exactly “designs” these processes?
For me this sounds like a bug, why does SailPoint says “per design” so often?

4
  1. So, looks like the having atleast one role in enabled state is needed to do the apply changes.

I will come back with a documentation link if not, I will raise a documentation defect.

SailPoint still pushing that the documentation should be improved, not the logic in the product. :partying_face: