Problem
In modern Identity Governance and Administration (IGA) implementations, integrating legacy applications into SailPoint Identity Security Cloud (ISC) often presents significant challenges:
- No API Support: The legacy application lacks REST or SOAP endpoints.
- Restricted Database Access: Direct database connection (JDBC) is blocked due to security constraints.
- No Flat-File Capabilities: Disconnected / CSV-based manual integrations are out of scope due to audit and security requirements for automated provisioning.
Despite these constraints, organizations still require automated lifecycle management, periodic access reviews (Certification Campaigns), and Segregation of Duties (SoD) enforcement for these applications within a single pane of glass.
Diagnosis
Instead of attempting unsupported custom connector builds or unautomated file drops, the optimal approach is to isolate the application’s specific AD scope and configure a dedicated, logically named Active Directory Source in SailPoint ISC. This satisfies automated governance and lifecycle requirements without requiring direct changes to the legacy application’s core infrastructure.
Solution
When an application relies on Active Directory (AD) for authentication and access authorization (e.g., via Kerberos/NTLM and AD Security Group memberships), we can use a Logical Integration approach.
By creating a dedicated Active Directory Direct Source in SailPoint ISC specifically scoped to that target application’s AD objects, ISC can manage account lifecycle, provision/deprovision access via AD groups, and run governance controls natively.
Step-by-Step Configuration Guide
Step 1: Establish AD Group Naming Conventions
Work with your Active Directory and Application teams to create AD Security Groups representing application roles/access.
Best Practice: Use a strict, predictable prefix nomenclature for easy filtering and isolation in ISC.
- Example: _github_read_group, _github_readwrite_group, _sailpoint_github
Step 2: Create and Name the Source in SailPoint ISC
- Navigate to Admin > Sources > Add Source.
- Select the Active Directory connector type.
- Name the source after the Target Legacy Application (e.g., GitHub), not generic “Active Directory”.
- Why? This ensures clarity in Governance reports, Access Requests, and Certifications, making it clear to business users that this source represents access to the specific target application.
Step 3: Configure Base Connection & IQService
- Configure Forest Settings and Domain Settings (Service Accounts, gMSA, IQService details, and Port settings).
- Perform a Test Connection to ensure connectivity between your Virtual Appliance (VA) / IQService and the AD Controllers.
Step 4: Configure Account & Group Filters (Scoping)
To prevent aggregating unwanted domain users or unrelated AD groups into this logical source, precise LDAP filtering is essential.
Navigate to Account and Group Settings and configure the following:
1. LDAP Search Filter (Accounts)
Filter user accounts so ISC only aggregates users who are members of the target application’s AD groups:
(&(objectCategory=person)(objectClass=user)(|(memberOf=CN=_github_read,OU=Groups,OU=Resources,DC=lab5,DC=test,DC=com)(memberOf=CN=_github_readwrite,OU=Groups,OU=Resources,DC=lab5,DC=test,DC=com)))
2. Group Membership Search Filter
Restrict member group queries specifically to the app-related groups:
(&(objectClass=group)(|(cn=_sailpoint_github)(cn=_github*)))
Step 5: Configure Group Search Scope (Entitlements)
Under Group Search Scope, define the exact container and LDAP filter to ensure entitlement aggregation only imports groups belonging to this target application:
- Search DN: OU=Groups,OU=Resources,DC=lab5,DC=test,DC=com
- LDAP Search Filter:
(&(objectClass=group)(|(cn=_sailpoint_github)(cn=_github*)))
Testing and Validation
-
Test Connection: Confirm connectivity to AD via IQService.
-
Account Aggregation:
· Run Account Aggregation.
· Verify that only users with the designated application AD groups are brought into ISC.
· Verify that uncorrelated or out-of-scope AD users are excluded.
- Entitlement Aggregation:
· Run Entitlement Aggregation.
· Confirm that only application-relevant AD security groups appear as entitlements.
Post-Setup & Governance
Once aggregation is verified:
- Access Profiles & Roles: Build requestable Access Profiles or automated Birthright Roles linking to these application-scoped entitlements.
- Lifecycle Management: Configure provisioning policy actions (Add/Remove AD Group) so ISC drives automated access assignment/revocation.
- Certifications & SoD: Include these logical entitlements in standard Access Review Campaigns and define Segregation of Duties (SoD) policies in SailPoint ISC.
Key Takeaways
- Logical Integration bridges the gap for legacy apps lacking modern integration mechanisms (APIs/DB/CSV).
- Proper LDAP filtering is critical to avoid duplicating full Active Directory footprints across multiple logical sources.
- Target-application naming for AD sources delivers a clean user experience for Access Requests and Governance Reviews.




