Configure Domains for the Cloud Identity Engine
Table of Contents
Expand all | Collapse all
-
- Cloud Identity Engine Attributes
- Collect Custom Attributes with the Cloud Identity Engine
- View Directory Data
- Cloud Identity Engine User Context
- Create a Cloud Dynamic User Group
- Configure Third-Party Device-ID
- Configure an IP Tag Cloud Connection
- Configure Dynamic Privilege Access in the Cloud Identity Engine
- Configure Security Risk for the Cloud Identity Engine
-
-
- Configure Azure as an IdP in the Cloud Identity Engine
- Configure Okta as an IdP in the Cloud Identity Engine
- Configure PingOne as an IdP in the Cloud Identity Engine
- Configure PingFederate as an IdP in the Cloud Identity Engine
- Configure Google as an IdP in the Cloud Identity Engine
- Configure a SAML 2.0-Compliant IdP in the Cloud Identity Engine
- Configure a Client Certificate
- Configure an OIDC Authentication Type
- Set Up an Authentication Profile
- Configure Cloud Identity Engine Authentication on the Firewall or Panorama
- Configure the Cloud Identity Engine as a Mapping Source on the Firewall or Panorama
- Configure Dynamic Privilege Access in the Cloud Identity Engine
-
- Get Help
Configure Domains for the Cloud Identity Engine
Learn about best practices for configuring domains for
the Cloud Identity Engine.
On-Premises Active Directory Domains
A
single Cloud Identity agent can communicate with multiple domains.
The service account you use to query the Active Directory must have
permission to query all domains you configure on the agent. We recommend
configuring multiple domain controllers for each domain so that
if a domain controller is unavailable, the agent can try the next
available domain controller.
To ensure agent redundancy for
a domain, configure multiple agents for that domain. The server
hosting the agent should be physically located near the domain controllers
from which the agent will collect attributes. If the domain controllers
are in different locations, we recommend that you configure multiple agents
and install each agent on a host server that is physically located
near the domain controllers from which the agent will collect attributes.
To
obtain cross-domain memberships for groups with members from other domains
in the forest, configure those domains on the Cloud Identity agent(s).
In this scenario, you must configure the agent to connect to the
domain controllers using the LDAP or LDAPS port (by default, 389
and 636 respectively).
When you configure the Active Directory
in the Cloud Identity agent, do not configure the agent to use the
Global Catalog port (3268 for LDAP or 3269 for LDAPS).
Azure Active Directory Domains
Ensure that your Azure Active Directory (Azure AD) does not contain any circular references,
where a group is a direct or indirect member of itself (for example, Group 2 is a
member of Group 1 and Group 1 is a member of Group 2). If your Azure AD contains circular references, the
Cloud Identity Engine cannot accurately populate the membership of the groups and
you must change the membership of the groups to remove the circular references.
After removing the circular references, sync the attributes to verify
that the Cloud Identity Engine can successfully collect the attributes.
To successfully sync the attributes from
Azure AD, the Cloud Identity Engine automatically removes circular
references. If you do not make any changes, the Cloud Identity Engine
is still operational and other applications, such as Prisma Access,
can successfully retrieve data from the Cloud Identity Engine, but
the membership of the circular groups may not be correctly computed
in Cloud Identity Engine. Therefore, we strongly recommend that
you manually remove any circular references from the Azure AD to
ensure the Cloud Identity Engine operates as expected.