Authenticate users in multiple domains

You install the connector on a host Windows server that is joined to a domain controller to authenticate CyberArk Identity users who have an account in that domain. If you want CyberArk Identity to authenticate users in other domains, there are two connector installation models—which one you use depends upon whether the accounts are in trusted domains in a single forest or in multiple, independent domain trees or forests.

If all of your CyberArk Identity users have their accounts in a single domain, you can skip this topic.

Configure authentication for trusted domains

You use this model when the users’ Active Directory accounts are in domains with domain controllers that have a two-way, transitive trust relationship with the domain controller to which the connector is joined.

In this model, you have a single connector for the entire domain tree or forest. CyberArk Identity communicates through this connector for all authentication requests. When the user account is in another domain, the authentication requests are handled according to the tree-root, parent-child, forest, and shortcut trust relationship settings between the domain controllers.

If you are using Active Directory for device and policy management, all object management communications are done through the same connector as well.

By default, two-way transitive trusts are automatically created when a new domain is added to a domain tree or forest root domain by using the Active Directory Installation Wizard. The two default trust types are parent-child trusts and tree-root trusts. When you configure the trust relationship, be sure to select Forest trust. This establishes a transitive trust between one forest root domain and another forest root domain. See How Domain and Forest Trusts Work in Microsoft TechNet for more about trust relationships.

Important: For tenants created after CyberArk Identity 17.1 release, the connector by default does not perform cross forest user lookup from a local forest. To enable this functionality, contact CyberArk Support.

After you install the first connector, you should install one or more on separate host computers. The host computer for each connector must be joined to the same Active Directory domain controller. See Install the CyberArk Identity Connector for the details.

CyberArk Identity automatically creates a login suffix for the domain to which the host computer is joined plus all of the domains that the connector can see. Which domains can be seen depends upon two criteria:

  • The trust relationship between the domain controllers.
  • Only domain controllers with a two-way transitive trust meet this criteria

  • The connector’s user account permissions.
  • By default the connector is installed as a Local System user account on the Windows host. (See Permissions required for alternate accounts and organizational units for more information.) The permissions you grant to this account can affect its ability to see other domains.

When the Identity Administration portal searches Active Directory domains for users and groups (for example, when you are adding a user or group to a role), it only searches the Active Directory Users container in the domain controllers that can be seen by the connector.

Configure authentication for Independent domains in multiple forests

You use this model when the users’ Active Directory accounts are in independent domain trees or forests; that is, there are domain controllers that do not have a two-way, transitive trust relationships with each other.

In this model, you have a separate connector for each independent domain tree or forest. CyberArk Identity picks which connector to use for the authentication request based on the login-suffix-to-domain mapping it creates and maintains. When the user account is in the connector’s domain controller, the authentication requests are handled according to the tree-root, parent-child, forest, and shortcut trust relationship settings between the domain controllers in that forest or domain tree.

After you install the first connector for each independent domain tree or forest, you should install one or more on separate host computers for each one. The host computer for each connector must be joined to the same Active Directory domain controller as the initial connector for this tree or forest. See Install the CyberArk Identity Connector for the details.

CyberArk Identity automatically creates a login suffix for the domain to which the host computer is joined plus all of the domains that the connectors for each independent domain can see.

When the Identity Administration portal searches Active Directory domains for users and groups (for example, when you are adding a user or group to a role), it only searches the Active Directory Users container in the domain controllers that can be seen by the connectors. Which domains can be seen depends upon two criteria:

The trust relationship between the domain controllers.

Only domain controllers with a two-way transitive trust meet this criteria. When you configure the trust relationship, be sure to select Forest trust. This establishes a transitive trust between one forest root domain and another forest root domain. See How Domain and Forest Trusts Work in Microsoft TechNet for more about trust relationships. The connector’s user account permissions.

By default the connector is installed as a Local System user account on the Windows host. The permissions you grant to this account can affect its ability to see other domains. See Permissions required for alternate accounts and organizational units for more information.

If you are using this model, use the CyberArk Cloud Directory policy service to set mobile device policies (see Select the policy service for device management) and CyberArk Identity roles to enable users to enroll devices.

Permissions required for alternate accounts and organizational units

You can run the connector service as an Active Directory service account instead of as a Local System account. The account you select must have all of the required permissions. For example, if you run as a specific Active Directory service account, the account must be a member of the local administrators group, and you must confirm that it has at least read permission to the container that has CyberArk Identity user accounts and Active Directory Groups used as members of Roles.

You should not run a Windows service with an Active Directory built-in account or an Active Directory user account.

You must verify that the relevant accounts have permission to read Active Directory users and groups as if authentication would work. Each time role permissions are reassessed, the connector tries to resolve the Active Directory groups mapped to any role in which the Active Directory user is potentially a member.

The host computer must also have read access to the container or organizational unit (OU) that stores the user accounts. Without read access, the connector cannot authenticate the user. Domain computers have this permission by default; however, the connector host may not. This most often occurs in multi-forest or multi-domain setups and can occur even when two-way trust is already defined. You can tell when this occurs—the connector log would show the error message, "unable to locate forest or user object."

In this case, you need to give the Local System account read access permission to the containers or organizational units.

Set the Read access permission to the user account container or organizational unit

  1. Open Active Directory Users and Computers, select the user account container, and open the Properties.
  2. Select the Security tab and then click Add to add the user account you are using to run the connector service. Click OK after you add the user account.
  3. Click the user account in Group or User Names and click the Allow box for the Read permission.
  4. Click OK.

Any user or group that has been given permission to read and write the LockoutTime attribute for an OU or other container can unlock user accounts that reside in that container.

Password reset requires you to delegate a group of users to have the ability to reset passwords for another subset of users in a particular OU. See Delegate permissions to reset passwords and unlock accounts for more information.