zpa-application_segment-pra-onboard

What this skill does

# ZPA: Onboard Privileged Remote Access (PRA) Application

## Keywords

privileged remote access, pra, rdp access, ssh access, jump host, bastion host, jumpbox, pra portal, pra credential, agentless rdp, agentless ssh, browser rdp, browser ssh, secure remote access

## Overview

Onboard a new **Privileged Remote Access (PRA)** application in Zscaler Private Access. PRA segments publish RDP and SSH targets to authorized users through Zscaler's PRA portal — the end user connects through their browser without a native RDP/SSH client and without ZCC. The connection is brokered by the PRA portal and authenticated using PRA credentials managed as separate ZPA resources.

This skill walks through the full dependency chain: connector group → server group → segment group → **PRA credential** → **PRA portal** → **PRA application segment with `apps_config`** → access policy rule.

**Use this skill when:** The admin explicitly mentions Privileged Remote Access, PRA, RDP, SSH, jump host, bastion, or "publish a Windows/Linux server for browser-based remote access."

**DO NOT use this skill when:**

- The admin wants a regular client-routed application segment (any TCP/UDP app reachable via ZCC) — use `zpa-application_segment-onboard` instead.
- The admin wants to publish a clientless **web** application — use `zpa-application_segment-ba-onboard` instead.

---

## What makes PRA different from a regular or BA app segment

| Concept | Regular segment | Browser Access (BA) | Privileged Remote Access (PRA) |
|---|---|---|---|
| SDK / tool family | `zpa_*_application_segment` | `zpa_*_application_segment_ba` | `zpa_*_application_segment_pra` |
| Client requirement | ZCC | Browser only | Browser only (via PRA portal) |
| Per-app config block | none | `common_apps_dto.apps_config` (per domain) | `common_apps_dto.apps_config` (per RDP/SSH target) |
| Per-app `application_protocol` | n/a | `HTTP` / `HTTPS` | **`RDP` / `SSH`** |
| Per-app TLS cert | n/a | `certificate_id` required | n/a |
| RDP-only field | n/a | n/a | `connection_security` (`ANY`, `NLA`, `NLA_EXT`, `TLS`, `VM_CONNECT`, `RDP`) |
| Auto-injected `app_types` | n/a | `BROWSER_ACCESS` | `SECURE_REMOTE_ACCESS` |
| Update-diff field | n/a | `deleted_ba_apps` | `deleted_pra_apps` |
| Auth to the target | client supplies creds | n/a (web SSO) | **PRA credential** (managed as `pra_credential`) bound to the user via the access policy |
| Portal | n/a | n/a | **PRA portal** (`pra_portal`) — the URL users connect to |
| Typical port | any TCP/UDP | TCP 443 / 80 | **TCP+UDP 3389** (RDP) or **TCP 22** (SSH) |
| Access-policy operand type | `APP` | `APP` | `APP` — same |

The biggest source of PRA onboarding mistakes:

1. Forgetting to create / select a **PRA portal** users will connect to.
2. Forgetting to create / select a **PRA credential** for the target host.
3. Putting `connection_security` on an SSH app — it's RDP-only.
4. Forgetting that the same domain in `apps_config[].domain` must also appear in the segment's `domain_names`.

The `zpa_create_application_segment_pra` tool validates #3 and #4 client-side.

---

## Workflow

Follow this 8-step process for complete PRA application onboarding.

### Step 1: Gather Application Details

Collect the following from the administrator:

**Required:**

- Application name (e.g. "DC1 Jump Hosts", "Linux Bastions")
- One or more target host FQDNs / IPs (e.g. `rdp01.acme.com`, `bastion.acme.com`)
- Protocol per target: `RDP` or `SSH`
- Port per target (almost always `3389` for RDP, `22` for SSH)
- For RDP targets: desired `connection_security` mode — `ANY` is the safe default, `NLA` if Network Level Authentication is required
- Who should have access (users, groups, or departments)
- The credential users will authenticate to the target with (username + secret)

