> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/data-security-documentation/onboard-and-configure/csp-onboarding/outpost-onboarding/outpost-troubleshooting.md).
# Outpost troubleshooting
This document provides solutions for issues that might occur while deploying, configuring, and operating Cortex Cloud outposts. These troubleshooters can help identify symptoms, locate errors, and suggest how you can remediate.
## General troubleshooting
These general troubleshooters apply to all cloud service providers and outpost deployment modes.
**Terraform executes successfully but no outpost appears in Cortex**
After a successful Terraform run, your cloud environment sends a notification to Cortex to register the new outpost. If the outpost doesn't appear in the Cortex console, verify that outbound internet connectivity is available from the environment where Terraform was executed. The notification requires an active connection to reach Cortex. If connectivity is confirmed and the outpost still doesn't appear, contact customer support for a manual workaround.
**Terraform template execution fails on a non-approved tenant, such as after changing the target tenant mid-deployment**
If Terraform execution fails on a non-approved tenant, such as if you change an Azure target tenant after starting outpost creation. Terraform execution fails because the outpost is bound to the originally-approved tenant. Delete the partially-created outpost from the Cortex console, revert to the approved tenant, and re-run the Terraform template.
## Standard outpost troubleshooting
Standard outposts handle most of the infrastructure and identity provisioning automatically. Issues in this deployment mode might stem, for example, from broad permission gaps, restrictive policy definitions, or quota limits that prevent Cortex from deploying necessary resources.
## Custom outpost troubleshooting
Custom outposts require specific infrastructure configurations tailored to your environment. Troubleshooting these deployments might involve, for example, validating custom network routing, verifying the availability of specific scanner images, and ensuring modified Terraform variables align with your cloud provider's network topology.
### Setup fails silently: Tenant has disabled user registration
The setup fails silently if `Users can register applications = No` is set at the tenant level. See the `README.md` for this common failure mode.
## Bring your own app (BYOA) troubleshooting - Azure
This section details common deployment and runtime errors that occur when a Bring Your Own App (BYOA) Azure outpost is configured. These errors might appear, for example, if the app registration, service principal, and user-assigned managed identities (UAMIs) were created manually via the Azure portal instead of using the provided helper script.
Use the following table to identify symptoms and apply the appropriate resolutions.
| Symptom / error message | Terraform deployment phase | Detection method | Resolution |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Single-tenant app registration
Error: ... sign\_in\_audience must be 'AzureADMultipleOrgs' ...
| Plan | Terraform console output | Recreate the app registration as a multi-tenant application.
The Azure portal defaults to single-tenant ("this org only").
Run this command:
az ad app create --display-name \ --sign-in-audience AzureADMultipleOrgs
|
| Incorrect service principal ID
Error: ... customer\_sp\_object\_id ... is the SP of a different AppReg ...
| Plan | Terraform console output | An incorrect service principal object ID was provided.
Retrieve the correct ID by running:
az ad sp show --id \ --query id -o tsv
Update the customer\_sp\_object\_id variable in your tfvars file.
|
| Missing Terraform runner ownership
Error: Warning: The Terraform runner ... is NOT listed as an owner of the BYO App Registration ...
| Plan | Terraform console output | The Terraform runner must be added as an owner of the app registration.
Without this, the deployment fails with an "Insufficient privileges" error when attempting to create the first federated identity credential (FIC).
Run:
az ad app owner add --id \ --owner-object-id \
|
| Disabled service principal
Error: ... Customer SP ... is disabled in Entra ...
| Plan | Terraform console output | The service principal is disabled.
Re-enable it by running:
az ad sp update --id \ --set accountEnabled=true
Alternatively, toggle it in the Azure portal under Enterprise applications > \[Your SP] > Properties.
|
| Cross-subscription UAMI
Error: ... Customer UAMI ... lives in subscription \ but the outpost is being deployed to \ ...
| Plan | Terraform console output | Cross-subscription UAMIs are not supported because the Azure Instance Metadata Service (IMDS) only returns tokens for local identities.
Recreate the UAMI in the outpost's subscription and update customer\_uami\_\*\_id in your tfvars file.
|
| Cross-tenant UAMI
Error: ... Customer UAMI ... lives in tenant \ but the outpost subscription is in tenant \ ...
| Plan | Terraform console output | Cross-tenant UAMIs are not supported.
Recreate the UAMI in the correct Entra ID tenant to match the outpost subscription.
|
| Duplicate UAMI IDs
Error: ... All 5 customer UAMI IDs must be distinct ...
| Plan | Terraform console output | Duplicate UAMI IDs were provided.
The error message lists all 5 IDs.
Replace the duplicates with the correct, distinct UAMI IDs and rerun Terraform.
|
| Insufficient privileges for FIC
Error: Error: creating Federated Identity Credential ... Insufficient privileges to complete the operation
| Apply | Terraform console output | App registration owner permissions are missing for the Terraform runner.
Verify ownership by running az ad app owner list --id \.
Add the owner by running:
az ad app owner add --id \ --owner-object-id \
|
| Stale federated credential
Error: Another object with the same value for property federatedIdentityCredentials/\ already exists
| Apply | Terraform console output | A stale FIC exists from a previous deployment attempt or manual portal entry.
List existing credentials using az ad app federated-credential list --id \ -o table.
Delete the conflicting one with az ad app federated-credential delete --id \ --federated-credential-id \.
Rerun the deployment.
|
| Subject does not exist (replication lag)
Error: 400 BadRequest: Subject does not exist in directory.
| Apply | Terraform console output | The UAMI was created very recently, and it has not yet replicated across Entra ID.
Wait 30 to 60 seconds and rerun terraform apply.
Verify the subject exists with az ad sp show --id \.
|
| Account disabled at runtime
Error: AADSTS50057: The user account is disabled.
| Runtime | Scanner pod logs | The service principal was disabled after onboarding.
Re-enable it by running:
az ad sp update --id \ --set accountEnabled=true
|
| Missing federated identity record
Error: AADSTS70021: No matching federated identity record found
| Runtime | Scanner pod logs | A FIC is missing or has the wrong subject.
List the FICs on the app registration (az ad app federated-credential list --id \) and on the UAMI (az identity federated-credential list --name \ -g \).
Rerun terraform apply to allow Terraform to automatically reconcile and recreate the missing FICs.
|
| Missing admin consent
Error: AADSTS650056 or AADSTS50020
| Runtime | Cortex consent URL | The app registration is configured as single-tenant, or admin consent is missing on the monitored tenant.
Verify sign\_in\_audience is set correctly and retry the admin consent flow.
|
| Accidental UAMI deletion
Error: terraform destroy deleted my customer-created UAMIs!
| Destroy | Azure portal / CLI | The UAMIs were incorrectly placed inside the outpost's Cortex-managed resource group.
Terraform deletes UAMIs placed inside the outpost's Cortex-managed resource group during a destroy operation.
Recreate the UAMIs in a customer-owned resource group outside of the outpost boundaries and re-onboard.
|
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://cortex-docs.paloaltonetworks.com/data-security-documentation/onboard-and-configure/csp-onboarding/outpost-onboarding/outpost-troubleshooting.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.