> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serval.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Palo Alto Strata Cloud Manager

> Strata Cloud Manager is the cloud management plane for Palo Alto Networks firewalls, Prisma Access, and SD-WAN - Serval connects to one tenant with an IAM service account so workflows can inventory devices and read or change security configuration.

## About Palo Alto Strata Cloud Manager

Strata Cloud Manager is the cloud management plane for Palo Alto Networks NGFWs, Prisma Access, and SD-WAN. Serval connects to a single Strata Cloud Manager tenant using a Palo Alto Networks IAM service account, and once connected, workflows read the tenant's device inventory and configuration hierarchy, manage policy objects and security rules, and push configuration changes out to the firewalls.

**Authentication:** OAuth 2.0 client credentials (a Palo Alto Networks IAM service account). Serval exchanges the stored Client ID and Client Secret for short-lived access tokens scoped to your Tenant Service Group, automatically - there is no browser redirect and no per-user sign-in.

**Data sync:** two optional ingestion workflows sync devices and folders into Serval as external assets. Everything else runs on demand: workflows call the live Strata Cloud Manager API when they run.

## What the Strata Cloud Manager integration enables

| Capability                     | Description                                                                                                                                                                                                                                                                |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Device inventory               | List every firewall and appliance the tenant manages, with hostname, IPv4/IPv6 and MAC addresses, model, product family, software and content versions, HA state, connection status, and installed licenses - the source data for CMDB and asset-reconciliation workflows. |
| Configuration hierarchy        | Read the folders, labels, snippets, and variables that devices are organized into, plus the sites and site groups used for SD-WAN device onboarding.                                                                                                                       |
| Network configuration          | Read the interfaces (ethernet, aggregate, VLAN, loopback, tunnel, and subinterfaces), security zones, logical routers, IKE gateways and IPsec tunnels, BGP profiles and route maps, NAT and PBF rules, and QoS settings a firewall is configured with.                     |
| SD-WAN and deployment topology | Read the SD-WAN rules, path-quality, traffic-distribution and error-correction profiles, link tags, and AutoVPN clusters, plus the remote networks, service connections, bandwidth allocations, BGP routing, and physical sites that make up a Prisma Access deployment.   |
| Policy objects                 | Create, read, update, and delete address objects and groups, services, tags, applications, regions, schedules, dynamic user groups, external dynamic lists, and log-forwarding and server profiles.                                                                        |
| Security rules and profiles    | Read and change security, decryption, DoS-protection, and app-override rules (including reordering them), along with the anti-spyware, URL-filtering, WildFire, file-blocking, and vulnerability-protection profiles they reference.                                       |
| Configuration push             | Push the candidate configuration to the tenant's devices and track the resulting job to completion.                                                                                                                                                                        |
| Operational reads              | Pull a device's running configuration, and run route-table, FIB, DNS-proxy, interface, and rule-status jobs against a device for troubleshooting workflows.                                                                                                                |
| Generic API access             | Call any of these endpoints through Serval's Strata Cloud Manager API request action - 263 typed endpoint paths across configuration setup, device onboarding, network services, network deployment, objects, security services, config operations, and troubleshooting.   |

