Hope everything’s well.
It happens that we are working with two different Active Directory Domain Services (AD DS) and currently we have a separate connector for each one.
We’d like to see if we can add one user existing on, let’s say, AD DS 1 to a group that exists in AD DS2.
We tried this manually and it worked because of a relationship trust between both Domain Services (talking about going to AD and adding the user from the other AD DS to a current AD DS group).
You can configure Roles and leverage the membership criteria which can used to impose fine-grained controls and assign the relevant entitlements and or access profiles once the criteria is met with.
The only thing to consider is that the identity should have the account on the ADDS2 else create operation will be invoked by SailPoint. More information related to Role configuration is here: Automating Role Assignment - SailPoint Identity Services
If you’re interested in another approach if you are using ADDS2 just to aggregate the users from then would be to leverage native rules on ADDS1 when an Add entitlement operation is successful during the After Modify Rule.
Thank you for your reply!
I understand what you suggest but we don’t want to create accounts in the AD DS where the groups exist. Instead of creating accounts in the AD DS 1 (where the groups are), we want to add the users that exist in the AD DS 2 (where we have all the users), without creating anything in the AD DS 1, only adding users from the other AD DS.
Do you think this is feasible?
@ninfante_solidigm
Unfortunately, I have only worked on this use-case wherein the accounts are existing on both ADDS1 and ADDS2 that was how the client environment was and since ADDS2 source was only for account reconciliation I had to add a native rule to add users on ADDS2 to relevant ADDS1 group.
But I think definitely someone would have worked on this specific ask of yours.
As you have mentioned that the cross domain group provisioning works manually, can you execute a powershell script to achieve the same.?
If you can execute a powershell script in the IQ service server of source 1 to grant the group membership in source 2 (or the other way), you can consider using an afterModify rule.
You may want to create a dummy group in source 1 which acts as a trigger that invokes the afterModify script.
We have same use case, we have implemented through connector rule defined where we execute a powershell script, this script is deployed in the IQ services.
Powershell script gets request information and it adds to the member.
Here is start guide documentation and it should be helpful
Hey @ninfante_solidigm!
Thanks for your post and welcome to the Sailpoint Developer Community!
Based on the phrasing of your question, you might be able to achieve this with an OOTB solution. (Especially if you were able to do it directly in AD.) The AD Connector in ISC should allow for this without having to write any connector rules.
For example, in the AD Source Configuration, you can get groups or accounts from multiple forests or domains:
○ Forest Configs: Forest Settings
○ Domain Configs: Domain Settings
○ Account and Group Configs -(This can be used to pull the groups you require from both domains.): Account and Group Settings
It’s important to note that you can only add a user from domainA to domainB when the domain group is a LOCAL group. (this is default AD behavior, you cannot add other group types)
Looking back at your example, you already created two sources per domain. (Here we call them domainA and domainB)
What you would do next is to create a 3rd source with both domain’s information in the configurations.
Then you would configure the filter to aggregate LOCAL groups to the 3rd source from domainA and domainB as well as the Accounts from those domains.
Lastly, to test this, submit an Access Request for an entitlement from domainB for a user in domainA and voila, you should see that it works.
This should work since the 3rd source will have all LOCAL groups and accounts from domainA and domainB.
Make sure that your service accounts have permissions to modify group members in domainA and domainB.
Let me know how this goes for you and again, welcome to the Community!
