I’m running into a design/architecture issue around Azure AD group memberships and how they surface in SailPoint IdentityNow, and I’m looking for best‑practice guidance.
Current Situation
Users receive membership to several SPE_E5* groups.
These SPE_E5 groups are nested under a single parent group:
PPC-License-M365E5-Full.
This parent group is assigned to all users in Sailpoint as a birthright rule.
In SailPoint IDN, the nested SPE_E5 groups appear as individual entitlements per user, but:
They are not part of any Access Profile.
Only the parent group PPC-License-M365E5-Full is part of an Access Profile and is provided as birthright.
Constraints
Azure application management has confirmed:
The Azure birthright rule cannot be changed.
The logic cannot be moved to SailPoint provisioning.
Impact on Certification Campaigns
For the manager certification campaign:
I can filter out these SPE_E5 entitlements using a prefix filter.
However, the clean SailPoint design ideally follows the structure:
Role → Access Profile → Entitlement,
and this situation breaks that alignment.
Question
How would you handle this scenario?
Specifically:
Would you maintain filtering as the long‑term solution?
Would you model the nested groups differently?
Or would you adjust the Access Profile design, even though Azure controls the actual assignment?
This is an excellent question, and you’ve run into a very common scenario when managing Azure AD entitlements in Identity Security Cloud (ISC).
Why This is Happening: Expected Connector Behavior
The behavior you are seeing is expected. The SailPoint Azure AD connector is designed to provide full visibility into a user’s access, which includes aggregating all group memberships—both direct and nested—as individual entitlements on an identity. Even though the user gets access via the parent group (PPC-License-M365E5-Full), the connector correctly identifies and displays the inherited memberships from the nested SPE_E5* groups.
Your Approach is Correct: Filter in Certifications
Your instinct to filter these entitlements out of certification campaigns is the correct and recommended best practice for this situation. Here’s why:
Maintains Governance Visibility: By aggregating all entitlements, you maintain a complete and accurate record of all access a user has within ISC. This is crucial for overall identity governance and for other processes like access reviews and reporting.
Reduces Certification Fatigue: For birthright access that is managed automatically by a parent group, it doesn’t make sense for reviewers to have to certify each individual nested entitlement. This leads to “certification fatigue” and can reduce the effectiveness of your campaigns. By filtering them out, you allow reviewers to focus on the access that truly needs their attention.
How to Filter in Certification Campaigns
You can easily filter these entitlements when you create your certification campaigns. When you get to the “Entitlements” section of the campaign setup, you can use a filter to exclude entitlements based on their name. In your case, you would use a filter like:
name NOT startsWith "SPE_E5"
This will include all entitlements except for the ones that start with “SPE_E5”.
A Note on Access Profiles
You mentioned that the nested entitlements are not part of any Access Profile. This is also perfectly normal and expected for this type of inherited access. Access Profiles are typically used to bundle entitlements to make them requestable by users. Since this access is granted via a birthright parent group, there is no need for the nested entitlements to be part of an Access Profile.
In summary, your understanding of the situation is spot on, and your proposed solution is the correct one. Keep aggregating the entitlements for visibility, but filter them out of your certification campaigns to keep them focused and effective.