Cloud Identity Engine Implementation

CIE performs three core functions that together replace the traditional spiderweb of per-firewall directory connections:

The result is a single pane of glass for identity: add a user in any connected directory and every enforcement point learns about them automatically. Remove a user and access is revoked everywhere within the next sync interval.

These two concepts serve different purposes in the CIE workflow. Understanding the distinction determines which phases of this guide apply to a given deployment.

CIE uses a hub-and-spoke architecture. The CIE cloud service sits at the center. Identity sources connect on one side; enforcement points subscribe on the other. This eliminates direct firewall-to-directory connections and reduces configuration to a single integration point.

Components

Data Flow Summary

1. Ingest — Identity sources push or sync user/group data to the CIE hub (cloud directories via API; on-prem AD via Cloud Identity Agent over mTLS).
2. Normalize — CIE aggregates users from all sources into a unified view, resolving attributes and building Cloud Dynamic User Groups.
3. Distribute — Enforcement points subscribe to CIE and receive user-to-IP mappings, group memberships, and CDUG updates at configurable intervals.
4. Enforce — Firewalls apply user- and group-based security policy using the identity data received from CIE. Unknown users trigger authentication via the Cloud Authentication Service.

The four-step pipeline visualized:

Confirm you have a Palo Alto Networks Customer Support Portal (CSP) account and understand the licensing model. The Cloud Identity Engine service itself is free and does not require a standalone subscription or authorization code.

Core Service Availability (No Additional License Required)

Directory Sync, Cloud Authentication Service, and all standard CIE functionality are included at no cost on the following platforms:

• PA-Series and VM-Series firewalls running PAN-OS 10.1+
• Panorama running PAN-OS 10.1+
• Prisma Access (SCM-managed or Panorama-managed)
• Strata Cloud Manager (availability depends on held licenses such as Prisma Access, AIOps for NGFW Premium, or SCM Essentials/Pro)

Features That Require Additional Licenses

Required Administrative Roles

Assign CIE-specific app roles to administrators in the Palo Alto Networks Hub (Common Services) before activation. Roles control access to tenant management, directory data, and secrets configuration. At minimum, the activating administrator needs the Superuser role on the CSP account.

Verify that all firewalls and management platforms meet the minimum software versions for CIE integration.

Open the required FQDNs and ports so the Cloud Identity Agent can reach the CIE cloud service and validate certificates. All connections use TLS; certificate revocation checks use HTTP on port 80.

GoDaddy Certificate Verification URLs

The Cloud Identity Agent validates its mTLS certificate chain against GoDaddy CRL/OCSP endpoints. These three URLs must be reachable from the agent host:

Region-Specific CIE Endpoints

Allow HTTPS (port 443) from the agent host to the endpoint matching your selected region. Allow traffic only for the region(s) where you have active tenants.

On-Premises Directory Ports

curl -I http://crl.godaddy.com
curl -I http://ocsp.godaddy.com
curl -I https://certs.godaddy.com
curl -I https://agent-directory-sync.us.paloaltonetworks.com

If a Palo Alto Networks firewall sits between the Cloud Identity Agent and the CIE cloud service or Active Directory, configure the following Security policy rules.

Agent → CIE Cloud Service

1. Create a Security policy rule allowing the paloalto-cloud-identity App-ID from the agent host to the CIE regional endpoint.
2. This App-ID requires the ssl and web-browsing application signatures as implicit dependencies.
3. Create a separate rule allowing ssl and web-browsing to the three GoDaddy URLs on ports 80 and 443.

Agent → Active Directory

Use the appropriate App-ID based on the protocol selected during agent configuration:

Proxy Server Considerations

Non-Palo Alto Networks Firewall

If a third-party firewall sits in the path, allow:

• HTTPS (443) from the agent host to the region-specific CIE endpoint
• HTTP (80) from the agent host to crl.godaddy.com and ocsp.godaddy.com
• HTTPS (443) from the agent host to certs.godaddy.com
• LDAP (389) or LDAPS (636) from the agent host to domain controllers

