System

System data objects

With respect to your master data in the ES, ensure that all System data objects have at least one account resource.

System trust

You can specify that a system object trusts another system. You can use this setting to handle multiple Active Directory domains, or systems that reference accounts in another system, for example Microsoft Exchange, which relies on Active Directory accounts.

When a system trusts another system, it allows accounts from the trusted system to be assigned to resources in the trustee system.

Trust between two systems has a direction. For it to be in both directions, both systems must specify the other system as trusted.

You can nest trust. This means that if system1 trusts system2 that trusts system3, then system1 effectively trusts system2 and system3.

An identity can have accounts, even with the same account names, in some or all of the systems that a system trusts.

Multiple domains

In organizations with multiple domains, some of the domains typically trust some of the other domains. When a domain trusts another domain, it allows accounts from the trusted domain to be members of the trustee domain's security groups and distribution lists.

In Omada Identity, a System data object should represent each domain. A domain that trusts another domain must specify the trusted domain in the Trusts property on the System data object type.

Desired state assignments

When RoPE creates a desired state permission assignment, it assigns the permission resource to the account that the identity has in the system, plus to the accounts in the trusted systems. The account types must match for an account to be suitable.

For example, John has an account John1 in Domain1 and another account John2 in Domain2. Domain1 trusts Domain2. The organization has configured an assignment policy that assigns John to the group Group1 which is in Domain1.

The result of this is that John gets two CRAs for Group1: one for his account in Domain1 and one for his account in Domain2.