ADSI Connector

[DP]

Hi Everyone -

We have multiple forest / domains that need to be integrated into Saviynt & a one-way trust between them (AD & Cloud AD. Accounts that exists in AD need to be added to the groups that are created in Cloud AD. Based on the above requirements we are thinking about leveraging ADSI connector since it is not supported with AD connector. Below are a few of my questions.

1. Does the ADSI connector require that all Forests / Domains have two way trusts? Based on the document, it says 2-way trust is required. Is there any way we can still work with one-way trust between domains?
2. Service account that is required can work with Least Privileges? Based on the document, it seems that the account must also be a member of the Enterprise Admins group. I would like to know if we just give "Permissions to create, update, move, or delete an object and add or remove access from resources in a cross domain environment"

Thanks

Durga Pasupulati

[rushikeshvartak]

Does the ADSI Connector Require Two-Way Trust Between All Forests/Domains?

• ADSI Connector Trust Requirement: According to the documentation, the ADSI (Active Directory Service Interfaces) connector does indeed require a two-way trust relationship between all forests and domains for full functionality. This requirement ensures that the service account can authenticate and perform actions across all domains.

• Working with One-Way Trust: If you have a one-way trust, it complicates the process since the ADSI connector expects two-way communication. However, you can consider a few workarounds:

  • Service Account Placement: Place the service account in the trusted domain (the domain that trusts the others). This way, the service account has the necessary permissions to access resources in the other domains.
  • Use of Multiple Connectors: Consider using separate ADSI connectors for each domain, if feasible, and manage the trust and access control at the domain level.
  • Custom Scripting: If ADSI limitations are too restrictive, you might explore custom PowerShell scripts or other automation tools that can handle cross-domain operations under a one-way trust. These scripts can be executed within Saviynt to perform required tasks.

2. Can the Service Account Work with Least Privileges?

• Required Privileges: The documentation typically states that the service account should be a member of the Enterprise Admins group, which grants it extensive privileges across all domains. This is because the ADSI connector might need to create, update, move, or delete objects across domains, which usually requires elevated privileges.

• Least Privilege Approach: If you want to operate with least privilege:

  • Granular Permissions: You can delegate specific permissions to the service account in each domain. This involves:
    • Assigning the service account permissions to create, update, move, or delete objects as needed.
    • Ensuring the service account can add or remove access to resources across domains, which may involve adjusting permissions on specific Organizational Units (OUs) or security groups..

[stalluri]

@rushikeshvartak 
It's better to have a two-way trust present so that all the FOREST_DETAILS get populated and will help in the import.

Permission:

Provide the Least Privilege to the Service Account if the domain administrator rights are not granted to it:

• Directory replication permissions across domains in a forest. This is only required for import.

• Permissions to create, update, move, or delete an object and add or remove access from resources in a cross-domain environment. The account must also be a member of the Enterprise Admins group. This is only required for provisioning.

 The following table provides information about the scope of access provisioning in Active Directory groups:

Group Scope Members from the same domain Members from domains within the same forest Members from other domains from a different forest

Domain Local (Security/Distribution)	Users Global Groups Universal Groups Domain Local groups	Users Global Groups Universal Groups	Users Global Groups
Universal (Security/Distribution)	Users Global Groups Universal Groups	Users Global Groups Universal Groups	Not Applicable
Global (Security/Distribution)	Users Global Groups	Not Applicable	Not Applicable