Select the CIE region during activation. This is a permanent decision that cannot be changed after activation. The region determines where your identity data is stored and processed.

Decision Criteria

1. Data residency compliance — Select the region that satisfies your organization's data sovereignty requirements.
2. Prisma Access alignment — If you use Prisma Access, select the same region as your Prisma Access deployment. Mismatched regions cause latency and may prevent CIE from associating with the correct SCM tenant.
3. Latency to agent hosts — For on-premises AD deployments, choose the region closest to your Cloud Identity Agent hosts to minimize sync latency.

Available Regions

Plan agent placement, domain configuration, and directory-specific preparation before activating CIE.

Cloud Identity Agent Placement (On-Premises AD)

• Install the agent on a Windows server physically located near the domain controllers it queries. Network latency between the agent and domain controllers directly affects sync performance.
• If domain controllers are in different geographic locations, install a separate agent at each location, near its respective domain controllers.
• A single agent can communicate with up to 20 domains.
• The service account used by the agent must have LDAP bind permissions across all configured domains.

High Availability

• Configure multiple agents per domain for redundancy. Each agent must have identical configuration.
• CIE communicates with only one agent at a time. If an agent becomes unavailable, CIE automatically connects to the next available agent.
• Agents do not communicate with each other.
• Configure multiple domain controllers per domain so the agent can fail over if a DC is unavailable.

Cross-Domain Group Membership

To resolve group memberships that span multiple domains in an AD forest, configure all relevant domains on the Cloud Identity Agent(s). The agent must connect to each domain's domain controllers using standard LDAP (389) or LDAPS (636) ports.

Azure AD / Entra ID Preparation

Deployment Planning Checklist

After activation, open the Cloud Identity Engine dashboard to confirm the service is running and familiarize yourself with the interface before connecting directories in Phase 3.

1. From the Palo Alto Networks Hub, click the Cloud Identity Engine app tile (or navigate to Strata Cloud Manager > Settings > Products and click Manage next to Cloud Identity Engine).
2. If you created multiple tenants, select the tenant to manage from the tenant switcher in the top-right corner.
3. Review the dashboard landing page. Key sections include:
   • Directories -- lists connected directories (empty after initial activation).
   • Users -- displays synchronized user accounts.
   • Groups -- displays synchronized groups.
   • Authentication -- configure SAML, OIDC, certificate, and password authentication types.
   • Logs -- view sync and authentication event logs for troubleshooting.

Verify that CIE has successfully synced user, group, and computer objects from the connected directory.

1. Log in to the hub and select the Cloud Identity Engine app.
2. Select the tenant, then select Directories.
3. Locate the directory configured in Phase 3. Review the column totals:
   • Users — total user objects synced
   • Groups — total group objects synced
   • Computers — total computer/device objects synced (directory-dependent)
   • Containers — container objects (on-prem AD only)
   • OUs — organizational units (on-prem AD and Google only)
4. Confirm the Sync Status column shows Success.
5. Click the number in the Users column to open the Directory Data page. Search for a known user to validate attribute population (e.g., displayName, mail, memberOf).
6. Click Go Back to Directory in the upper right to return.

CIE uses different synchronization methods depending on directory type. Understanding these intervals is critical before triggering manual syncs or troubleshooting stale data.

Triggering a Manual Sync

1. Navigate to Directories and select the target directory.
2. Click Actions and choose either:
   • Full Sync — resynchronizes the entire directory (recommended after connectivity issues)
   • Sync Changes — syncs only changes since last successful sync (not available for Google)
3. A confirmation message (Sync started) appears. Click the sync button only once.
4. Wait for Sync Status to show Success.

Cloud Dynamic User Groups provide adaptable, attribute-driven group membership that updates automatically. Use CDUGs for security policy that adapts to changes in user context such as department, location, title, or risk level.

CDUGs fall into two categories:

To delete a CDUG, select the ellipses button next to the group and select Remove.

