We have a requirement to create a contact object in Active Directory for managers which is from Different Domain via SailPoint ISC
For Example
User from this domain “OU=xyz,DC=lab,DC=ad”
Manager from this domain“OU=abc,DC=cde”
Please let me know, how to implement this
are you creating users and aggregating them from both domains?
will this manager be in domain that user is in?
if you have the manager info already for the user, you can use after/before create op and create AD Contact object with something like this :
New-ADObject -Type 'contact' -Name $contactName -Path $ouPath -OtherAttributes @{
'displayName' = $contactName
'givenName' = $firstName
'sn' = $lastName # Surname
'mail' = $emailAddress
}
but it would be helpful to know more. you may also want to consider other use cases like how to handle if the manager changes and if the new manager contact object already exists etc.
Hi @gbalag I’m going to assume you are aggregating both domains and provisioning into XYZ domain (you could be provisioning into ABC domain as well, but not in scope for this duscussion). Also, you are getting the manager mapping from a separate auth source, HR or some such.
This is untested and provided as-is:
Personally, to keep it clean and purely in ISC UI, I would create a new generic LDAP connector to XYZ purely for contact objects, filtered on object class and OU (eg XYZ Contacts). You could also use an AD connector, if you want (you won’t need any IQService). You could use the same connector and include some logic to create Contact objects rather than User objects, but that feels messy to me and this way, when you look at the Manager Identity you will see 2 accounts, one on the ABC connector and one on the XYZ Contact Connector, rather than one on ABC and one on XYZ.
The Account Create policy on XYZ Contacts would define the LDAP attributes required for a contact object.
You will need a dummy XYZ Security Group Entitlement (such as ABC Contacts).
Create a Role (such as ABC Managers) with this Entitlement (could be in an AP) and assign it dynamically to Identities who have an account in ABC and have Identity attribute ismanager as true. Yes, this will create a contact for all ABC Managers, regardless of whether they manage XYZ Identities or not, but I don’t feel that’s an overhead and makes it cleaner when it comes to manager changes.
Write back the DN of the XYZ contact to a custom Identity Attribute (eg managerXYZContactDN).
On the XYZ AD connector update the manager attribute transform from a simple Get Manager DN generator to a first valid on reference attributes managerXYZContactDN and DN.
Interesting Use Case, by the way.
If your domains are part of the Entra world of things, this might (or might not) be of interest to you:
There are certain use cases that are better suited to be handled at the directory service layer instead of bubbling up / spilling over to the IdM / IGA layer. This might be one of them.
Right now, you’ve mentioned one very specific requirement…but it would help to have full visibility as to whether this is one step of many (to come)…you might want to get a sense of the full scope / direction of this in order to get the right solution in place. For example, what if I now have a set of mailing lists or distribution groups to be made visible to the other side?