ZPA Access Policy — default-deny, first-match

1. Why Enabled is not an allow

Lesson 9 taught the broker. Lesson 10 put App Connectors next to the app. This page is the decision: which user, on which device, may reach which exact private destination.

A firewall engineer arriving from PAN-OS or FortiGate wants a bottom Deny Any. Official ZPA Help is the opposite. By default ZPA blocks access to applications and Segment Groups until you configure policy rules that explicitly allow access. A terminal Block-All is redundant. If you drag it above later Allows, it becomes a self-inflicted outage.

Hero · who talks to whom

Two different tickets hide in the same user sentence “Jira is down.”

• No matching Allow — default-deny. The segment exists. The user is authenticated. No Access Policy line matched. Diagnostics show a policy deny / no allow, not a dead connector.
• Wrong first match — a broad Allow sitting above a contractor Block. The contractor is in. The Block rule is dead code. Diagnostics show the wrong Policy name.

2. Mental model — object chain

Policy cannot allow a thing you never defined. Memorise four objects. Every “authenticated but blocked” ticket is a broken link in this chain.

3. Match-order flowchart

Do not start the whiteboard with the Add Rule form. Start with the request. Official Help: ZPA evaluates Access Policy using the most specific Application Segment and a top-down, first-match principle. If a user must be blocked while a broader group is allowed, the Block rule must sit above the Allow.

Path · request → most-specific → first-match

Worked example you can say in an interview:

1. Two segments exist: *.lab.example TCP 443 (wildcard, discovery) and payroll.lab.example TCP 443 (exact).
2. User requests payroll.lab.example:443. ZPA selects the more specific segment — the exact FQDN — not the wildcard.
3. Access Policy is then walked only in that context, top-down. Rule 1: Block Access if SCIM group = Contractors. Rule 5: Allow Access if SCIM group = Finance and posture = Compliant-Win.
4. A contractor hits rule 1 and stops. A Finance user on a compliant Windows laptop misses rule 1, hits rule 5, Allow. An intern in neither group matches nothing and is denied — you did not need a bottom Block-All.

4. How to choose — ports, bypass, criteria

Use these tables in the design review. The wrong knob is usually “we published the whole RFC1918 range and hoped policy would save us.”

Application Segment knobs

Access Policy criteria

5. Runbook Side A → B → C

Lab goal: only the SCIM group Finance on a compliant ZCC Windows laptop may reach payroll.lab.example TCP 443. Contractors are explicitly blocked. Everyone else hits implicit deny. You will prove the Allow and the Block in User Activity.

Primary sources: Zscaler Help — Configuring Defined Application Segments; Configuring Access Policies; About Access Policy; Accessing User Activity Diagnostics.

Side A — Define the application

1. Write the destination on paper first

   FQDN users type, TCP/UDP ports, internal server the App Connector can resolve, who should reach it. Lab: payroll.lab.example, TCP 443, server 10.40.20.15, audience = Finance. If APIs hit 8443, that port must be on the segment too — a 443-only definition will never match 8443 (flowchart step 2).

2. Create the Application Segment

   ZPA Admin → Resource Management → Application Management → Application Segments → Defined Application Segments → Add. Name Payroll-Lab, status Enabled, domain payroll.lab.example, TCP port 443. Place it in Segment Group SG-Finance (exactly one). Bind Server Group DC1-Payroll-Servers.

3. Set Bypass Type and Double Encryption on purpose

   Bypass Type = Never so the session is brokered and logged. Double Encryption = Disabled unless a written control requires the inner crypto layer. Health reporting On for TCP 443 only.

Side B — Write Access Policy

1. Turn on identity for policy on the IdP

   Administration → IdP Configuration → Edit IdP (classic ZPA Admin). Enable SAML Attributes for Policy and SCIM Attributes and Groups for Policy. If either toggle is Off, a rule that depends on that criterion is silently skipped — SSO still succeeds, the user still falls to default-deny.

2. Add the narrow Block first

   Official current Help path: Policies → Access Control → Private Applications → Access Policy → Add. Classic ZPA Admin still says Policy → Access Policy → Add Rule. Rule name Block-Contractors-Payroll, action Block Access, applications = Segment Group SG-Finance (or the Payroll-Lab segment), SCIM Group = Contractors. Give it a lower order number than the Allow. Official Help: list the block rule before the allow rule.