If the directory uses non-default attribute names, override the attribute mapping so CIE collects the correct fields. This is only necessary when directory attributes differ from the default formats listed in the CIE Attributes reference.

1. Log in to the hub and select the Cloud Identity Engine tenant.
2. Select Attributes, then select the directory type (e.g., Active Directory, Azure, Okta, Google, SCIM, OpenLDAP).
3. Click on the attribute value to make the field editable.
4. Enter the custom attribute name used in the directory and click the checkmark to confirm.
5. A green triangle appears in the upper-left corner of the modified row to indicate the change.

Inspect the data CIE has synced from connected directories to validate attribute accuracy and troubleshoot missing or incorrect values.

1. In the Cloud Identity Engine app, select Directories.
2. Click the count in any column (Users, Groups, Computers, Containers, or OUs) to open the Directory Data page for that object type.
3. By default, 25 results display per page. Use the pagination controls or the rows-per-page dropdown to adjust.
4. Search for specific objects:
   • Enter a partial or complete keyword in the search bar and press Enter or click Search.
   • Select Text Search for exact matches or Substring Search for partial matches.
   • Search terms are not case-sensitive.
5. Click the Details icon in the first column of any row to expand that object's attributes:
   • For a group — displays up to 2,000 flattened users in the Member attribute.
   • For a user — displays up to 2,000 groups in the Groups attribute.
6. Click View Raw Data (upper right of the details pane) to see the complete attribute payload.
7. Toggle between Direct and Direct and Nested views to inspect nested group membership. Nested group data is not available for attribute-based CDUGs.
8. Click Go Back to Directory to return to the Directories page.

The Authentication Profile defines which authentication type(s) apply to which users. CIE offers two modes: Single (one auth type for everyone) and Multiple (map different auth types to different directory groups with priority ordering).

Choose your authentication mode:

Create a firewall-side authentication profile that references the CIE Authentication Profile. This profile acts as the local pointer to the Cloud Authentication Service.

The Authentication Portal (captive portal) captures user identity by redirecting unauthenticated users to CIE for login. This creates the IP-to-username mapping required for identity-based security policy.

1. Navigate to Device > User Identification > Authentication Portal Settings.
2. Click Edit (gear icon).
3. Select the Authentication Profile created in Step 7.2 from the dropdown.
4. Set Mode to Redirect.
5. Configure the redirect host:
   • Enter the Redirect Host IP address or FQDN. This is the IP/hostname that users are redirected to for the authentication page.
6. Enable Response Pages on the interface management profile for the trust zone interface to allow the firewall to serve the redirect.
7. Click OK.

The Authentication Enforcement object binds an authentication method and profile together. Authentication Policy rules reference this object to trigger user authentication.

1. Navigate to Objects > Authentication.
2. Click Add.
3. Enter a Name for the enforcement object (e.g., CIE-Web-Form-Enforce).
4. Set Authentication Method to web-form.
5. Select the Authentication Profile created in Step 7.2.
6. (Optional) Enter a Message to display to users on the authentication page (e.g., Please log in to access this resource.).
7. Click OK.

Create a custom URL category containing the CIE authentication service URLs. Security and authentication policy rules use this category to match and allow CIE-related traffic.

1. Navigate to Objects > Custom Objects > URL Category.
2. Click Add.
3. Enter a Name (e.g., CIE-Auth-URLs).
4. Add the CIE region-specific URLs. Use the table below or add the wildcard *.apps.paloaltonetworks.com if strict regional filtering is not required.
5. Add the IdP-specific URLs required by the authentication type (e.g., *.okta.com, login.microsoftonline.com, accounts.google.com).
6. Click OK.

show cloud-auth-service-regions

CIE Region-Based URLs

Create a security policy rule that allows traffic to CIE authentication URLs and IdP endpoints. Without this rule, the firewall blocks the redirect traffic and authentication fails.

