How should AD group–based application access be modeled in SailPoint ISC?

[RAKRHEEM (Rakesh Bhati)]

@ebesamuel2

Thank you all. I think I am stuck even before getting to assigning access profiles or making entitlements requestable, so I want to clarify the base issue first.

1. We have Active Directory fully onboarded in ISC with provisioning and deprovisioning enabled, and all AD group entitlements are being aggregated correctly.
2. We are planning to onboard additional applications into ISC. During discovery, the application owners confirmed that no direct provisioning is required and that access to these applications is governed entirely via AD group membership.
3. Since access is governed by AD entitlements, these applications are currently not defined as individual applications, and access certifications today would only occur at the Active Directory level.

My confusion is around the next step:

• If we want to define these target systems as separate applications in ISC for governance purposes, do we need to select the Active Directory connector again when creating those application objects?
• If yes, would that not effectively result in duplicate AD applications with different names pointing to the same AD connector?
• I do not see any other connector option for this use case apart from Active Directory

Hi @ebesamuel2,

You do not need to create separate application objects for these AD-governed systems in ISC. Creating duplicate AD sources pointing to the same directory is not supported or recommended. Instead, the application distinction happens at the Access Profile layer on your existing AD source. You model each logical application by:

Grouping the relevant AD groups into application-specific Access Profiles.

Using naming conventions (e.g., “App1 - Admin Access,” “App1 - Read Access”)

Making those Access Profiles requestable

This way, certifications and requests can be scoped by Access Profile naming patterns, giving you application-level governance without creating separate application/source objects. The AD source remains singular; governance becomes application-centric through Access Profile design. This is the standard ISC pattern for AD-governed apps.

Let us know if this was useful to you and helps you make decision.