Access & Identity
GlobalProtect (Remote Access & Large-Scale VPN) 22
Learning objectives
- Explain the roles of the GlobalProtect portal vs. gateway
- Describe how LSVPN removes manual per-site IPSec tunnel configuration
- Identify which GlobalProtect features require a paid Gateway license
Palo Alto's VPN/endpoint-agent product: it extends the same App-ID/User-ID/Content-ID policy enforcement to remote and mobile users, and (via LSVPN) to branch-office site-to-site connectivity.
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
A GlobalProtect portal distributes agent configuration and gateway lists; gateways terminate the VPN and enforce policy for connected clients. For branch connectivity, Large-Scale VPN (LSVPN) has satellite firewalls auto-establish IPSec tunnels to portal/gateway infrastructure rather than manual tunnel configuration per site. Certificates (from Certificate Management) secure device authentication.
Pros
- Remote users get the exact same App-ID/Content-ID policy enforcement as on-prem users
- Basic portal/gateway deployment (no HIP checks) doesn't require a separate license
- LSVPN scales branch site-to-site VPN without per-tunnel manual config
Cons
- Advanced features — Host Information Profile (HIP) checks, mobile app, IPv6, clientless VPN — need a paid Gateway license
- Client agent deployment/lifecycle management is extra operational overhead across a mixed device fleet
- Gateway sizing/licensing has to scale with concurrent remote-user counts
Exam trap
Don't confuse the portal with a gateway: the portal only distributes agent config/gateway lists (control plane), it doesn't terminate tunnels or enforce policy — that's the gateway's job.Self-check
Q1. A branch office needs site-to-site connectivity without an admin manually building an IPSec tunnel to headquarters. Which GlobalProtect feature fits?
A: Large-Scale VPN (LSVPN) — satellite firewalls auto-establish tunnels to portal/gateway infrastructure instead of manual per-site IPSec configuration.
Q2. A user connects with the basic GlobalProtect app and no HIP checks are configured. Do they need a Gateway license?
A: No — a basic portal/gateway deployment without HIP checks, mobile app, IPv6, or clientless VPN doesn't require a paid Gateway license.
Source: pan-os/11-1/pan-os-admin/subscriptions; ngfw/administration/large-scale-vpn-lsvpn
Authentication Services 23
Learning objectives
- Distinguish an Authentication Profile from an Authentication Sequence
- Explain how Authentication Policy triggers a Captive Portal / Authentication Portal challenge
- List the interactive and non-interactive authentication methods PAN-OS supports
A common authentication layer used both by admins logging into the firewall/Panorama and by end users going through Authentication Portal or GlobalProtect.
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
Supports certificate-based authentication (silent, PKI-driven) as well as interactive methods: MFA, SAML, Kerberos SSO/server auth, TACACS+ (auth and accounting), RADIUS, LDAP, and local database. Each backend is defined once as an Authentication Profile (the server type plus login attribute mapping and timeout/lockout settings); profiles can then be chained into an Authentication Sequence so the firewall tries them in order until one succeeds — useful when migrating between identity providers or supporting multiple business units on different backends. An Authentication Policy rule (evaluated before Security Policy, matched by zone/user/URL category like a security rule) decides which traffic must authenticate and which profile/sequence to use; when a rule matches, unauthenticated users are redirected to a Captive Portal-style Authentication Portal web form (or the GlobalProtect app login screen) before Security Policy is ever evaluated for that session.
Pros
- Broad protocol support means it fits into almost any existing identity stack
- Certificate-based auth avoids user friction entirely where PKI already exists
- Authentication sequences allow layered/fallback authentication methods
Cons
- Each method (SAML, Kerberos, RADIUS...) has its own setup and failure modes to troubleshoot
- Misconfigured connection timeouts to auth servers can cause slow logins or lockouts network-wide
Exam trap
Authentication Policy is evaluated before Security Policy — a common wrong answer is assuming the firewall checks Security Policy first and only prompts for auth if the app is allowed.Self-check
Q1. You want users to try SAML SSO first, and fall back to a local database login if the IdP is unreachable. What do you configure?
A: An Authentication Sequence chaining the SAML profile first, then the local database profile as fallback.
Q2. Two business units use different RADIUS servers with different login attribute mappings. Do they need separate Authentication Profiles or can one profile cover both?
A: Separate profiles — an Authentication Profile is scoped to one server/backend and its attribute mapping, so different backends need their own profile (which can then be combined in a sequence if needed).
Source: ngfw/administration/authentication
Multi-Factor Authentication 24
Learning objectives
- Explain why MFA is applied selectively via Authentication Policy, not everywhere
- List the supported MFA factors and native vendor integrations
- Describe the request flow: Authentication Policy → Authentication Portal → MFA factor(s) → Security Policy
MFA forces a user to prove identity with more than one factor before reaching sensitive services — stolen passwords alone stop being enough to get in.
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
A user request first hits Authentication Policy (evaluated before Security Policy). If a matching rule requires MFA, the firewall shows an Authentication Portal form for the first factor, then a separate MFA login page for each additional factor (some MFA services let the user pick one of several available factors). Only after all factors succeed does the firewall evaluate Security Policy for the requested app/service. Supported factors: Push, SMS, Voice, and One-Time Password. The firewall natively integrates with Duo, Okta Adaptive, PingID, and RSA SecurID for end-user Authentication Policy MFA, and falls back to RADIUS or SAML for any other vendor — but GlobalProtect and admin-login MFA only support RADIUS/SAML integrations, not the native vendor connectors. MFA authentication profiles can't be chained inside authentication sequences.
Pros
- Selective enforcement via Authentication Policy avoids MFA fatigue on low-risk services
- Native connectors (Duo, Okta, PingID, RSA SecurID) simplify integration versus building RADIUS/SAML from scratch
- Kerberos/SAML SSO as the first factor reduces how often users are interrupted
Cons
- GlobalProtect and admin-login MFA are limited to RADIUS/SAML — the native app integrations don't apply there
- MFA profiles can't be combined into authentication sequences, limiting some layered-fallback designs
- Decryption must be in place for the firewall to see and evaluate the traffic MFA is meant to protect
Exam trap
GlobalProtect and admin-login MFA only support RADIUS/SAML — the native Duo/Okta/PingID/RSA SecurID connectors are for end-user Authentication Policy MFA only. This distinction shows up often.Self-check
Q1. You want to enforce MFA on admins logging into the firewall's Web UI using Duo's native integration. Is that supported?
A: No — admin-login MFA only supports RADIUS/SAML integrations, not the native vendor connectors like Duo.
Q2. Why does MFA get applied selectively via Authentication Policy instead of globally?
A: To balance security against user friction — low-value services don't need the extra step, while sensitive/financial/admin access justifies it.
Source: ngfw/administration/authentication/authentication-types/multi-factor-authentication
Credential Phishing Prevention 25
Learning objectives
- Explain how the firewall detects a corporate credential being typed into a web form
- Compare the three detection methods: IP User, Group Mapping, Domain Credential
- Connect credential detection to URL-category-based blocking policy
Credential phishing works because a fake login page is often visually indistinguishable from the real one — the firewall instead watches for the credential itself being submitted to an untrusted site, regardless of how convincing the page looks.
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 uses User-ID to compare submitted username/password pairs against real corporate credentials, via one of three methods: IP User (matches the submitted username against the logged-in user for that source IP — needs only basic User-ID mapping), Group Mapping (checks the submitted username against known LDAP group members — simpler to enable but more prone to false positives since it ignores the password entirely), or Domain Credential (validates the actual username and password against the domain — most accurate, but requires the Windows-based User-ID agent installed on a read-only domain controller with the Credential Service Add-on). Traffic must be decrypted for any of this to see the submitted credential. Once detection is enabled, a URL Filtering profile decides per-category whether credential submission is allowed, alerted, or blocked — e.g. allow submission to your own SSO domain, block it to newly-registered or uncategorized domains.
Pros
- Detects phishing by behavior (credential submission), not by trying to keep up with every fake domain
- Category-based policy lets you allow legitimate SSO/partner sites while blocking the long tail
- Three detection tiers let you trade setup complexity for accuracy
Cons
- Requires decryption to be enabled on the relevant traffic — no visibility otherwise
- Domain Credential mode (the most accurate) has the narrowest platform requirement: Windows-based agent + RODC + add-on
- Group Mapping mode's false-positive rate means it needs tuning before relying on it to actually block
Exam trap
Domain Credential mode checks username and password against the domain; IP User and Group Mapping only ever look at the username — neither validates the password itself. Don't assume any mode confirms the password matched unless it's Domain Credential.Self-check
Q1. Which detection method requires the Windows-based User-ID agent on a read-only domain controller with the Credential Service Add-on?
A: Domain Credential — the most accurate mode, validating both username and password against the domain.
Q2. A user's real corporate username matches a phishing page's submitted username, but the firewall has no way to verify the password. Which detection method is being used?
A: IP User or Group Mapping — both only compare the submitted username, not the password, unlike Domain Credential.
Source: ngfw/help/10-1/objects/objects-security-profiles-url-filtering/user-credential-detection
Cloud Identity Engine 26
Learning objectives
- Distinguish the Cloud Identity Engine's two components: Directory Sync and Cloud Authentication Service
- Explain why moving identity to the cloud reduces per-firewall operational load
- Describe the profile setup flow on the firewall side
Instead of every firewall independently querying on-prem AD/LDAP, the Cloud Identity Engine centralizes directory sync and authentication in the cloud, so firewalls (and Panorama) consume identity as a service rather than each managing its own directory connection.
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, usable independently but stronger together: Directory Sync pulls user/group/device attributes from Azure AD, on-prem AD, or another cloud directory — a fast incremental "sync changes" runs every 5 minutes by default, with a full sync available for recovery. Cloud Authentication Service handles authentication itself: it redirects login requests to a SAML 2.0 identity provider, then maps the authenticated user and applies security policy — configured once centrally instead of per authentication method. On the firewall, you add a Cloud Identity Engine profile (region, instance, domain, update interval, username/group/device attribute formats) under Device > User Identification, tied to the firewall's device certificate; the firewall only pulls attributes for users/groups actually referenced in security policy, not the whole directory. User Context extends this by sharing tags, quarantine lists, and mappings (including Terminal Server agent mappings) across the network for consistent enforcement everywhere.
Pros
- Offloads authentication/directory load from the firewall/Panorama onto the cloud service
- Configure the identity source once instead of per authentication method
- Incremental sync (every 5 min by default) keeps mappings fresh without full-sync overhead
Cons
- Adds a cloud-service dependency to something as fundamental as authentication
- Only pulls attributes for users/groups referenced in policy — forgetting to reference a group in a rule means it silently isn't synced
- Requires a device certificate on every firewall/Panorama that connects, adding a PKI prerequisite
Exam trap
Directory Sync and Cloud Authentication Service are separate, independently usable components — you can sync directory attributes without using the cloud service for authentication, or vice versa.Self-check
Q1. A user/group was just added to Azure AD. How soon will the Cloud Identity Engine reflect that on the firewall, by default?
A: Within about 5 minutes — the default incremental "sync changes" interval — unless a full sync is manually triggered.
Q2. You reference a new AD group in a security rule but the firewall doesn't seem to have synced its members. Why?
A: The Cloud Identity Engine only pulls attributes for users/groups actually referenced in security policy — the group won't sync until it's referenced somewhere and the sync interval elapses.
Source: pan-os/10-1/pan-os-new-features/identity-features/cloud-identity-engine; pan-os/11-0/pan-os-new-features/identity-features/user-context-for-the-cloud-identity-engine
Advanced Identity Concepts & User Context 27
Learning objectives
- Explain why large environments redistribute User-ID data instead of querying sources directly from every firewall
- Describe what gets redistributed (and what can't be)
At scale, having every firewall independently query every mapping source (domain controllers, syslog, GlobalProtect, captive portal) duplicates load and adds latency — redistribution lets a subset of firewalls collect once and share.
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
Selected firewalls collect user mapping information from their sources and redistribute it to other firewalls, instead of every firewall querying the source directly — Panorama can manage this redistribution centrally, which is simpler than wiring up direct firewall-to-firewall redistribution links. Redistribution carries mapping data from any method except Terminal Server agents, and specifically cannot carry Group Mapping or HIP match data. If you use Authentication Policy, firewalls must also redistribute authentication timestamps — generated when a user authenticates — so that Authentication Policy timeout behavior (how long before re-auth is required) stays consistent across every firewall enforcing that user, not just the one that first authenticated them. Data and timestamps travel over the same redistribution flow, no separate configuration needed.
Pros
- Cuts direct-query load on identity sources as the firewall fleet grows
- Panorama-managed redistribution is simpler than a mesh of direct firewall links
- Shared authentication timestamps keep Authentication Policy timeouts consistent fleet-wide
Cons
- Terminal Server agent mappings and Group Mapping/HIP data can't be redistributed — those still need direct configuration per firewall
- Adds another data-flow topology to design and troubleshoot in a large-scale User-ID deployment
Exam trap
Redistribution carries mapping data from any source except Terminal Server agents, and it specifically cannot carry Group Mapping or HIP match data — those always need direct per-firewall configuration.Self-check
Q1. Why must authentication timestamps be redistributed alongside user mapping data when Authentication Policy is in use?
A: So Authentication Policy timeout/re-auth behavior stays consistent across every firewall enforcing that user, not just the one that first authenticated them.
Q2. Can Group Mapping data be redistributed between firewalls?
A: No — Group Mapping and HIP match data cannot be redistributed; only direct configuration per firewall provides them.
Source: ngfw/administration/user-id/deploy-user-id-in-a-large-scale-network/redistribute-user-mappings-and-authentication-timestamps
SCIM Provisioning 28
Learning objectives
- Explain what SCIM standardizes and why identity platforms use it
- Position SCIM relative to User-ID/Cloud Identity Engine in the identity stack
SCIM (System for Cross-Domain Identity Management) is an open standard for automatically creating, updating, and deactivating user/group records between an identity provider and downstream applications — the plumbing that keeps identity data in sync without manual exports.
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
SCIM defines a REST/JSON API for exchanging user and group resources between an identity provider (e.g. Azure AD/Entra ID, Okta) and a service provider. In the Palo Alto identity stack this sits alongside Directory Sync/Cloud Authentication Service in the Cloud Identity Engine: where Directory Sync pulls attributes for policy matching, SCIM-based provisioning keeps the underlying user/group lifecycle (creation, attribute updates, deactivation) automatically current with the source-of-truth IdP, so stale accounts don't keep matching security policy long after someone has left.
Pros
- Automated deprovisioning closes a common access-hygiene gap that manual processes miss
- Standard protocol — works the same way across compliant IdPs instead of a custom sync for each
Cons
- Only as reliable as the IdP-side configuration; a broken SCIM feed silently stops propagating deactivations
- Not itself a policy engine — it keeps identity data current, but User-ID/Cloud Identity Engine still does the actual policy matching
Exam trap
SCIM keeps user/group lifecycle data current (create/update/deactivate) — it is not what performs security-policy matching. Don't confuse it with User-ID or the Cloud Identity Engine's Directory Sync, which is what policy actually reads.Self-check
Q1. An employee is offboarded in the IdP. What keeps their account from silently lingering in downstream systems?
A: SCIM's automated deprovisioning — it pushes the deactivation event to connected systems instead of relying on manual exports.
Q2. Does SCIM decide whether a user's traffic is allowed by a security rule?
A: No — SCIM only keeps identity data (user/group lifecycle) synced; User-ID and Security Policy still do the actual policy matching.
Curriculum: Identity course, "System for Cross-Domain Identity Management" lesson. Not covered as a dedicated topic in the local NGFW docs mirror — summarized against the general SCIM standard and its role alongside the Cloud Identity Engine.
Dynamic User Groups 29
Learning objectives
- Explain what a Dynamic User Group is and how membership changes without a commit
- Give a concrete example of tag-driven automated response
A Dynamic User Group (DUG) is a policy object whose membership is driven by tags that can be added or removed by the firewall itself (or an external system) in real time — no config change, no commit, required to add or remove a user from the group.
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
A DUG object matches users by tag using a filter expression. Tags can be applied automatically — e.g. a Log Forwarding profile's built-in action tags a user when a correlation object or WildFire verdict flags suspicious behavior — and a security rule referencing that DUG (as source user) immediately starts matching them, no commit needed, because tag changes are dynamic runtime state rather than committed configuration. A typical pattern: tag a user "compromised-credentials" when Threat Prevention flags C2 traffic from their session, and have a DUG-based rule quarantine that user to a remediation-only zone until the tag is manually cleared.
Pros
- Enables automated, near-real-time response (quarantine, step-up auth) without waiting on a commit cycle
- Decouples enforcement from static directory group membership
- Tags can originate from multiple sources (log forwarding actions, external orchestration via API) for flexible automation
Cons
- Automation quality depends entirely on tagging logic being correct — a bad automated tag can quarantine legitimate users
- Debugging "why is this user in this group" is harder than reading a static LDAP group, since membership is runtime tag state
Exam trap
DUG membership changes require no commit — that's the entire point. If an exam question implies you need to edit/commit config to move a user in or out of a DUG, that's wrong; only the tag changes.Self-check
Q1. Threat Prevention flags a user's session for C2 traffic. How can policy react to that within seconds, without an admin editing any rule?
A: A Log Forwarding profile action auto-tags the user (e.g. "compromised-credentials"), and a DUG-based security rule referencing that tag immediately starts matching — no commit needed.
Q2. What's the practical difference between an AD group and a Dynamic User Group as source-user match criteria?
A: An AD group reflects static directory membership (changes require directory edits); a DUG reflects runtime tag state that can change automatically and instantly.
Source: ngfw/help/11-1/objects/objects-dynamic-user-groups; ngfw/administration/user-id/deploy-user-id-in-a-large-scale-network/redistribute-user-mappings-and-authentication-timestamps
Implementing User-ID in Security Policy 30
Learning objectives
- Write a security rule that references users/groups instead of IPs
- Recognize common real-world user-based policy patterns
Once User-ID is enabled and mapping IPs to identities, Security Policy rules can reference actual users and groups as source-user match criteria — combined with App-ID, this is what turns "allow TCP/443" into "allow Finance to use Concur."
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
After enabling User-ID and group mapping, a Security Policy rule can set Source User to specific users, AD/LDAP groups, or Dynamic User Groups, combined with the usual zone/app/service match criteria. Typical patterns: restrict admin-style protocols (SSH, Telnet, FTP on standard ports) to IT staff only; allow a specific support team access to a SaaS tool like Slack while leaving it blocked organization-wide; allow broad read access to a category (e.g. social media) but restrict posting/upload capability to a specific marketing group. Rules are still evaluated top-to-bottom, first match wins, same as any other Security Policy rule — user/group criteria is just one more dimension of the match, not a separate rulebase.Pros
- Policy intent maps directly to organizational roles instead of network topology
- Combines cleanly with App-ID for fine-grained "who can do what with which app" rules
- Works whether the group comes from static LDAP or a real-time Dynamic User Group
Cons
- Only as accurate as the underlying User-ID mapping — stale or wrong mappings silently misapply policy
- Group-based rules inherit LDAP group sprawl/hygiene problems if the directory itself isn't well maintained
Exam trap
User/group criteria is just another match dimension in the same Security Policy rulebase — there is no separate "user rulebase." Rules are still evaluated top-to-bottom, first match wins.Self-check
Q1. You want IT staff to be the only ones who can SSH into servers, using standard ports. How do you express that?
A: A Security Policy rule with Source User set to the IT group/AD group, combined with App-ID matching SSH — the rule sits in its normal position in the ordered rulebase.
Q2. What happens if User-ID mapping for a user is stale (wrong IP-to-user mapping)?
A: Policy gets silently misapplied — the rule matches whoever the stale mapping says is at that IP, not the actual current user.
Source: ngfw/administration/user-id/enable-user-and-group-based-policy
Module Quiz
1. A network security administrator has been tasked with deploying User-ID across a mixed environment of domain-joined workstations, GlobalProtect-connected laptops, and a custom internal application that can push mappings itself. Which three are valid methods of collecting User-ID information? (Choose three.)
2. A branch office needs site-to-site-style connectivity to headquarters, but the admin wants satellite devices to auto-establish tunnels against a central portal instead of hand-building IKE/IPSec objects for every new site. Which GlobalProtect capability fits, and does it require the paid Gateway license?
3. An engineer wants to require MFA for a specific finance application without applying it to every other service on the firewall. Which policy layer evaluates first and decides whether that traffic needs to authenticate at all?
4. Two business units authenticate against different RADIUS servers with different login-attribute mappings, and the design must fall back to a local database login if both RADIUS servers are unreachable. How should this be built?
5. An organization uses Duo's native integration for end-user Authentication Policy MFA and now wants admins logging into the firewall's Web UI to use Duo the same way. Is this supported as designed?
6. Security wants to confirm that a credential typed into a suspected phishing page actually matches both a real corporate username and the correct password, not just the username. Which User Credential Detection method is required, and what does it depend on?
7. A URL Filtering profile is configured to block credential submission to uncategorized domains, but logs show no credential-detection events at all for HTTPS traffic to those sites. What is most likely missing?
8. Which two statements about the Cloud Identity Engine are correct? (Choose two.)
9. An engineer configures User-ID redistribution across a large firewall fleet but notices Terminal Server agent mappings never propagate to peer firewalls, even though other mapping sources do. Why?
10. An employee is offboarded in the corporate IdP, but their account continues to authenticate against several downstream systems days later. Which capability, if properly configured, would have automatically deactivated those accounts?
11. Threat Prevention flags a user's session for command-and-control traffic. A Log Forwarding profile auto-tags the user "compromised-credentials," and a matching security rule quarantines them to a remediation zone within seconds — with no admin editing or committing any rule. What makes this possible?
12. An engineer wants only members of the IT group to be able to SSH into servers, while everyone else's SSH attempts are blocked, all inside the existing security rulebase rather than a separate policy layer. Which mechanism achieves this?