Access & Identity

Why

Remote and mobile users need the same protection as on-network users, and branch offices need a scalable way to establish site-to-site VPN without hand-building IPSec tunnels one by one.

How

GlobalProtect deliberately splits into two separate pieces instead of one box that does everything — the same reason a hotel splits reception from room access: reception (the portal) needs to be reachable and lightweight so any client can check in, while the actual rooms (the gateways) do the heavy, sensitive work and can scale independently.

• Portal — "how does a client even know what to connect to?" A laptop leaving the office doesn't inherently know which gateway to use, what authentication method applies, or what the current agent settings should be — that has to come from somewhere. The portal is that somewhere: the client checks in here first, the portal authenticates it, then hands back the agent's live configuration plus the specific list of gateways it's allowed to use (which can differ by user group, location, or OS). The portal never sees a byte of the user's actual traffic — its whole job ends the moment it's handed out a config, which is why it can be small and centralized even for a huge fleet.
• Gateway — "who actually does the security work?" This is the piece that terminates the VPN tunnel, decrypts the session, and runs the exact same App-ID/User-ID/Content-ID Security Policy a wired office connection would get. Because this is where the real load lives (crypto, decryption, inspection), gateways are sized and licensed independently from the portal — you can have one portal and many gateways spread across regions, each sized for its own concurrent-user count.

Large-Scale VPN (LSVPN) — "how do I connect fifty branch offices without hand-building fifty tunnels?" A traditional site-to-site VPN means an admin manually creating IKE/IPSec objects for every single branch, one at a time — that doesn't scale past a handful of sites and every new branch is a repeat of the same manual, error-prone work. LSVPN solves it by reusing the exact same portal/gateway roles, just with firewalls instead of laptops as the "clients":

1. A branch firewall is configured as a satellite and points at the LSVPN portal — same check-in concept as a GlobalProtect client.
2. The satellite proves it's a legitimate branch device using a certificate (issued via Certificate Management), not a shared password — a stolen or guessed PSK would let anyone claim to be a branch office, but a certificate has to actually be issued to that device.
3. Once trusted, the portal pushes back that satellite's specific gateway assignment and IPSec configuration — the same "hand out the config" pattern as regular GlobalProtect.
4. The satellite then auto-negotiates its own IKE/IPSec tunnel to those gateways. The admin's job shrinks from "hand-build a tunnel" to "approve a certificate" — adding branch number fifty-one costs the same five minutes as branch number two.

Licensing — "why is some of this free and some of it paid?" Palo Alto draws the license line around advanced capability, not around basic connectivity — the core promise (remote users get real policy enforcement) is free. Portal and gateway deployment cost nothing by default. A paid GlobalProtect Gateway license (purchased per gateway) is only required to unlock capability layered on top of that base:

• Host Information Profile (HIP) checks (and their content updates) — inspecting the connecting device's actual security posture (patch level, disk encryption, AV running) before granting access, not just who's logging in
• the GlobalProtect Mobile App — extending the same tunnel to phones/tablets
• IPv6 connections
• GlobalProtect Clientless VPN — browser-based access to specific web apps with no agent installed at all

Why

Different organizations already run different identity infrastructure (AD, RADIUS, SAML IdP, TACACS+); the firewall needs to plug into whatever exists rather than forcing a new identity silo.

How

Three building blocks stack on top of each other. Take them one at a time:

