Dynamic User Groups & Auto-Tagging in PAN-OS

What are Dynamic User Groups (DUGs)?

Dynamic User Groups (DUGs) automatically update their membership based on tags associated with users, rather than a static list of usernames. This enables policies that dynamically adapt to changing conditions like user behavior or potential threats without needing manual updates.

Benefits:

• Auto-Remediation: Automatically restrict users tagged as 'risky' or 'compromised'.
• Time-Bound Access: Grant temporary access by applying and timing out tags.
• User Visibility: Group users based on detected activities for more granular policy enforcement.

How DUGs Work: Tags as Filters

You define a DUG by specifying tag-based criteria using logical AND / OR operators (negation is not supported). When a user gains a tag (or combination of tags) that matches the DUG's filter, they are automatically added to the group. When the tag(s) are removed or expire, the user is automatically removed from the DUG.

Example: A DUG named `Require-MFA-Group` could be defined with the filter matching the tag `require-mfa`. Any user who gets tagged with `require-mfa` instantly becomes a member of this group.

Diagram: DUG Concept

graph LR
    subgraph Tag_Sources [Tag Sources]
        API(XML API)
        UIDAgent(User-ID Agent
/AD Monitor)
        AutoTag(Auto-Tagging
/Log Forwarding)
        Manual(Manual/Panorama)
    end

    subgraph User_Identity
        U1[User: Alice
Tags: low-risk]
        U2[User: Bob
Tags: high-risk, require-mfa]
        U3[User: Charlie
Tags: contractor, temp-access]
    end

    subgraph DUG_Definitions [DUG Definitions]
       DUG_Risky("DUG: Risky-Users
Filter: 'high-risk'")
       DUG_MFA("DUG: Require-MFA-Group
Filter: 'require-mfa'")
       DUG_Temp("DUG: Temp-Access
Filter: 'temp-access'")
    end

     subgraph Policy_Enforcement [Policy Enforcement]
        Policy1("Security Policy
Source User: Risky-Users
Action: Deny")
        Policy2("Authentication Policy
Source User: Require-MFA-Group
Action: Enforce MFA")
        Policy3("Security Policy
Source User: Temp-Access
Action: Allow to Specific Apps")
     end

    API --> U2 & U3;
    UIDAgent --> U1;
    AutoTag --> U2;
    Manual --> U3;

    U1 -- No Match --> DUG_Risky;
    U2 -- Match --> DUG_Risky;
    U3 -- No Match --> DUG_Risky;

    U1 -- No Match --> DUG_MFA;
    U2 -- Match --> DUG_MFA;
    U3 -- No Match --> DUG_MFA;

    U1 -- No Match --> DUG_Temp;
    U2 -- No Match --> DUG_Temp;
    U3 -- Match --> DUG_Temp;

    DUG_Risky --> Policy1;
    DUG_MFA --> Policy2;
    DUG_Temp --> Policy3;

    style DUG_Risky fill:#ffc,stroke:#333,stroke-width:1px
    style DUG_MFA fill:#ffc,stroke:#333,stroke-width:1px
    style DUG_Temp fill:#ffc,stroke:#333,stroke-width:1px

Where Do Tags Come From? (Tag Registration)

Tags are metadata labels associated with users (or IP addresses). They can be:

• Static: Defined directly in the firewall/Panorama configuration ( Objects > Tags ).
• Dynamic: Applied or removed at runtime without needing a configuration commit. This is the key to automation.

Dynamic tags for users can be registered (associated with a user) via:

• XML API: Allows external systems (SIEM, SOAR, custom scripts, threat intelligence platforms) to push user-tag mappings.
• User-ID Agent (Windows): Can monitor Active Directory group memberships and automatically apply tags corresponding to those groups.
• Panorama / Firewall GUI / CLI: Manual registration or via configuration.
• Auto-Tagging (Log-Based): Automatically apply tags based on log events (explained below).
• VM Information Sources / Panorama Plugins (for IPs): Can apply tags based on VM attributes from vCenter, AWS, Azure, GCP etc. (Primarily for Dynamic Address Groups, but relevant to the ecosystem).

Automating Actions with Auto-Tagging

Auto-tagging is the mechanism that allows the firewall or Panorama to automatically apply or remove tags based on specific criteria found in generated logs. This links observed behavior or events directly to dynamic policy enforcement through DUGs.

Diagram: Auto-Tagging Workflow

sequenceDiagram
    participant User
    participant Firewall
    participant Logger as Log Processing Engine
    participant LogFwd as Log Fwd Profile /
Log Settings
    participant UserTagDB as User-ID / Tag Database
    participant PolicyEngine as Policy Engine

    User->>Firewall: Accesses Risky Site / Event Occurs
    Firewall->>Logger: Generates Log (e.g., Threat, URL)
    Logger->>LogFwd: Log Sent for Processing
    LogFwd->>LogFwd: Evaluate Filter Criteria (e.g., threat ID, URL category)
    alt Log Matches Filter
        LogFwd->>UserTagDB: Execute Built-in Action: Add/Remove Tag for User/IP
        Note over UserTagDB: User/IP tag mapping updated
    end
    Note over Firewall, PolicyEngine: Later Traffic from User/IP...
    Firewall->>PolicyEngine: Evaluate Policy for New Session
    PolicyEngine->>UserTagDB: Check User/IP Tags
    UserTagDB-->>PolicyEngine: Provide Current Tags
    PolicyEngine->>PolicyEngine: Match Policy Rule using DUG/DAG
    PolicyEngine->>Firewall: Apply Policy Action (Allow/Deny/MFA)

Configuration Steps (Simplified)

1. Define the Tag: Create the tag you want to use ( Objects > Tags ), e.g., `compromised-credential`.
2. Configure the Trigger (Log Forwarding/Settings):
   • Determine the log type that indicates the event (e.g., URL Filtering log for credential detection).
   • Based on log type, go to Objects > Log Forwarding or Device > Log Settings .
   • Create or edit a profile/setting for that log type.
   • Add a Filter to match the specific event (e.g., `(credential-detected eq yes)`).
   • Add a Built-in Action > Tagging :
     • Target: `Source User` (or Source Address, etc.)
     • Action: `Add Tag`
     • Tags: Select `compromised-credential`
     • Timeout: Set an appropriate duration (e.g., `480` for 8 hours) or `0` for permanent until removed.
     • Registration Source: Choose `Local` or configure HTTP profile for remote sharing.
3. Create the Dynamic User Group:
   • Go to Objects > Dynamic User Groups , Add.
   • Name: e.g., `Users-Require-MFA`.
   • Match Criteria: Select the tag `compromised-credential`.
4. Create/Modify Policy using the DUG:
   • Go to Policies > Authentication (or Security, Decryption).
   • Create a rule.
   • In the Source User field, add the DUG `Users-Require-MFA`.
   • Configure the desired Action (e.g., apply an MFA Authentication Profile).
   • Ensure rule placement is logical (often specific rules come before general allow rules).
5. Assign Log Forwarding Profile (Crucial Link):

   Why is Assigning the Log Forwarding Profile Needed?

   For log types handled by Log Forwarding Profiles (Threat, URL, Traffic, etc.), simply creating the profile isn't enough. The firewall needs to know *which traffic* should have its logs processed by that profile's filters and actions.

   You **must** assign the Log Forwarding Profile you created (the one containing your auto-tagging filter and action) to the specific Security Policy rule(s) that allow the traffic which generates the trigger logs.

   Think of it this way:

   • The Security Rule says: "Let this web traffic through."
   • The attached Log Forwarding Profile says: "And WHILE that traffic is flowing, IF you see a URL log matching 'credential-detected=yes', THEN execute the 'Add Tag' action."

   Without attaching the profile to the Security Rule (under the rule's Actions tab), the firewall allows the traffic and generates the standard logs, but it doesn't perform the extra check defined in the Log Forwarding Profile, so no auto-tagging occurs for these log types.

   (This assignment step is *not* needed for log types configured directly under Device > Log Settings, like User-ID or GlobalProtect logs, as their tagging actions are tied directly to the log generation itself.)

   • If the trigger log (e.g., URL Filtering) is generated by traffic matching a Security Policy rule, assign the Log Forwarding Profile created in Step 2 to that Security Policy rule (under the rule's Actions tab).
6. Commit all configuration changes.

Best Practices & Verification

• Plan Your Tags: Use a consistent naming convention.
• Filter Specificity: Make log filters precise.
• Timeouts: Use strategically for temporary actions. Match IP tag timeouts to DHCP leases.
• API for Scale: Prefer API for large-scale or external system integration.
• Policy Order: Ensure traffic generating trigger logs is allowed *before* potential block rules using the DUG.
• Verification: Use CLI (`show user group list dynamic`, etc.) and check logs. Audit DUG membership.
• Redistribution: Plan how tags will be shared across firewalls if needed.