Our installation of IIQ has connectors for secondDomain and thirdDomain. These connect and provision just find on their own, but we do have users that have or need memberships to groups on a different domain than they currently reside in. For example: my AD account lives in secondDomain.firstDomain.com, but I need to be a member of some group that lives in thirdDomain.firstDomain.com. This is easily handled manually in ADUC, but I just can’t seem to figure out how to implement this properly in IIQ.
Currently, if I tried to add a user from one domain to a group from another domain, IIQ will attempt (and sometimes succeed) with creating a secondary account for the user on the domain that the group lives in. Similarly, if we try to remove a group from one domain from a user in another domain, the provisioning transaction simply fails.
Is there a proper way to handle this? I’ve searched around and I’m probably not looking in the right place as I have yet to find any topic that addresses this specific problem. We don’t want to create an account for a user on the domain that the destination group resides in - we simply want to grant them membership to the group. Is this even possible?
Is there a trust relationship established between these domains? I’m making the assumption that you’ve configured all these domains within a single Active Directory (AD) application, and your groups are set as universal groups.
Is there a reason you had to create 2 separate Applications for these domains? Would you not want to (or were you not able to) create one Application and have both domains added to the same under Domain Configuration?
@sunnyajmera there is definitely a trust relationship between the domains. As far as I know, all of our groups are universal. @iam_nithesh the reason for the separation is that there’s a set of users to live exclusively in one domain, and then another set of users that live in the other. Such is the same for groups, though there are cases where users from domain A have memberships to group from domain B (it’s not common, usually only for some sysadmins). We needed to be able to manage each domain separately, though I do see your point and that might have even been a lot more beneficial when they first brought SailPoint online at our enterprise. Unfortunately I was in a totally different role when this happened so I didn’t have any weigh-in.
I don’t think that you can manage this cross Group membership provisioning without creating AD account. It would be interesting to see if there is any OOTB workaround.
You can manage this with 2 AD applications, each on its own. If any challenges here, we should be able to fix them.
Quicklinks
You can create a Quicklink for cross domain AD group membership.
When user requests through Quicklink, you can just add user to the Group using PowerShell scripts. You can run PowerShell scripts using RPC service.
Only problem is you cannot see them in Identity cube.
There might be some challenges in this approach, but in IIQ nothing is impossible with customizations. You may not like how it looks but your requirement can be fulfilled.