1. Navigate to Policies > Security.
2. Click Add.
3. On the General tab:
   • Enter a Name (e.g., Allow-CIE-Auth-Traffic).
   • Set Rule Type to universal.
4. On the Source tab:
   • Set Source Zone to the trust zone(s) where users reside.
5. On the Destination tab:
   • Set Destination Zone to the untrust zone (internet-facing).
6. On the Service/URL Category tab:
   • Set Service to application-default.
   • Add the custom URL category created in Step 7.5 (e.g., CIE-Auth-URLs).
7. On the Actions tab:
   • Set Action to Allow.
   • Enable Log at Session End.
8. Click OK.
9. Position this rule above any deny-all or restrictive rules that would otherwise block the authentication traffic.

The Authentication Policy rule triggers user authentication for matching traffic. It references the Authentication Enforcement object from Step 7.4 and can target specific source zones, addresses, or user groups.

1. Navigate to Policies > Authentication.
2. Click Add.
3. On the General tab:
   • Enter a Name (e.g., CIE-Auth-Rule).
4. On the Source tab:
   • Set Source Zone to the trust zone(s).
   • (Optional) Set Source User to unknown to target only unauthenticated users, or select specific user groups to require re-authentication.
5. On the Destination tab:
   • Set Destination Zone to the untrust zone.
6. On the Service/URL Category tab:
   • Set Service to service-http and service-https.
   • (Optional) Exclude the CIE custom URL category to avoid authentication loops — CIE auth URLs must pass through without triggering a second authentication challenge.
7. On the Actions tab:
   • Set Authentication Enforcement to the object created in Step 7.4 (e.g., CIE-Web-Form-Enforce).
8. Click OK.

With CIE connected (Phase 5) and authentication configured (Steps 7.1–7.7), security policy rules can use CIE-sourced usernames and groups as match criteria in the Source User field. This is the end goal of the CIE deployment: identity-based policy enforcement.

1. Navigate to Policies > Security.
2. Click Add to create a new rule, or edit an existing rule.
3. On the Source tab, click Add under Source User.
4. The user/group picker displays CIE-sourced users and groups. Select the appropriate entries:
   • Directory groups — groups synced from Active Directory, Entra ID, Okta, Google, or SCIM (configured in Phase 3).
   • Cloud Dynamic User Groups (CDUGs) — attribute-based groups created in Phase 4. These appear with the format CDUG-name.
   • Individual users — specific user identities from the synced directory.
5. Configure the remaining rule fields (destination zone, application, service, action) per your security requirements.
6. Click OK.
7. Position the rule appropriately in the rulebase (more specific rules above more general rules).
8. Click Commit.

Example: Role-Based Access Rules

show user ip-user-mapping all

Confirm the firewall has received IP-to-username mappings from CIE. Without valid mappings, user-based policy cannot match traffic.

View All CIE Mappings

1. SSH into the firewall CLI.
2. Run the following command to display all active User-ID mappings:

show user ip-user-mapping all

Review the output table. Each row contains an IP address, username, mapping type, and source.

Filter by Specific IP

To check the mapping for a known test client IP address:

show user ip-user-mapping ip 10.0.1.50

Filter by Mapping Type

To show only CIE-sourced mappings:

show user ip-user-mapping all type CIE

What to Look For

Validate the full authentication round-trip: client request, redirect to IdP, credential entry, return to resource, and mapping creation.

Trigger Authentication

1. From a test client behind the firewall, open a browser and navigate to a URL that matches your authentication policy rule (a site that requires CIE authentication).
2. The firewall should redirect the browser to the CIE authentication portal, which then redirects to the configured IdP (Entra ID, Okta, Google, or other).
3. Verify the IdP login page loads correctly. Confirm the correct tenant/application name appears on the IdP login screen.
4. Enter valid credentials and complete any MFA challenge if configured.
5. After successful authentication, the browser should redirect back to the originally requested resource.

Check Authentication Logs

1. On the firewall, navigate to Monitor → Logs → Authentication.
2. Filter for the test user:

   (user.src eq 'domain\testuser')

   Copy
