I am looking for some feedback regarding a behavior that I am observing within SailPoint “Access History” portal, and trying to determine if this is normal or some weird bug. My organization has dozens of access profiles and roles. Most of the roles are mapped to one access profile. I have noticed that when looking at many of our users within the access history, they have multiple access profiles, but only one role.
For example, I have user “Smith, James”, who per SailPoint, has the “Deposit Student” and “High School Student” access profile, but the role that they have is “Deposit Student” (which is correct). The criteria that must be met to be part of the “High School Student” access profile does not match the criteria this user has. The entitlements (which are just AD groups) that a “High School Student” access profile has matches the entitlements that the AD account “Smith, James” is a member of. Is this a bug, or is this related to SailPoint’s certifications? We are not actively using certifications, but I am not sure if this access history behavior is by default “enabled”.
Your configuration is correct in the sense that it will auto assign these access profiles and respective AD groups to the identity, however, ISC will also identify if the identity’s azure account is also part of another Azure group which might have been granted outside of ISC. In this case, the “High School Student” group
I may be mistaken but I believe the Access History is part of the Identity AI feature set which will be there if your organisation has it as part of their SailPoint licence and agreement.
If you don’t have access history you should be able to check within AD or with the AD management team in your org to see if this group was granted earlier or potentially via another method.
If a user has an entitlement or entitlements that combine together to form an access profile, the user will be tagged to that access profile automatically in ISC. It has nothing to do with the roles that you have configured.
eg. AP1 contains only ENT1 and user has ENT1, Then user will be auto tagged to the AP1, irrespective of how ENT1 got assigned to the user.
The user will be tagged to a role only if the role membership criteria is satisfied.
One to thing to remember wrt what @jesvin90 mentioned if that identity starts matching the ROLE criteria and it gets assigned to identity, it will just encapsulate the existing AP’s which were part of that role.
But if ROLE stops matching the criteria then dont expect it to also remove the encapsulated AP, as that AP & entitlements were not assigned by the virtue of ROLE detection but by the virtue that source had those entitlements assigned to that identity.
Simply, understand one thing, IDN can detect AP if the entitlements that constitute the AP are already assigned to that identity, IDN does not support AP detection based on criteria. And Role will be only detected based on a criteria.
@Irshaad_Laher_WS@jesvin90@harshamin9 Thank you for your responses! It has clear my confusion on my end and now I am aware that this is the expected behavior by IDN. Thanks again!
