Skip to main content

​
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

Anything defined in the Strata Cloud Manager 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 for full details.
1

Open Identity & Access in Strata Cloud Manager

In the left panel, go to Settings > Identity & Access.
2

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.
3

Add a service account

Add a new identity, choose Service Account as the identity type, name it (for example, “Serval Integration”), and continue.
4

Download the client credentials

Download and save the credentials file. It contains the Client ID and Client Secret.
5

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.
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.

​
Connect in Serval

1

Open the Strata Cloud Manager connect form

In Serval, open the Palo Alto Strata Cloud Manager integration and start a new connection.
2

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”.
3

Enter your Client ID (required)

The service account’s Client ID, which looks like name@1234567890.iam.panserviceaccount.com.
4

Enter your Client Secret (required)

The service account’s Client Secret (a password field).
5

Save the connection

Submit the form, then run the health checks below to confirm the credentials and the role assignment are both right.
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.
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.

​
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.
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.

​
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

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.
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.
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.
/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.
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.
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.
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.
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.
Need help? Contact support@serval.com for assistance with your Palo Alto Strata Cloud Manager integration.