We have only one forest acme.it and
2 subdomain gt and gos and
2 sub-subdomain extra and intex
I need to integrate these 4 sub-domains.
In the extra domain are present all the Supplier users.
In the gos domain are present all the employees.
A supplier of extra domain has an internal manager present in gos domain.
A supplier of extra domain can have groups present in any domain (gos, intex ecc…).
What is the best solution to integrate these 4 domains ?
If I use 4 different sources I cannot set gos groups to extra users (cross groups), I think !!!
If I use a single source with multiple domains can I have some problems ? (example: groups with same name in different domains are problems or in the request center I don’t know the domain owner of a specific group or other downsides of this solution).
Below is some general guidance based on typical SailPoint IdentityNow and Active Directory best practices when dealing with multiple domains in a single forest. Ultimately, every environment is unique, but these points should help you decide whether to configure a single AD Source (with multiple domain configurations) or set up multiple Sources:
1. Cross-Domain Group Assignments
Single AD Source:
If you want to manage cross-domain group membership in IdentityNow (e.g., user in extra domain is assigned a group that resides in gos), this is far simpler with one AD Source that is configured for multiple domains. IdentityNow will have a consolidated view of all users, groups, and memberships across the forest.
Multiple AD Sources:
Managing cross-domain group memberships is not straightforward when each domain is a separate Source. You can certainly onboard each domain as its own Source, but out-of-the-box, you cannot seamlessly assign or manage a group from gos to a user from extra if they live in separate Sources. IdentityNow treats each Source as a separate system.
Recommendation: If cross-domain group assignments are a key requirement, one single Source with multi-domain support is generally the best practice.
2. Handling Duplicate Group Names
Potential Name Collisions:
In a large organization with multiple subdomains, group name collisions (e.g., two groups named “IT-HelpDesk” in different domains) are possible. IdentityNow will still treat these as distinct entitlements because they have different distinguished names (DNs).
How IdentityNow Distinguishes Groups:
The “native identity” of a group typically includes its full DN (e.g., CN=IT-HelpDesk,OU=SecurityGroups,DC=extra,DC=acme,DC=it).
The entitlement display name in IdentityNow can include domain or OU information if you configure it that way.
You can always customize how SailPoint displays these entitlements so it’s obvious which domain they belong to (e.g., using a naming convention or including domain info in the display name).
Recommendation: If duplicate group names are a concern, configure the entitlement display name to include domain indicators. This solves most confusion around “which domain owns which group.”
3. Manager References Across Domains
Single AD Source:
When a user in the extra domain has a manager in the gos domain, the single Source approach makes it much easier for IdentityNow to resolve and display the correct manager attribute (assuming AD trust relationships exist and the SailPoint service account can read the manager attribute across domains).
Multiple AD Sources:
If you split each domain into separate Sources, you must ensure that the manager references are either resolvable across Sources or that you use correlation rules to link them. It can become more complex to maintain manager references cleanly.
4. Request Center (Service / Access Requests)
Single AD Source:
All AD groups, across all domains, appear in one place in the Access Request user interface. That usually simplifies the user experience—searching for a group shows results from all subdomains.
Multiple AD Sources:
You can still show entitlements from multiple Sources in the Request Center, but you would see them grouped by Source. If an end user doesn’t know which Source (i.e., domain) a group lives in, it may add extra confusion.
5. Granular Control vs. Unified Management
Single Source:
Pros: Simplifies cross-domain group management, manager resolution, and a single place for configuration changes.
Cons: Potential confusion if you do not set up naming conventions to differentiate groups or objects across domains.
Multiple Sources:
Pros: Fine-grained control over each domain (e.g., different admins for each domain, different provisioning policies). Possibly clearer segmentation if you truly treat these domains as independent security zones.
Cons: Harder to manage cross-domain relationships (manager references, group assignments), more complex design, and potential duplication of identity records if users exist in multiple domains.
6. Typical Best Practice: One Source for the Entire Forest
In most single-forest AD environments, the recommended approach is to configure a single “Active Directory” Source in IdentityNow with the connector set to discover all the domains in that forest (subdomains and sub-subdomains). This ensures:
Unified Identity and Group Data:
Users from all domains appear under the same Source, so entitlements (groups) and memberships are managed in one place.
Seamless Manager Lookups:
Cross-domain manager references are automatically resolved.
Cross-Domain Membership:
A user in the extra domain can be assigned a group residing in the gos domain without any extra complexity.
Simplicity in Requests:
You only have one AD Source to maintain from a lifecycle perspective (e.g., a single place to schedule aggregation, define provisioning policies, etc.).
Note: To avoid confusion around groups with the same name in multiple domains, configure your entitlements so domain or OU context is visible. This can be done via SailPoint’s entitlement customization—either in the provisioning policy or by adding domain details into the Display Name logic.
7. References
SailPoint Connector Guide:
The SailPoint IdentityNow Active Directory Connector Guide outlines multi-domain and single-forest scenarios. Typically, it highlights that as long as a trust is established and the account you use for the connector has permissions across domains, you can manage them in one Source.
Final Recommendation
Given your requirements:
Cross-domain manager references (supplier in extra → manager in gos).
Cross-domain group assignments (supplier in extra can be assigned groups from gos or intex).
The most straightforward design (and commonly recommended practice) is to use a single Active Directory Source in IdentityNow, configured with multi-domain support. This avoids the headaches of cross-domain provisioning and simplifies the overall architecture. You can mitigate any potential naming overlap by including the domain name in your group display names and by ensuring your AD connector service account has the appropriate permissions in all child domains.