3. Verify the log entry shows:
   • Result = Successful
   • Auth Policy = the name of your authentication policy rule
   • Server Profile = the CIE authentication profile name
   • Type = cloud-auth-service

Check CIE Authentication Logs

1. In Strata Cloud Manager, open the Cloud Identity Engine app.
2. Navigate to Logs → Authentication Logs.
3. Search for the test user. Verify the log shows the authentication timestamp, IdP name, and result status.

CLI Verification

After the test user authenticates, verify the mapping appeared on the firewall:

show user ip-user-mapping ip <test-client-IP>

Confirm the firewall enforces security policy based on CIE user and group identity. This step creates a test rule and validates that user-specific policy matches traffic.

Create a Test Security Rule

1. Navigate to Policies → Security (on the firewall or Panorama).
2. Add a new security policy rule with these settings:

   Field	Value
   Name	CIE-Test-UserPolicy
   Source Zone	The zone where the test client resides
   Source User	A specific CIE user (e.g., domain\testuser) or CIE group
   Destination Zone	The zone for the target resource
   Application	web-browsing and ssl
   Action	Allow
   Log at Session End	Enabled

3. Position this rule above any broader rules that would match the same traffic.
4. Commit the configuration.

Generate Test Traffic

1. From the authenticated test client, browse to an external website (e.g., https://example.com).
2. Wait 10–15 seconds for the session log to appear.

Verify the Rule Matched

1. Navigate to Monitor → Logs → Traffic.
2. Filter for the test rule:

   (rule eq 'CIE-Test-UserPolicy')

   Copy
3. Confirm the log entry shows:
   • Rule = CIE-Test-UserPolicy
   • Source User = domain\testuser
   • Action = allow

Negative Test (Optional)

To confirm the rule is user-specific and not matching all traffic:

1. From a different client that has not authenticated (or has a different user mapping), generate traffic to the same destination.
2. Verify the traffic log shows a different rule name (not CIE-Test-UserPolicy).

Confirm the firewall populates the user field in traffic logs for all sessions traversing User-ID-enabled zones. A blank user field indicates that User-ID mapping is not functioning.

GUI Method

1. Navigate to Monitor → Logs → Traffic.
2. Add a filter to show only sessions with a populated user field:

   (user.src neq '')

   Copy
3. Alternatively, filter for a specific user:

   (user.src eq 'domain\testuser')

   Copy
4. Review the Source User column. Every row should show a domain\username value.

CLI Method

show log traffic direction equal backward user.src equal domain\testuser

Common Issues

If you created Cloud Dynamic User Groups (CDUGs) in Phase 4, verify that members are populated correctly and the firewall can resolve the group for policy evaluation.

Check CDUG in CIE Dashboard

1. In Strata Cloud Manager, open the Cloud Identity Engine app.
2. Navigate to User Groups → Cloud Dynamic User Groups.
3. Locate the CDUG and verify:
   • Member count is greater than zero and matches the expected number of users
   • Last evaluated timestamp is recent
   • Click the CDUG name to expand the member list and confirm the expected users appear

Check CDUG on Firewall

Run the following CLI command to verify the firewall has received the CDUG membership from CIE:

show user group name "cdug-group-name"

Replace cdug-group-name with the exact name of your Cloud Dynamic User Group. The output lists the group members known to the firewall.

Verify Attribute-Based Criteria

If the CDUG uses attribute-based membership (e.g., department = Engineering):

1. In the CIE dashboard, navigate to Explore → Users.
2. Search for a user who should be in the CDUG.
3. Click the user and review their attribute values. Confirm the attribute used in the CDUG filter (e.g., department) has the expected value.
4. If the attribute is missing or incorrect, check the directory sync configuration and attribute mapping.

Common Issues

If you configured User Context segments in CIE to redistribute User-ID mappings across multiple firewalls, verify that subscribing firewalls receive the published mappings.

Verify Publishing Firewall

1. SSH into the firewall configured as the publishing segment member.
2. Confirm it has active CIE mappings:

   show user ip-user-mapping all type CIE

   Copy
3. Verify the User Context Cloud Service connection is active:

   show user cloud-identity-engine status

   Copy

Verify Subscribing Firewall

1. SSH into a firewall in the subscribing segment.
2. Run the mapping command and filter for CIE-sourced entries:

   show user ip-user-mapping all type CIE

   Copy
3. Compare the output to the publishing firewall's mappings. The subscribing firewall should display the same CIE mappings that the publishing firewall advertised to the segment.

Verify in CIE Dashboard

1. In Strata Cloud Manager, open the Cloud Identity Engine app.
2. Navigate to User Context → Mappings & Tags.
3. Select the User-ID tab and search by username or IP address.
4. Confirm the mapping appears with the correct source firewall.

Verify Segment Configuration

1. Navigate to User Context → Segments.
2. Select each segment and verify:
   • The publishing segment contains the expected firewalls and data types (IP User Mappings, IP Tag Mappings, User Tag Mappings, etc.)
   • The subscribing segment is subscribed to the correct publishing segment(s)
   • Each firewall shows a Connected status

Common Issues

Confirm every item below before considering the CIE deployment production-ready. Each item corresponds to a verification step above.

Connect risk assessment sources so CIE can automatically assign users and devices to Cloud Dynamic User Groups based on risk signals. When the risk condition is remediated, CIE removes the user or device from the group automatically.

Add a Risk Source

1. In CIE, navigate to Security Risk > Risk Sources.
2. Click Add Risk Source.
3. Select the risk source type and click Connect.

Configure CIE as a Shared Signals Framework (SSF) transmitter to send Cortex XDR user risk signals to Okta. Okta receives these signals and enforces risk entity policy rules (session logout, MFA challenges) for coordinated threat response.

How SSF Transmitter Works

1. Cortex XDR detects high-risk user activity during an active Okta session.
2. Cortex XDR syncs user risk and device risk data with CIE.
3. CIE sends the data to Okta as security events through the SSF Transmitter.
4. Okta processes signals as risk detection events and enforces risk-based policy rules.

Configure Cortex XDR as a Risk Source

1. In CIE, navigate to Security Risk > Risk Connections.
2. Click Add a risk source.
3. Click Connect on the Cortex tile and select an existing Cortex Directory.
4. Click Continue. The directory is added to the Risk Collection for Cortex.

Configure the SSF Transmitter

1. Navigate to Security Risk > Risk Connections.
2. Under Risk Sharing, click Add on the Shared Signals Framework Okta tile. The SSF Transmitter configuration window opens.
3. Set Risk Source to XDR.
4. Select the target Okta directory for Cortex XDR risk signals.
5. Verify SSF stream details:
   • Leave the Audience field as-is.
   • Copy the Well Known Configuration Endpoint value. This URL is required for the Okta receiver setup.
   • Verify the Transmitter Endpoint is your Okta tenant address appended with /security/api/v1/security-events.
6. Click Submit.

Configure Okta as the Receiver

1. Log in to your Okta admin console.
2. Navigate to the shared signal provider configuration.
3. Paste the Well Known Configuration Endpoint value from the SSF Transmitter configuration into the Well-known URL field.
4. Save the configuration.

Configure CIE as a Shared Signals Framework (SSF) receiver to ingest risk signals from Okta. CIE uses these signals (session revocation, credential changes) in Cloud Dynamic User Groups for adaptive firewall policy enforcement.

Create the Okta App Configuration

1. Copy the CIE tenant URL and replace everything after the domain with /authorize to construct the Sign-in redirect URI.

   # Example:
   # CIE tenant URL:  https://directory-sync.us.paloaltonetworks.com/directory?instance=<InstanceId>
   # Redirect URI:    https://directory-sync.us.paloaltonetworks.com/authorize

   Copy
2. In Okta, create a new app integration.
3. Set Sign-in method to OIDC - OpenID Connect.
4. Set Application type to Web Application. Click Next.
5. Click the X next to the existing default Sign-in redirect URI to remove it, then paste the URI constructed in step 1.
6. Edit the app's General Settings.
7. Under Grant type, enable Refresh token.

8. Navigate to Okta API Scopes and grant consent to:
   • ssf.manage
   • ssf.read
9. Return to General and copy the Client ID and Client Secret.

Add SSF Okta Receiver in CIE

1. In CIE, navigate to Security Risk > Risk Connections > Add.
2. Click Add on the SSF Okta Receiver tile.
3. Enter a Receiver Name.
4. Select the Associated Directory (the Okta directory connected in Phase 3).
5. Enter the Client ID and Client Secret from the Okta app.
6. Click Create Stream.
7. Log in to Okta with admin credentials when prompted. CIE displays Stream created successfully.
8. Click Submit.

Create a Cloud Dynamic User Group

1. Navigate to Security Risk > Cloud Dynamic Groups > Risky User Group.
2. Select the SSF Okta Receiver directory from the dropdown.
3. Click Create New Risky User Group.
4. Set Category to Risky User.
5. Configure Context and Attributes for the group.
6. Click Submit.

Enable third-party IoT solutions to provide Device-ID verdicts to Prisma Access through CIE. IoT vendors submit IP-address-to-device mappings via API, and Prisma Access Security Processing Nodes enforce matching device-based policy rules.

Activate Third-Party Device-ID

1. In CIE, navigate to User Context > Third-Party Device-ID.
2. Select the Location (region) for the tenant. Verify the region is correct before confirming.
3. Click Add New Management System.

Upload the CSR and Generate Credentials

1. Enter a unique Configuration Name (use the vendor name for clarity).
2. Click Browse Files or drag and drop the CSR file from the third-party IoT vendor.
3. Click Sign CSR and Export to download the signed certificate. Save it securely.
4. Click Generate New API Key to create an authentication token. Copy the API key and save it securely.
5. Import both the signed certificate and the API key into the third-party IoT solution's management system.

Verify and Manage Mappings

1. Select Mappings to view detected devices and their IP-address-to-device mappings.
2. Use Apply Search to filter by IP address.
3. Select Management Systems to review certificate expiration dates and API key status.

Configure CIE to collect IP-address-to-tag mappings from AWS, Azure, or GCP. Use these mappings in Dynamic Address Groups for tag-based security policy that adapts automatically to IP address changes in cloud environments.

Configure Cloud Provider IAM Permissions

Before adding the connection, grant the CIE service account the required permissions in the cloud provider:

Create the Credential Configuration

1. In CIE, activate User Context if not already active. Use the default segment or configure a new one.
2. Navigate to User Context > IP-Tag Collection > Credential Configuration tab.
3. Under Set Up a New Credential Configuration, select the cloud provider (AWS, Azure, or Google Cloud Platform).
4. Enter a unique, descriptive Name.

5. Click Test Connection to verify connectivity.
6. Click Submit.

Create a Monitor Configuration

1. Select the Monitor & Status tab.
2. Click Set Up a New Monitor Configuration and select the credential configuration created above.
3. Enter a unique Name.
4. Select the Credential Configuration.
5. (AWS only) Optionally select a Role ARN.
6. Select regions, VPCs (AWS), or Project IDs (GCP) -- or leave All selected.
7. (Azure only) Select whether to Fetch Service Tags.
8. Set the Polling Interval (60--1800 seconds).
9. Select a segment to share mappings with firewalls, or None for monitoring only.
10. Click Submit.

Enable Dynamic Privilege Access to isolate network resources on a per-project basis for Prisma Access users. DPA uses Azure AD SAML with Dynamic SP metadata to control project-level access.

Configure SAML Authentication Type for DPA

1. In CIE, navigate to Authentication Types > Add New Authentication Type.
2. Select SAML 2.0 and configure Azure as the identity provider (or edit an existing Azure IdP configuration).
3. Set Metadata Type to Dynamic service provider metadata.

Export SP Metadata

1. Copy the Entity ID and Assertion Consumer Service URL, or click Download SP Metadata.

Configure Azure Enterprise Application

1. Log in to the Azure Portal. Navigate to Enterprise Applications.
2. Search for and select Palo Alto Networks Cloud Identity Engine - Cloud Authentication Service from the gallery.
3. (Optional) Edit the application Name.
4. Click Create.
5. Under Set up single sign-on, click Get started.
6. If using Entity ID / ACS URL:
   1. Edit the Basic SAML Configuration.
   2. Click Add identifier and paste the Entity ID.
   3. Click Add reply URL and paste the Assertion Consumer Service URL.
   4. Enter the regional Sign on URL: https://<RegionUrl>.paloaltonetworks.com/sp/acs
   5. Click Save.
   6. Copy the App Federation Metadata URL.
7. Assign users and groups to the application.
8. Save the configuration.

Complete CIE Configuration

1. In CIE, paste the App Federation Metadata URL into the Identity Provider Metadata URL field.
2. Click Get URL to confirm CIE can connect.
3. Configure Multi-factor Authentication and Force Authentication as needed.
4. Click Test SAML Setup to verify.
5. Select the Username Attribute using the /identity/claims/name: format.
6. (Optional) Configure Usergroup Attribute, Access Domain, User Domain, and Admin Role.

Enable DPA

1. If not already done, enable Collect enterprise applications data in the Azure directory configuration. Sign in to confirm and Submit. Wait for the full sync to complete.
2. Select Enable Dynamic Privilege Access.
3. Click Detect Directory and SAML to allow CIE to detect available directories and SAML attributes.
4. Confirm the displayed Directory and SAML 2.0 Application information is correct.
5. Click Submit.
6. Configure an Authentication Profile in CIE to use the DPA authentication type.

Configure a centralized, encrypted vault for storing and managing sensitive credentials (passwords, API keys) with granular access controls, auditing, and collection-based sharing.

Configure Vault Roles

Assign vault roles to users. Vault roles are add-on roles that must be combined with existing Common Services roles -- a standalone vault role cannot log in to CIE.

Activate and Create Secrets

1. In CIE, select Secrets Vault.
2. Click Activate the Secrets Vault (first-time only).
3. Click Create Secret.
4. Enter the Secret Name.
5. Enter URLs that require this secret (up to 100 URLs per secret, in RFC 3986 URI format).
6. Enter the Username and Password.
7. (Optional) Select Collections to associate with this secret.
8. (Optional) Enter a Note (up to 1,000 characters).
9. Grant Access to specific users or groups with the appropriate level:

   Access Level	Description
   View and Use	User can view and use the secret
   Full Access	User can add, edit, or delete the secret
   Use Only	User can use the secret but not view the password

10. Click Save.

Configure Collections (Optional)

Collections group secrets for sharing with specific users and groups.

1. Select the Collections tab.
2. Click Create Collection (or Add Collection if collections exist).
3. Enter the Collection Name.
4. Select Secrets to include (up to 500 secrets per collection).
5. (Optional) Enter a Note.
6. Grant Access to users or groups.
7. Click Save.

Manage Secrets and Collections

• Search: Filter by secret name, URL, username, collection, or creator.
• Edit: Click the Edit button on any secret or collection.
• Change password: Select the secret, click Edit, then Change Password.
• Delete a secret: Click the Delete button and confirm.
• Delete the vault: Click Options > Delete Vault and confirm.

All ports required for Cloud Identity Engine communication between the agent, directory, firewall, and CIE cloud service.

Allow outbound HTTPS (443) from the Cloud Identity Agent to the regional endpoint matching the CIE tenant region. Allow HTTP (80) and HTTPS (443) to the GoDaddy CRL/OCSP endpoints from every agent host.

CIE Regional Agent Endpoints (port 443)

GoDaddy CRL & OCSP Endpoints (all regions)