I have a few sources where entitlements are replicated from another source.
Examples:
Azure Active Directory - We have ADConnect, and replicate AD Groups into AAD because they are useful to also use in Azure Active Directory in a read only way.
Servicenow - We have a task that pulls AD Groups into ServiceNow, because they are useful to use in ServiceNow in a readonly way.
We set entitlement filters on these sources as they are managed elsewhere (AD). We dont want these entitlements to be associated with ServiceNow or AAD.
However, when we load accounts from these sources, the account load operation brings these entitlements back in. This creates duplicates of entitlements, and these duplicates show up in other places of IDN, creating confusion, and a reduction in perceived quality/robustness in the platform.
How can I not have these entitlements brought into IDN on the ServiceNow or Azure Active Directory sources? The source entitlement filters are not complete/donât work in these scenarios.
Hello Chad,
What type of aggregation you try to perform on those ServiceNow or Azure AD source ?
Account Aggregation alone or Entitlement Aggregation too.
It seems that IDN is âlearningâ about entitlements via the account aggregation and ignoring the entitlement filtering that we have set on the source.
This bad data then confuses us/adds clutter in other areas of IDN (AI/ML, certifications, etc.)
If I am a source admin, and very knowledgeable about my source, and know that I donât want certain entitlements to come into IDN, how do I do that?
It works on the âpure entitlementâ source configuration side, but then the source later âallowsâ additional entitlements to be seen from the source in other views.
From what I understand it has something to do with account aggregation? that the source can find out about entitlements via account aggregation?
These entitlements that should be filtered out then show up in other IDN things like certifications/access history, etc.
Maybe another way to say this is that the looking at entitlements from an account perspective fails to consider the sourceâs entitlement filtering criteria?
Entitlement filters prevent a source from aggregating certain entitlements that are available on a source so they do not appear available for use in access profiles and request center. This works well when your source has entitlements that arenât being used by any accounts and you want to filter them out.
However, account aggregations will still bring in any entitlement that is assigned to at least one user on the source by design. This is for visibility into who has access, and what they have access to, so that it can be remediated via certification campaigns if necessary. If account aggregations honored the entitlement filter then this would break the visibility and governance feature of identity access because the source would be giving access to accounts that IDN can not see or govern.
It might be worth a professional services engagement to explore options for this scenario you have encountered.
I do not agree with your statement " This is for visibility into who has access, and what they have access to, so that it can be remediated via certification campaigns if necessary. If account aggregations honored the entitlement filter then this would break the visibility and governance feature of identity access because the source would be giving access to accounts that IDN can not see or govern."
For example:
Azure Active Directory:
on premise active directory groups are replicated into Azure Active Directory. This is a very standard operation that I would expect near 100% of companies using AAD do.
These groups are read-only in Azure AD. They cannot be changed in Azure Active Directory (because they are mastered in Active Directory)
However, SailPoint considers these read only replicated groups as entitlements on the Azure Active Directory Source.
A certification campaign involving AAD source CANNOT remediate these entitlements, as they are not actually mastered in the source SailPoint is listing them on. They are read only on the AAD Source, and I am actively trying to use entitlement filtering to exclude them. Only a certification campaign involving the AD source can remediate these entitlements.
It sounds like IDN is simply assuming that any entitlement coming from a source is authoritatively managed there.
This is unfortunately not true, and I was trying to use entitlement filters to help correct this, but it doesnât sound like its possible?
Itâs not possible through entitlement filters, but itâs likely that our professional services team has encountered a scenario like this with other customers. I highly recommend contacting your customer success manager to schedule a professional services engagement if possible. If you do manage to find a solution to this, we would greatly appreciate it if you can update the community with the solution to help others in the future.
It sounds like a custom rule? Might be able to be used here.
what is strange is that this seems like it should be a checkbox in the connector configuration, as the rule filter is static that requires no customer related information.
So would this be something like a generic rule that would be attached to the account aggregation for the particular sources were we modify the attributes on that link removing the extraneous group memberships?
That might work, but I admittedly donât have enough experience with connector rules and modifying aggregation plans to know what the ramifications of this approach would be.
Has a resolution been found by anyone? This is an age-old issue with the Azure/Entra source. Filtering the on-prem mastered security groups from the Entra source would remove a ton of noise coming into the system. You canât do anything with them anyway. If you try to remove the group in Entra via IDN, it throws an error saying you canât do that.
We have contacted SailPoint directly and did not get a resolution. We have been told it is possible to filter if we were using IIQ but does not look to be possible in IDN even with the assistance of SailPoint professional services.
We are a relatively smaller organization and only have about ~3000 AD entitlements that would be replicated into AAD; we also use an on-premises dynamic groups engine that recalculates groups multiple times a day.
As others have noted, the lack of this IDN capability adds significant noise and confusion to our Access History, and Certifications when the AAD/Entra source is added.
So, we have currently stopped our plans to use IDN for AAD/Entra IAM.
As we have a lot on premise, but some critical things in Azure/Entra we were hoping to manage with IDN, this has caused some negative IDN sentiment.
The simple design assumption/shortcut that every entitlement from a source can be mastered in that source is false.
We need to be able to configure entitlement filtering on the account aggregation feed.
This came up for us as well but wasnât a priority for us to address. I stumbled upon this thread looking for something else and figure it might be worth looking into it a bit more. I came across this group filter that seems like it filters out non-cloud only group types. Putting this into the Group Aggregation filter in the Azure connector significantly reduced the groups.
This seems like it will work. I applied it to our Azure source filter and tried it through Postman with the Microsoft Graph API. I am just still working on making sure this doesnât filter too much as I am not fully an export on this value and what is populated in this attribute for the other Azure groups.
I am going to keep researching, just wanted to post this to throw out an idea and see if anybody had any additional thoughts to provide. Here is the Microsoft forum where I first saw this filter idea.
I apologize if there was any confusion, but I didnât intend for my previous post to be the solution to the problem, just something I had come across that seemed interesting that might be able to be leveraged to achieve the desired outcome.
With that being said, it seems like there is a potential workaround that could be helpful depending on your requirements. If the entitlement aggregation with that filter removed the on-prem entitlements from IDN and the account aggregation captures all of the entitlements, then the order could be reversed. Run an account aggregation to get all memberships then an entitlement aggregation after to remove the on-prem groups.
Obviously this would keep pulling in the on-prem groups then deleting them shortly after, but if the aggregations are only run once a day in the mornings, for example, it might not be that noticeable and most of the day these on-prem groups wouldnât be visible in IDN and thus wouldnât be included in any role discovery or certifications being generated during the day.
I am still curious to see if there is a way to apply a filter overall that prevents these groups from ever appearing and Iâll see what I can figure out.
Calling the /user endpoint would not allow for filtering of different entitlement types according to this post since the $expand property is needed and that doesnât support filtering operations. However, making the call for individual users does allow the memberOf attribute to be filtered. I am just trying to get a better understanding of the Graph API and the calls this connector is making to share any helpful info to find a more ideal solution, if one exists, in lieu of the OOTB connector being updated.