3. Add the Finance Allow under it

   Rule name Allow-Finance-Payroll, action Allow Access, same Segment Group, SCIM Group = Finance, Posture Profile = Compliant-Win, Client Type = Client Connector. Do not add a bottom Block-All. Implicit deny is already there.

Side C — Prove it in ZPA diagnostics

1. Open User Activity, not a screenshot of the rule

   Logs → Insights → Diagnostics. Log Type = User Activity. Filter on the pilot username and the last 15 minutes. Official field list includes Policy (access policy rule name), Application, AppGroup, Host, ServicePort, ConnectionStatus, InternalReason, DoubleEncryption, Username, Connector.

2. Finance allow must name the rule

   From a compliant ZCC Windows laptop, open https://payroll.lab.example. Success is a row with Policy = Allow-Finance-Payroll, Application = Payroll-Lab, Host = payroll.lab.example, ServicePort = 443, and a successful ConnectionStatus. If Policy is a different rule, first-match already fired somewhere else — do not add another Allow.

3. Contractor block must also leave a row

   Repeat as a Contractor user. You want Policy = Block-Contractors-Payroll and a deny / block status — not silence. Silence usually means Bypass Type Always, or the FQDN/port never matched a segment. An intern in neither group should show no matching Allow (implicit deny), not your contractor Block.

6. Runtime path after go-live

After save, the click path is the flowchart you already walked — plus two things that are not policy.

1. Client Connector matches payroll.lab.example to an Application Segment and hands the process a synthetic IP. The real 10.40.20.15 never lands on the laptop.
2. The SYN rides the existing ZCC → Service Edge leg. The edge selects the most specific segment for that FQDN+port.
3. Access Policy is evaluated first-match. Allow → pick a healthy App Connector from the Server Group. Block or no match → stop. No stitch.
4. On Allow, the connector dials payroll.lab.example:443 locally. The edge stitches the microtunnel. Payroll sees the connector source IP, not the user’s home IP.
5. User Activity writes Policy, Application, Host, ServicePort, ConnectionStatus. That row is the audit trail. The rule form is not.

Proof · diagnostics desk

7. Traps + proof

Pilot checklist

• Payroll-Lab exists with TCP 443 only, Bypass = Never, Double Encryption = Disabled, one Segment Group, one Server Group.
• IdP: both “for Policy” toggles On. SCIM shows Finance and Contractors as direct members.
• Access Policy order: Block-Contractors-Payroll (1) then Allow-Finance-Payroll (5). No bottom Block-All.
• Finance + compliant ZCC: User Activity Policy=Allow-Finance-Payroll, Application=Payroll-Lab, ServicePort=443.
• Contractor: Policy=Block-Contractors-Payroll.
• Intern / unknown group: denied with no Allow match (implicit deny).
• Wrong port 8443: no segment match — proves ports are part of the definition, not “whatever TCP.”

Sources

• Zscaler Help — About Access Policy (most specific Application Segment + top-down first-match; SAML/SCIM, posture, trusted networks, client types as criteria)
• Zscaler Help — Configuring Access Policies (Policies → Access Control → Private Applications → Access Policy; default block until an Allow exists; list the block rule before the allow)
• Zscaler Help — About Policies / Policy Evaluation Order (most specific segment + first-match)
• Zscaler Help — Configuring Defined Application Segments (Resource Management → Application Management → Application Segments)
• Zscaler Help — About Applications (Double Encryption, health reporting configured per Application Segment)
• Zscaler Help — Configuring Bypass Settings (Bypass Type on the Application Segment)
• Zscaler Help — Understanding Double Encryption (inner crypto layer inside the outer TLS tunnels)
• Zscaler Help — ICMP and Double Encryption (ICMP does not work with Double Encryption)
• Zscaler Help — Accessing User Activity Diagnostics (Logs → Insights → Diagnostics → User Activity)
• Zscaler Help — Understanding User Activity Log Fields (Policy, application, connection fields)
• Zscaler Help — Understanding Private Access Session Status Codes
• Zscaler Help — ZPA Leading Practices Guide (rule order matters; most specific + first-match)

Related: Lesson 9 · ZPA architecture · Lesson 10 · App Connectors · ZPA Access Policy deep-dive · Application Segments deep-dive · Zscaler authentication · Lesson 12 · CBI / SIPA