Anything defined in the [Strata Cloud Manager API](https://pan.dev/scm/api/) on `api.strata.paloaltonetworks.com` can be accessed through Serval.

## Get your credentials

Serval needs a **service account** created in Strata Cloud Manager, and the **TSG ID** of the tenant it should manage. See Palo Alto Networks' [service accounts documentation](https://pan.dev/scm/docs/service-accounts/) for full details.

<Steps>
  <Step title="Open Identity & Access in Strata Cloud Manager">
    In the left panel, go to **Settings > Identity & Access**.
  </Step>

  <Step title="Note the TSG ID">
    The Tenant Service Group ID is shown at the top of the Identity & Access page, next to the tenant name. It is numeric. Confirm it belongs to the tenant you want Serval to manage - a service account can be entitled to several.
  </Step>

  <Step title="Add a service account">
    Add a new identity, choose **Service Account** as the identity type, name it (for example, "Serval Integration"), and continue.
  </Step>

  <Step title="Download the client credentials">
    Download and save the credentials file. It contains the Client ID and Client Secret.
  </Step>

  <Step title="Assign a role">
    Give the service account a role on this tenant. Read-only roles are enough for inventory and reporting workflows; workflows that create objects, change rules, or push configuration need a role that grants those permissions.
  </Step>
</Steps>

<Warning>
  The Client Secret is available **only** in the credentials file downloaded at creation, and cannot be retrieved later. Save it before leaving the page - if you lose it, generate a new secret (or a new service account) in Strata Cloud Manager.
</Warning>

## Connect in Serval

<Steps>
  <Step title="Open the Strata Cloud Manager connect form">
    In Serval, open the Palo Alto Strata Cloud Manager integration and start a new connection.
  </Step>

  <Step title="Enter your TSG ID (required)">
    The numeric Tenant Service Group ID from the step above. A non-numeric value is rejected with "TSG ID must be the numeric Tenant Service Group ID shown in Strata Cloud Manager".
  </Step>

  <Step title="Enter your Client ID (required)">
    The service account's Client ID, which looks like `name@1234567890.iam.panserviceaccount.com`.
  </Step>

  <Step title="Enter your Client Secret (required)">
    The service account's Client Secret (a password field).
  </Step>

  <Step title="Save the connection">
    Submit the form, then run the health checks below to confirm the credentials and the role assignment are both right.
  </Step>
</Steps>

<Note>
  The TSG ID is part of the connection's identity, so one Serval team can connect several Strata Cloud Manager tenants - each with its own TSG ID - without them colliding. Reconnecting with the same TSG ID updates the existing connection.
</Note>

<Note>
  When editing an existing connection, the Client Secret displays obfuscated. Leaving it unmodified keeps the stored secret - you only need to fill in the fields you are rotating.
</Note>

## Verifying the connection

The integration ships four health checks:

* **Validate API connection** - reads a single folder, confirming the token exchange works and the service account has a role on this tenant.
* **List devices** - confirms the connection can read the tenant's device inventory.
* **List folders** - reads the configuration hierarchy the devices are organized into.
* **List address objects** - reads the address objects in the **Shared** folder, confirming the service account's role reaches the objects API and not only the setup API.

<Tip>
  All four checks can pass while a workflow still fails with a permission error - the checks only exercise reads. Any workflow that creates objects, edits rules, or pushes configuration needs a Strata Cloud Manager role that permits those actions.
</Tip>

## Syncing devices into Serval

Two installable ingestion workflows are available:

* **Ingest Devices from Palo Alto Strata Cloud Manager** - syncs the managed firewalls and appliances as external assets, carrying the full device record (hostname, addresses, model, family, software and content versions, HA state, licenses).
* **Ingest Folders from Palo Alto Strata Cloud Manager** - syncs the folder hierarchy, including each folder's parent and labels.

Both page through the tenant and are safe to schedule. Devices reference their folder by name, so ingesting folders alongside devices is what makes the location and grouping resolvable.

## Gotchas and troubleshooting

<AccordionGroup>
  <Accordion title="A 401 right after connecting usually means the TSG ID, not the credentials">
    Strata Cloud Manager scopes every access token to a Tenant Service Group. A valid Client ID and Secret paired with a TSG the service account is not entitled to fails at the token exchange, which surfaces the same way a bad secret does. Re-check the TSG ID at the top of the Identity & Access page in the tenant you intend to manage.
  </Accordion>

  <Accordion title="A 403 on some endpoints but not others is the role, not the connection">
    Permissions come from the role assigned to the service account in Strata Cloud Manager, not from anything stored in Serval. A read-only role passes the setup health checks and then fails a workflow that writes. Grant the role the workflow needs on the tenant.
  </Accordion>

  <Accordion title="Most collection reads must name a container">
    The objects, security-services, and network-services endpoints require exactly one of `folder`, `snippet`, or `device` as a query parameter and answer 400 without one, even though the API reference marks them optional; the deployment endpoints declare `folder` required outright. Pass `folder: "Shared"` (or the specific folder you mean) for a spot read. A workflow that wants the whole tenant has to list folders first and repeat the read for each one - only the device list and AutoVPN clusters are flat, tenant-wide collections. Security rule reads additionally require `position`, which is either `pre` or `post`.
  </Accordion>

  <Accordion title="The networking APIs return configured intent, not live state">
    `/config/network/v1` describes how interfaces, zones, routers, and tunnels are configured, which is not the same as what a firewall is doing right now. An interface's addresses live at `layer3.ip[].name` and only on the static variant, so a DHCP-addressed interface has no address there at all. Live interface status, the real route table, and the FIB come only from the `/operations/v1/jobs/*` endpoints, which are asynchronous per-device jobs you submit and then poll - workable for a single device in a troubleshooting workflow, impractical for bulk inventory.
  </Accordion>

  <Accordion title="Configuration changes do nothing until they are pushed">
    Creating or editing an object or a rule only changes the tenant's candidate configuration. It reaches the firewalls when the candidate configuration is pushed, which returns a job - poll that job until it completes before treating the change as live. A workflow that writes and then stops has not changed anything on the network.
  </Accordion>

  <Accordion title="Prisma Access tenants on the older SASE host are not covered">
    This connection is pinned to `api.strata.paloaltonetworks.com`. Palo Alto Networks also serves parts of this API from `api.sase.paloaltonetworks.com` under different paths, and the tenancy, subscription, and licensing APIs live only there - none of those are reachable through this integration.
  </Accordion>

  <Accordion title="Device id is documented as a UUID but is usually a serial number">
    The device record's `id` field is described as a UUID in the API reference; hardware firewalls report their serial number there. The ingestion workflow keys assets on `id` without depending on which it is, and forwards the whole device record so a downstream mapping can pick whichever identifier your CMDB expects.
  </Accordion>

  <Accordion title="Rate limiting on heavy workflows">
    Strata Cloud Manager enforces API rate limits per tenant. Prefer paged collection reads over one call per resource, and keep scheduled workflows on a modest interval - see Palo Alto Networks' [API best practices](https://pan.dev/scm/docs/api-best-practices/).
  </Accordion>
</AccordionGroup>

***

Need help? Contact **[support@serval.com](mailto:support@serval.com)** for assistance with your Palo Alto Strata Cloud Manager integration.