**Optional:**

- Description and purpose of the application
- Geographic location of the target servers
- Whether to reuse existing ZPA resources (connector groups, server groups, segment groups, PRA portals, PRA credentials)
- Health check requirements

If the admin says "I want users to RDP/SSH to my servers without installing anything" — this is PRA. If they say "I want users on ZCC to reach an internal API" — **stop and use `zpa-application_segment-onboard`** instead. If they say "publish my intranet website to the browser" — **stop and use `zpa-application_segment-ba-onboard`** instead.

---

### Step 2: Set Up App Connector Group

Check for existing connector groups or create a new one. The same connector groups are used by regular, BA, and PRA segments — there is no PRA-specific connector group.

**List existing:**

```text
zpa_list_app_connector_groups()
```

**Create if needed:**

```text
zpa_create_app_connector_group(
  name="<location>-Connectors",
  description="Connectors serving <application_name>",
  enabled=True,
  latitude="<lat>",
  longitude="<lon>",
  location="<datacenter_or_office>",
  country_code="<country>"
)
```

The create tool already resolves the tenant's enrollment certificate ID automatically.

Save the connector group `id` for the next step.

---

### Step 3: Set Up Server Group

Check for existing server groups or create a new one.

**List existing:**

```text
zpa_list_server_groups()
```

**Create if needed:**

```text
zpa_create_server_group(
  name="<application_name>-Servers",
  description="Server group for <application_name>",
  app_connector_group_ids=["<connector_group_id>"],
  enabled=True,
  dynamic_discovery=True
)
```

Save the server group `id` for Step 7.

---

### Step 4: Set Up Segment Group

Check for existing segment groups or create a new one.

**List existing:**

```text
zpa_list_segment_groups()
```

**Create if needed:**

```text
zpa_create_segment_group(
  name="<application_grouping>",
  description="Segment group for <application_grouping>",
  enabled=True
)
```

Save the segment group `id` for Step 7.

---

### Step 5: Set Up the PRA Credential

A PRA credential carries the username + secret used to authenticate the user **into the RDP/SSH target host**. PRA brokers the connection but the target still needs a real OS-level credential.

**List existing PRA credentials:**

```text
zpa_list_pra_credentials()
```

Pick one if a suitable shared credential already exists (e.g. an Active Directory service account that can RDP to all jump hosts, or a sudo-capable user on the SSH bastions).

**Create if needed:**

```text
zpa_create_pra_credential(
  name="<descriptive-name>",
  description="<purpose>",
  credential_type="USERNAME_PASSWORD",  # or PASSWORD, SSH_KEY, etc.
  user_domain="<AD_domain_if_RDP>",
  username="<account>",
  password="<secret>"
)
```

Save the credential `id` for Step 8 (it gets referenced by the access policy rule, NOT by the segment itself).

> **Note:** Don't put real secrets into a chat. Confirm the credential storage path with the admin and have them create or paste the secret directly into the tenant if needed.

---

### Step 6: Set Up the PRA Portal

A PRA portal is the URL endpoint users navigate to in their browser to launch a PRA session. One portal can serve many PRA segments; reuse an existing portal if one already exists.

**List existing PRA portals:**

```text
zpa_list_pra_portals()
```

**Create if needed:**

```text
zpa_create_pra_portal(
  name="<portal-name>",
  domain="<portal.example.com>",
  enabled=True,
  certificate_id="<ba_or_pra_tls_certificate_id>",
  user_notification_enabled=True,
  user_notification="Welcome to <company> Privileged Remote Access"
)
```

The portal needs a TLS certificate covering its `domain` (look up via `zpa_list_ba_certificates` — BA certs and PRA portal certs come from the same store).

Save the portal `id` for Step 8 (also referenced by the access policy rule).

---

### Step 7: Create the PRA Application Segment

This is the PRA-specific segment step. The `apps_config` block is **required** and must list one entry per RDP/SSH target. Every `apps_config[].domain` must also appear in `domain_n