Outpost troubleshooting

Check here for solutions to issues that might occur while configuring, deploying, and operating outposts.

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 <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 <CUSTOMER_APP_CLIENT_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 <APP_ID> --owner-object-id <TF_RUNNER_OBJ_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 <SP_OBJ_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 <X> but the outpost is being deployed to <Y> ...	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 <X> but the outpost subscription is in tenant <Y> ...	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 <APP_ID>. Add the owner by running: az ad app owner add --id <APP_ID> --owner-object-id <TF_RUNNER>
Stale federated credential Error: Another object with the same value for property federatedIdentityCredentials/<name> 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 <APP_ID> -o table. Delete the conflicting one with az ad app federated-credential delete --id <APP_ID> --federated-credential-id <NAME>. 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 <UAMI_PRINCIPAL_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 <SP_OBJ_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 <APP_ID>) and on the UAMI (az identity federated-credential list --name <UAMI_NAME> -g <UAMI_RG>). 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.