1. Authentication Profile — "how do I even talk to one specific identity source?" Your company doesn't have one identity system, it has several — maybe an on-prem AD server, a RADIUS box for network gear, and a SAML identity provider for SaaS apps. Each of those speaks a completely different protocol and hands back identity info in a different shape. An Authentication Profile is PAN-OS's answer to "how do I wire the firewall up to this one specific backend": you pick the backend type (LDAP, RADIUS, SAML, Kerberos, TACACS+, local database, or a certificate profile), give it the actual connection details to reach it (server address, shared secret, bind credentials — whatever that protocol needs), and — critically — tell it which field in that backend's response should be treated as "the username" going forward (an AD server can return several different name formats; get this attribute mapping wrong and User-ID/Security Policy will silently be matching the wrong string against every rule). It also carries timeout and lockout settings, because a login attempt has to fail gracefully instead of hanging or letting someone brute-force it indefinitely. One profile = one backend, fully specified. Some profiles are interactive (MFA, SAML, Kerberos SSO, TACACS+, RADIUS, LDAP, local database — the user has to do something); a certificate-based profile is silent and PKI-driven — the device's certificate itself is the proof, nobody types anything.
2. Authentication Sequence — "what if the first backend I check is down, or the user isn't in it?" A single profile is a dead end if that one backend is unreachable. A Sequence is just an ordered list of profiles: try profile 1; only if that backend can't be reached or flatly rejects the login, move on and try profile 2; and so on. This is the mechanism that makes a phased IdP migration painless (old AD profile first, new SAML IdP as the fallback, flip the order once everyone's migrated) and lets two business units on two different RADIUS servers share one login flow without merging their directories.
3. Authentication Policy — "which traffic actually has to prove who it is, and which profile/sequence checks it?" Profiles and sequences are just backends sitting there, unused, until something decides to invoke them. That something is an Authentication Policy rule — matched by zone/source/destination/URL category exactly like a Security Policy rule, but sitting in its own rulebase evaluated before Security Policy ever runs. If a session doesn't match any Authentication Policy rule, it's simply never asked to authenticate here — it goes straight to Security Policy exactly as if this feature didn't exist. If it does match, the firewall has to actually challenge the user for credentials somehow, and that's what an Authentication Portal method is for — three different ways to actually collect the proof:
   • Browser challenge — the browser silently hands over a Kerberos ticket it already has (because the user is domain-joined and already logged into Windows); if that ticket is valid, the user never even sees a prompt.
   • Web form — the fallback for anyone without a silent ticket: an actual login page, backed by whichever profile/sequence applies (MFA, SAML, Kerberos, TACACS+, RADIUS, LDAP, or local auth).
   • Client certificate authentication — the device itself presents a certificate at the TLS layer; nobody types a username or password at all.
   Only once this challenge succeeds does the session get handed off to Security Policy for the normal allow/deny decision.

Why

Not every application needs the same bar: MFA on a low-value internal wiki would just add friction, but financial systems or admin access justify the extra step. Applying it selectively, by application/service/user, balances security against user experience.

How

MFA isn't a separate system bolted on — it reuses the exact same Authentication Policy / Authentication Portal plumbing from the previous section, and just adds more checkpoints after the first one. Walking the request end to end:

1. Authentication Policy decides who even gets stopped. If MFA applied to every single request, users would be hit with push notifications constantly and start reflexively approving them without looking — which defeats the entire point. So the same selective, zone/user/URL-category-matched Authentication Policy rule that gates regular authentication is what decides whose traffic needs the extra step at all. A rule pointed at the finance app's URL category triggers MFA; a rule that never matches the internal wiki means the wiki never asks for it.
2. The user clears the normal login first ("something you know"). This is the ordinary Authentication Portal challenge — password, SSO ticket, whatever the profile says. This is factor one.
3. Then one more challenge per additional required factor ("something you have"). A second screen appears for each factor still required — some MFA services let the user pick which one to answer with if several are enrolled. The factor types PAN-OS supports are Push (approve a prompt on a phone), SMS, Voice (a phone call reads a code), and One-Time Password (a code from an authenticator app) — but note these are just the categories of proof; which specific vendor actually issues and checks that proof is a separate question, covered next.
4. Only once every required factor clears does Security Policy even see the request. Until then, the session is stuck at the authentication layer — it never reaches the allow/deny decision for the actual application.

Why does the MFA vendor split even exist? You'd expect "we integrated with Duo" to mean Duo works everywhere MFA is used — but PAN-OS draws a hard boundary around where a given integration is trusted, because GlobalProtect login and admin login to the firewall/Panorama itself are higher-stakes, lower-volume paths than day-to-day app access, and PAN-OS only ships pre-built, maintained connector logic for the high-volume end-user case:

• End-user Authentication Policy MFA — gets native, plug-and-play connectors for Duo, Okta Adaptive, PingID, and RSA SecurID (or RADIUS/SAML for any other vendor) — built for the everyday "user hits a sensitive app" case.
• GlobalProtect login and firewall/Panorama admin-login MFA — never uses those native connectors, full stop; both only ever speak RADIUS or SAML. Practically: setting up Duo for end-user MFA does nothing for admin-login MFA — that has to be wired up separately, through RADIUS or SAML, even if it's the same Duo tenant underneath.

One more limitation worth remembering because it trips people up: MFA profiles can't be chained inside an Authentication Sequence the way regular authentication profiles can — there is no "try MFA vendor A, and if that's down, fall back to vendor B." If the MFA backend is unreachable, there's no automatic fallback path the way there is for ordinary authentication.

Why

Stolen corporate credentials are one of the highest-value outcomes for an attacker, and phishing pages are cheap to stand up and hard for users to spot. Detecting the credential submission itself is more reliable than trying to blocklist every phishing domain.

