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

Identity Security Cloud (ISC) ISC Discussion and Questions
, , , ,
1

In SailPoint Identity Security Cloud (ISC), we have several applications that do not have direct connectors and are provisioned exclusively via Active Directory security groups.

We are trying to understand the correct and supported approach to represent these applications so that access is requestable and certifiable at the application level, not just under Active Directory.

Specifically:

  1. Is the recommended pattern to model this access directly under the Active Directory application using access profiles and naming conventions?

  2. Is there a supported way in ISC to associate AD group entitlements to a specific application object, so access appears application-centric in requests and certifications?

  3. If governance-only applications are expected to be used, what configuration produces consistent results in the UI?

Any guidance or confirmation on current ISC capabilities or limitations would be appreciated.

2

You can assign the AD groups and based on that active directory group, application access will be provided.

You can create a Application object with the name of your target app and assign the entitlements on that Application object.

Users can get that application to have the AD group.

Let me know if it does not make sense. I will guide you for the proper steps.

Thanks

3

Thanks for the response.

I want to clarify a couple of points to ensure we’re aligned with how ISC actually behaves in the UI.

In our tenant:

  • AD groups are aggregated under the Active Directory source

  • When creating an Application object, there is no option to directly assign AD group entitlements to the application itself

  • Entitlements can only be selected via Roles or Access Profiles, and provisioning still executes via the AD source

Could you please clarify:

  1. Where exactly in the ISC UI are AD group entitlements assigned directly to the Application object? (menu path would help)

  2. Are you referring to assigning AD groups via Roles or Access Profiles that are then associated to the application?

  3. When users request access, does it appear under the Application name or still under Active Directory in requests and certifications?

If possible, step-by-step guidance would be very helpful

Thanks for your help.

4

@ebesamuel2

The Application model does not has the option to directly add entitlements .It can only add access-profiles which is nothing but a group of entitlements.

If you want to directly request entitlements better you can make them requestable and allow end users to access via request center

5

Here We cannot add entitlements directly. create an access profile ,include entitlements in that.

Add the access profile in the application.

6

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

7

Hi @ebesamuel2 Yes, in your case you must select the connector as Active Directory and Yes it results in showing the duplicate entitlements with the AD group names with 2 different sources. (I do have this scenario in my current customer setup). We are onboarding every AD application into a new source.

8

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.

2 Likes
9

Does the fact that it is ‘not needed by the application owners’ mean it should not be done? Application owners have a functional requirement of authentication and authorization and it should not matter how that is handled technically.

We are at the very beginning of our journey but we will push a standardized policy and application owners won’t get the choice to stay with current AD AuthN groups. Our IAM reference architecture already states (for years) that AD/Entra is only for authentication and that authorization should already be done within the application where ever possible and applications need an architecture exception if it isn’t possible.

So either you will have to onboard an extra AD source to manage groups for only one application and maybe have to do the same for other applications, or you still onboard the application itself. Just a though, not knowing if this even is feasible in your company :slight_smile:

KR, Roel

1 Like