SailPoint AD — How to create a second account in the same Source with a different suffix from an ITSM request?

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

Hi everyone, good morning!

I have an implementation question about SailPoint ISC with Active Directory integrated with an ITSM tool.

Scenario:

  • I have a single AD Source governing accounts.

  • When an ITSM request comes in, depending on the AD group being requested, I need to create a second AD account for the same user with a different naming pattern. Example: requesting the “Cofrezz” group → create an AD account ending with “zz”, and populate some fields like EmployeeNumber and extensionAttribute11.

  • There are other scenarios besides “zz”, such as accounts ending with “xx”, “hh”, etc. In all cases, the creation of the additional account must be controlled by a specific AD group (the group works as a “trigger” for the account type).

  • Also, each scenario may require a different target OU.

In addition to creating the account, is it possible to set the OU and populate attributes like EmployeeNumber and extensionAttribute11?

Questions:

  • What is the recommended approach so that, when this entitlement/group is requested, SailPoint creates a new account with the correct suffix in the same Source, instead of trying to apply the default provisioning logic within the AD Source?

  • I considered creating a second Source with LDAP filters to handle only this scenario (for both accounts and groups). What do you think about that approach?

  • I also thought about using a Before Rule (PowerShell/IQService) reading something from the provisioning request to decide the suffix and create the additional account. Is there a better approach or a recommended pattern for this type of scenario?

If anyone can share best practices and a high-level flow, that would help a lot.

Thanks!

2

I would create a new source targeting a different OU, and utilizing your other Create Account settings. Then make sure your requestable entitlements or access profiles are using that new source. It is the easiest way to do it.

Trying to do it with one source could cause a lot of issues. You would have to define Multiple Account Logic on all of your Access Profiles.

BeforeProvisioningRule might work, but I am not sure how well ISC would handle submitting a request with one NativeID and then getting a response with a completely different NativeID.

1 Like
3

@henriqueoliveira2026 As @Carlatto mentioned, the best way is to create a second source. If possible have a separate set of entitlements that is applicable to the second source alone, else create Access Profiles with the names which the users can differentiate. Otherwise, it will cause confusion for users while raising access requests.

4

How do I make sure that entitlements will come through that specific source? Do I also need to restrict in the AD Settings, where it reads the entitlements from?
i.e. in AD-Source-1 have OU=Entitlements-1, and in AD-Source-2 have OU=Entitlements-2 ?

Something like that? I’m not sure otherwise.

Thanks in advance

5

Hi @henriqueoliveira2026 ,

To ensure entitlements are tied to the correct AD source, you just need to separate them at the aggregation level. Each AD source should have its own Group Base DN so it only reads entitlements from the OU you intend. For example:

  • Source 1: OU=Entitlements-1,...

  • Source 2: OU=Entitlements-2,...

Once that’s in place, ISC will automatically associate each group with the correct source, and your Access Profiles will map cleanly without needing Multiple Account Logic or custom rules. This keeps the configuration simple and avoids duplicate or conflicting entitlements

Thanks,

1 Like
6

Hello, everyone.

Thank you all for responding; creating a new source seems like an excellent solution.

Thank you.