How

URL Filtering's User Credential Detection feature has one specific job: watch a username/password being typed into a web form, and figure out — in real time, before the submission completes — whether that's a genuine corporate credential heading somewhere it shouldn't. To do that it has to answer two separate questions, and how confidently it can answer each one is what defines the three detection tiers:

• IP User — "does the typed username match who's logged in here?" This tier reuses data the firewall already has for free: User-ID already knows which user is currently mapped to the source IP the form submission came from. So it just compares the submitted username string against that mapping. It needs nothing beyond basic User-ID — no new agent, no new config — which is exactly why it's the easiest tier to turn on. The catch: it never looks at the password field at all, so it can't tell a correct password from a wrong guess. If an attacker knows a real employee's username (trivial — it's often firstname.lastname), this tier alone can't catch a bad password being phished.
• Group Mapping — "is this at least a real employee's name?" Instead of checking against the live IP-to-user mapping, this checks the submitted username against the list of known LDAP group members. Just as cheap to enable as IP User, and it has the exact same blind spot — the password is never examined. It's actually the least reliable of the three in practice: group membership lists are broader and change less often than live login state, so it's more likely to fire on a name that merely looks plausible, generating more false positives.
• Domain Credential — "did they actually get the password right?" This is the only tier that closes the gap the other two share: it validates the submitted username and password against the real domain, meaning it genuinely confirms the credential was correct, not just that the name was real. That certainty costs infrastructure: it requires a Windows-based User-ID agent installed on a read-only domain controller (RODC — a DC that can be safely placed somewhere less trusted since it can't push changes back to the domain), plus the Credential Service Add-on running alongside it. If an exam question emphasizes "confirms the actual password," this is the only tier that qualifies.

Why does every tier need decryption enabled first? A username/password typed into an HTTPS login form is, by definition, encrypted the moment it leaves the browser — that's the whole point of HTTPS. Without SSL decryption active on that traffic, the firewall is looking at opaque encrypted bytes and literally cannot see the form fields being submitted, so none of the three detection tiers has anything to inspect. This is a hard prerequisite, not a tuning knob.

Once detection can actually see a submission, a URL Filtering profile decides the outcome per destination URL category — this is the step that turns "we detected a credential" into an actual enforcement action:

• Allowed — your own SSO domain, trusted partner sites
• Alerted — logged for visibility, submission still goes through
• Blocked — newly-registered or uncategorized domains, exactly where a phishing kit would live

Why

Large or distributed fleets querying a domain controller directly from every firewall doesn't scale well operationally, and configuring the same authentication source separately for every method (Authentication Portal, admin login, etc.) is repetitive and error-prone.

How

Two components handle this, usable independently but stronger together — the split exists because "who is this user" and "prove it's really them" are genuinely different problems with different failure modes:

• Directory Sync — "who is this user, and what do they belong to?" This is the read side: it pulls user/group/device attributes from Azure AD, on-prem AD, or another cloud directory, and keeps a copy the firewall/Panorama can query without touching the real directory every time. It runs a fast incremental "sync changes" pass every 5 minutes by default — incremental matters here: it's only asking "what changed since last time," not re-pulling the whole directory, which is why it can run that often without hammering anything. A full sync is available separately, for when something has drifted and you need to rebuild from scratch rather than trust the delta trail.
• Cloud Authentication Service — "prove you're actually them, right now." This is the write/interactive side: it redirects a login request to a SAML 2.0 identity provider, waits for that IdP to actually authenticate the user, then maps the now-authenticated identity and lets policy apply. The reason this is worth having as its own component rather than just "configure SAML on the firewall": without it, you'd configure the same identity source separately for every place authentication happens (Authentication Portal, admin login, GlobalProtect) — with it, you wire up the IdP once, centrally, and every consumer just points at this service.

On the firewall side, you add a Cloud Identity Engine profile (region, instance, domain, update interval, attribute formats) under Device > User Identification. That profile is anchored to the firewall's own device certificate — this is the mechanism that lets the cloud service trust that a request claiming to be "Firewall X" really is Firewall X, without a shared password that could leak — plus an already-activated Cloud Identity Engine instance on the hub, which the firewall's Region setting must match exactly.

Two different sync intervals, easy to conflate. The 5-minute incremental pass above is Directory Sync pulling changes from AD/Azure AD into the cloud service — it says nothing about when the firewall itself sees those changes. That second leg is governed by the profile's own Update Interval field (how often the firewall polls the Cloud Identity Engine for updates), which defaults to 60 minutes and can be set anywhere from 5 to 1440 minutes. A firewall showing stale mappings isn't necessarily a Directory Sync problem — check the profile's own Update Interval before assuming the cloud side is behind. One detail worth internalizing because it explains a common "why isn't this syncing" confusion: the firewall only pulls attributes for users/groups that are actually referenced somewhere in security policy — not the whole directory. This keeps sync traffic proportional to what you actually use rather than the size of the entire org, but it also means adding a brand new AD group to a rule and expecting it to already have synced members is backwards — nothing pulls until it's referenced, and even then, only after the next sync interval elapses.

User Context extends the same "centralize instead of per-firewall setup" idea past just directory data: it's a cloud service firewalls connect to for viewing and managing the redistribution of mappings and tags across your whole fleet from one place, instead of an admin wiring up redistribution links firewall by firewall.

Why

Large networks may have far more enforcement points than identity sources, and repeated direct queries from every firewall waste resources on both sides. A user's authentication state and IP mapping also needs to be consistent everywhere the user is enforced against, not just where they first authenticated.

How

The basic mechanism — "one firewall asks, everyone else just listens." A small number of firewalls are designated as collectors: they're the ones actually running Server Monitoring, reading syslog, or whatever other mapping method applies, and building the User-ID table the normal way. Instead of every other firewall repeating that same work against the same sources, those collectors redistribute — push — their finished mapping table out to the rest of the fleet. Panorama can manage this redistribution centrally (define once which firewalls collect and which firewalls receive), which is far simpler to operate than wiring up direct point-to-point redistribution links between every pair of firewalls by hand.

What can and can't ride along — and why the exceptions exist. Redistribution carries mapping data from any collection method except Terminal Server agents, and it specifically can't carry Group Mapping or HIP match data. This isn't an arbitrary limitation: Terminal Server mappings and HIP match data are tied tightly to per-session state on the specific firewall that saw that session (which port range belongs to which user right now, what posture that exact device reported), and Group Mapping is a full LDAP group membership snapshot rather than a lightweight per-user fact — none of the three compress down into the kind of simple "IP → user" record that redistribution is built to carry efficiently. Practically: those three always need their own direct configuration on every single firewall that needs them — there's no shortcut via redistribution for these.

Authentication timestamps — the part people forget. If you use Authentication Policy, there's a second, separate thing that has to travel alongside the mapping data: a timestamp recorded the moment a user actually authenticates. Here's the concrete failure this prevents: a user authenticates once at Firewall A (clearing an Authentication Policy challenge there), then their traffic later happens to be enforced by Firewall B. If B has the user's identity mapping (via redistribution) but no record of when they authenticated, B has no way to know whether that user's authentication session is still fresh or long expired — it couldn't correctly apply its own timeout rule. Sharing the timestamp alongside the mapping is what keeps that timeout decision consistent no matter which firewall in the fleet is doing the enforcing. The two ride the same redistribution flow, so once redistribution itself is configured, there's no separate switch to flip for timestamps.

Why

Manually provisioning and, critically, deprovisioning accounts across every connected system doesn't scale and is a common source of stale access — a departed employee's account lingering somewhere it shouldn't. A standard provisioning protocol lets an IdP push create/update/deactivate events automatically instead of relying on scheduled exports or manual admin work.

How

The mechanism itself. SCIM defines a standard REST/JSON API — a fixed shape for "here is a user resource, here is a group resource, here is how to create/update/ deactivate one" — that an identity provider (Azure AD/Entra ID, Okta, etc.) and a downstream service provider both agree to speak. Because it's a published standard rather than a one-off integration, the create/update/deactivate events flow over that same API the moment they happen in the IdP, and — critically — any SCIM-compliant service on the receiving end understands them the same way, without a custom sync job being written per application.

Why it's worth keeping conceptually separate from Directory Sync, even though the two sit side by side inside the Cloud Identity Engine: they're answering two genuinely different questions on two different timescales. Directory Sync answers the fast-moving, frequently-asked question — "does this user/group match a policy rule right now" — refreshed every few minutes because policy needs to react quickly. SCIM answers a slower, more fundamental question — "does this account exist at all, and is it still active." Think of the relationship this way: SCIM controls whether a record exists to sync in the first place. The moment SCIM deactivates a user in the IdP, that user stops being a valid account entirely — Directory Sync doesn't need any special logic to "notice" the departure, because there's simply nothing left there for it to find and sync on its next pass. This is exactly the mechanism that closes the offboarding gap described above: no admin has to remember to revoke access somewhere, because access was never a separate thing to revoke — it was always downstream of account existence.

Why

Static group membership (LDAP groups, manual lists) is too slow for automated response — by the time an admin edits a group and commits, a compromised user could already have caused damage. DUGs let policy react to a user's current risk state instead of their static org-chart membership.

How

Why "no commit" is even possible here — what's actually different from a normal config change. Every other object on the firewall (a security rule, an address object, a normal AD group reference) is committed configuration — it lives in the candidate/running config, and changing it means editing that config and pushing a commit, which takes real time and touches the whole device. A DUG sidesteps that entirely because its membership isn't config at all — it's a live filter expression evaluated against tags, and tags are runtime data, not configuration. A tag can be attached to or stripped from a user the instant something happens, the same way a log entry gets written instantly — no candidate config, no commit, no device-wide push. The DUG object (the filter expression itself, e.g. "match any user tagged compromised-credentials") is configured once, normally, with a commit like anything else — what never needs a commit again afterward is which specific users currently satisfy that filter.

Where the tags actually come from. Tags can be applied automatically — most commonly, a Log Forwarding profile has a built-in tagging action that fires when a correlation object or a WildFire verdict flags suspicious behavior, stamping a tag onto the responsible user with no human in the loop. (Tags can also be set manually or pushed by an external system via the API — the DUG doesn't care about the source, only that the tag exists.)

The full concrete chain, end to end — this is the example worth memorizing because it shows every piece working together:

1. Threat Prevention observes command-and-control (C2) beacon traffic from a specific user's session — a live detection, happening right now.
2. A Log Forwarding profile's tagging action fires off that detection and auto-tags the responsible user "compromised-credentials" — no admin involved, this is pre-configured automation reacting to a log match.
3. Separately, and in advance — potentially weeks earlier — an admin already wrote a security rule with Source User set to the "compromised-credentials" DUG, routing any match to a remediation-only zone. This rule has been sitting in the rulebase the whole time, matching nothing, waiting for a condition that didn't exist yet.
4. The instant the tag lands on the user (step 2), that pre-built rule (step 3) starts matching them — because the DUG's membership just changed, and DUG membership changes don't need a commit to take effect.
5. The user's traffic now hits the remediation-zone rule and gets contained.

The point of walking through all five steps: detection to containment happens with zero admin action at the moment of the incident — all the human effort (writing the tagging automation, writing the remediation rule) happened ahead of time, once, and then sat dormant until the runtime tag state made it relevant.

Why

IP-based rules can't express business intent — the same subnet might contain finance, engineering, and guest devices. User- and group-based rules let policy match how the organization actually thinks about access.

How

Mechanically, what changes. Once User-ID is enabled and group mapping is populated, a Security Policy rule gets one more match field: Source User. It accepts specific individual users, AD/LDAP groups, or Dynamic User Groups, and it combines with the zone/app/service criteria a rule already has — it isn't a new kind of rule or a separate rulebase, it's the exact same rule with one more filter applied on top. This matters because it means everything you already know about how Security Policy rules behave (ordering, logging, actions) still applies unchanged.

Three patterns that show up constantly, and the reasoning behind each:

• Lock down admin-style protocols to IT staff only. A rule allowing SSH/ Telnet/FTP on standard ports, with Source User set to the IT group. The reason this beats a subnet-based rule: subnets describe where a device physically sits, not who's using it — a guest laptop plugged into the "IT subnet" via a spare port would pass a subnet-based rule but fails a user-based one, because they're not actually in the IT group.
• Carve a narrow exception into an org-wide block. Slack is blocked organization-wide by a lower-priority rule, but a higher rule allows it specifically for Source User = Support group. Because rules evaluate top-to-bottom and stop at first match, Support's traffic matches the narrower allow rule above the broad deny and never reaches it — everyone else's Slack traffic falls through to the deny exactly as before. This is a direct, practical consequence of ordinary rule ordering, just with a user condition added.
• Split read access from write/upload access on one URL category. One rule allows browsing the "social-media" category for everyone; a separate, more specific rule (matched on the same category plus an App-ID for the upload/posting function) restricts that narrower action to Source User = Marketing group. This shows user criteria combining with App-ID granularity, not just replacing it.

The one thing that never changes: rules still run top-to-bottom, first match wins, exactly like a rulebase with no user criteria at all. Adding "who" to a rule never alters evaluation order — it only narrows what that specific rule is willing to match, the same way adding a service or an application to a rule would.