10.2 Single Sign-On (SSO) Architecture

10.2 Single Sign-On (SSO) Architecture

Quick Answer: WatchGuard Single Sign-On (SSO) transparently maps corporate domain user accounts to internal workstation IP addresses, allowing the Firebox to enforce user-aware and group-aware security policies without requiring interactive web logins. The architecture consists of the SSO Agent (installed on a domain member server, communicating with the Firebox over TCP port 4116), which aggregates logon intelligence from three optional sources: the endpoint-installed SSO Client (operating over TCP port 4114 for active logoff and fast user switching detection), the agentless Event Log Monitor (ELM) (which queries Domain Controllers for Windows Security Event ID 4624), and the Exchange Monitor (for mobile ActiveSync/OWA devices). For multi-user Remote Desktop / Citrix servers where multiple users share a single IP address, WatchGuard provides the Terminal Services Agent (TS Agent), which solves the multi-user challenge by assigning a unique outbound TCP/UDP port range to each user session.

---

The Purpose & Operational Mechanics of Single Sign-On

While user-based firewall rules offer superior security over IP-based rules, forcing enterprise employees to open a web browser and authenticate to a captive portal every morning creates user friction, administrative helpdesk tickets, and productivity loss. Furthermore, non-interactive background applications (such as automated backup utilities, CRM synchronizers, and system update daemons) cannot complete an interactive web form and would be blocked.

WatchGuard Single Sign-On (SSO) eliminates this friction by operating transparently behind the scenes. When an employee logs into their Windows domain workstation in the morning, their identity, active IP address, and security group memberships are automatically discovered and cached by the Firebox. Subsequent network traffic originating from that workstation is evaluated against firewall rules assigned specifically to that user or their Active Directory groups without any interactive intervention.

+-----------------------------------------------------------------------------------------+
|                        WATCHGUARD SSO ARCHITECTURAL ECOSYSTEM                           |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|       ┌────────────────────────┐                   ┌────────────────────────┐           |
|       │ Active Directory DC    │                   │ Exchange Mail Server   │           |
|       │ (Security Event Logs)  │                   │ (OWA & ActiveSync Logs)│           |
|       └───────────┬────────────┘                   └───────────┬────────────┘           |
|                   │ WMI / Event 4624                           │ IIS / ActiveSync       |
|                   ▼                                            ▼                        |
|       ┌────────────────────────┐                   ┌────────────────────────┐           |
|       │ Event Log Monitor (ELM)│                   │    Exchange Monitor    │           |
|       └───────────┬────────────┘                   └───────────┬────────────┘           |
|                   │ TCP 4116                                   │ TCP 4116               |
|                   └─────────────────────┬──────────────────────┘                        |
|                                         ▼                                               |
|                               ┌───────────────────┐                                     |
|                               │     SSO AGENT     │<────────────┐                       |
|                               │ (Dedicated Member │             │                       |
|                               │      Server)      │             │ TCP 4114              |
|                               └─────────┬─────────┘             │ (Logon/Logoff events) |
|                                         │                       ▼                       |
|                                         │            ┌──────────────────────┐           |
|                                         │ TCP 4116   │      SSO CLIENT      │           |
|                                         │            │ (Windows / macOS PC) │           |
|                                         ▼            └──────────────────────┘           |
|                                   ┌───────────┐                                         |
|                                   │  FIREBOX  │                                         |
|                                   │ APPLIANCE │                                         |
|                                   └───────────┘                                         |
|                             (In-Memory User IP Cache)                                   |
+-----------------------------------------------------------------------------------------+

---

The Core Software Components of WatchGuard SSO

The WatchGuard SSO solution is modular, allowing organizations to select the precise balance between agentless simplicity and granular endpoint reporting.

1. The SSO Agent

The SSO Agent is the central management gateway of the SSO subsystem. Installed on a Windows Server that is a member of the Active Directory domain, it serves as the broker between the Firebox and network identity sources:

• Firebox Communication: Listens on TCP port 4116 for incoming queries from Firebox appliances. When the Firebox encounters an unknown IP address, it asks the SSO Agent to identify the user.
• Direct Probing: If helper monitors are not deployed, the SSO Agent can directly probe the client workstation across the local network using Microsoft Remote Procedure Calls (RPC), NetBIOS, or Windows Management Instrumentation (WMI) to query the active logon session.
• Directory Querying: Once a username is identified, the SSO Agent contacts Active Directory domain controllers via LDAP to resolve the full list of security groups (memberOf) associated with that user account before returning the complete profile to the Firebox.

2. The SSO Client

The SSO Client is a lightweight background service installed directly on end-user Windows or macOS workstations:

• Port Communication: Communicates with the SSO Agent over TCP port 4114.
• Real-Time State Transitions: Unlike polling mechanisms, the SSO Client immediately detects and reports interactive user state changes: user logon, user logoff, screen lock/unlock, and Fast User Switching events.
• Mixed Operating Systems: Crucial for heterogeneous networks containing macOS workstations, which do not generate Windows domain controller security event logs.
• High Reliability: Immune to Windows Firewall blocking of incoming RPC/WMI probes on the workstation, since the client initiates outbound connections to the SSO Agent.

3. Event Log Monitor (ELM)

The Event Log Monitor (ELM) provides an agentless deployment model, completely eliminating the administrative need to install software on end-user workstations:

• Log Parsing: ELM is installed on a domain server and continuously reads the Windows Security Event Log across one or more Domain Controllers.
• Targeted Event IDs: It monitors for Event ID 4624 (Successful Logon) and examines logon types (Type 2 = Interactive console, Type 7 = Unlock workstation, Type 10 = Remote Interactive / RDP).
• Correlation: ELM extracts the user account name, domain, and client source IP address from the event payload and transmits this mapping to the SSO Agent over TCP port 4116.
• Scalability in Multi-DC Environments: In distributed enterprise networks with dozens of domain controllers, multiple ELM instances can be deployed regionally to monitor local DCs and forward telemetry to the central SSO Agent.

4. Exchange Monitor

The Exchange Monitor targets mobile devices, smartphones, and tablets that connect to corporate messaging infrastructure:

• Installation: Installed directly on Microsoft Exchange Servers running the Client Access Server (CAS) role.
• Telemetry: Scans Microsoft Exchange Internet Information Services (IIS) logs and ActiveSync / Outlook Web App (OWA) transaction records.
• Mobile Mapping: When an iPhone or Android device connects to corporate email via ActiveSync over the office Wi-Fi network, Exchange Monitor associates the device's internal Wi-Fi IP address with the user's domain identity and passes the mapping to the SSO Agent.

---

Firebox SSO Query Lifecycle & In-Memory IP Cache Management

To achieve wire-speed firewall throughput, the Firebox does not query external authentication servers for every individual network packet. Instead, it maintains an In-Memory IP-to-User Mapping Cache in the Fireware OS kernel.

+-----------------------------------------------------------------------------------------+
|                        FIREBOX SSO QUERY & CACHE LIFECYCLE                              |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   1. Workstation (10.0.1.55) sends TCP SYN to Internet (e.g., Salesforce CRM:443)       |
|             │                                                                           |
|             ▼                                                                           |
|   2. Firebox inspects packet. Checks in-memory SSO Cache for 10.0.1.55.                 |
|      • Cache Status: MISS (IP not recognized)                                           |
|             │                                                                           |
|             ▼                                                                           |
|   3. Firebox sends asynchronous query to SSO Agent (TCP Port 4116):                     |
|      "Who is currently logged into IP 10.0.1.55?"                                       |
|             │                                                                           |
|             ▼                                                                           |
|   4. SSO Agent checks ELM / queries SSO Client (TCP 4114) / queries AD:                 |
|      "User is CORP\jdoe; Groups: Engineering, RemoteUsers"                              |
|             │                                                                           |
|             ▼                                                                           |
|   5. SSO Agent replies to Firebox on TCP 4116 with identity record                      |
|             │                                                                           |
|             ▼                                                                           |
|   6. Firebox updates in-memory SSO cache:                                               |
|      [10.0.1.55 = CORP\jdoe | Groups: Engineering | TTL: 480 min | Idle: 0]             |
|             │                                                                           |
|             ▼                                                                           |
|   7. Packet re-evaluated against User-Aware firewall policies:                          |
|      • Policy 'Engineering-HTTPS' matches CORP\jdoe -> PACKET PERMITTED                 |
+-----------------------------------------------------------------------------------------+

The Lifecycle Stages

1. Unidentified Traffic Arrival: A workstation with IP 10.0.1.55 attempts an outbound connection to an external cloud application. The connection matches a firewall policy that requires user or group authentication in the From list.
2. Cache Lookup: Fireware scans its active kernel table. If an active, non-expired entry exists for 10.0.1.55, the connection is immediately matched against the user's permitted rules with zero latency.
3. Asynchronous Query Execution: If the IP is absent from the cache, the Firebox dispatches an asynchronous query over TCP 4116 to the primary SSO Agent. Meanwhile, depending on configuration, the initial packet is held momentarily or evaluated against fallback unauthenticated rules.
4. Identity Resolution: The SSO Agent resolves the identity using its active query pipeline (checking ELM cache, pinging the SSO Client on port 4114, or performing an RPC probe to the client).
5. Cache Insertion & Timer Initialization: Upon receiving the confirmation payload from the SSO Agent, Fireware writes the entry into the in-memory cache and initializes two independent counters:
   • Inactivity Timeout: Tracks silent periods where no packets traverse the Firebox from that IP (default: 20 minutes).
   • Session Expiration Limit: Hard ceiling capping the maximum lifetime of an authenticated session before re-validation is enforced (default: 8 hours).

---

Troubleshooting SSO: Stale Entries & The Multi-User Problem

In enterprise operations, SSO failures typically manifest as incorrect policy enforcement, unauthorized access, or sudden session terminations. Diagnosing SSO requires understanding its technical edge cases.

1. DHCP IP Churn and Stale Cache Entries

In high-turnover dynamic networks (such as laptop environments with short DHCP lease times), an IP address vacated by User A (e.g., an executive) may be rapidly reassigned by the DHCP server to User B (e.g., a contractor).

• The Risk: If User A shuts down their laptop without an explicit domain logoff, the Firebox SSO cache may continue associating the IP with User A until the inactivity or session timer expires. User B would temporarily inherit User A's elevated access rights.
• Remediation:
  • Deploy the SSO Client on all corporate endpoints. The SSO Client immediately signals a logoff event to the SSO Agent on shutdown or sleep.
  • Shorten the Session Inactivity Timeout in Fireware Authentication Settings.
  • Ensure DHCP lease times are properly aligned with typical workday durations (e.g., 8 hours or longer).

2. Multi-User Workstations & Fast User Switching

When multiple employees share a physical desktop computer (such as a nurse's station in a hospital or a factory floor terminal), Windows allows multiple concurrent logged-in sessions via Fast User Switching:

• The Failure Mode: Agentless ELM sees Event ID 4624 for both users on the exact same IP address. The last user to log on overwrites the previous mapping in the SSO Agent, causing the firewall to misidentify traffic generated by the original user.
• Remediation: For shared physical workstations, deploy the SSO Client, which can track active foreground console sessions, or exempt shared kiosks from SSO and enforce explicit captive portal authentication.

3. Remote Desktop Services / Citrix: The Terminal Services Agent (TS Agent)

The most severe architectural challenge to standard SSO occurs in Remote Desktop Services (RDS), Microsoft Windows Multi-Session, and Citrix Virtual Apps environments. On an RDS Session Host, 50 or 100 distinct users log in simultaneously, each running independent web browsers, email clients, and corporate tools—all sharing a single physical network interface and a single IP address.

+-----------------------------------------------------------------------------------------+
|                   TERMINAL SERVICES AGENT (TS AGENT) PORT MULTIPLEXING                  |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   RDS Session Host (Single IP: 10.0.2.100)                                              |
|   ┌─────────────────────────────────────────────────────────────────────────────────┐   |
|   │ WatchGuard Terminal Services Agent (TS Agent) Kernel Filter Driver              │   |
|   │                                                                                 │   |
|   │  User Session: 'alice' (Finance)      ──> Outbound Source Ports: 20000 - 20999  │   |
|   │  User Session: 'bob'   (Engineering)  ──> Outbound Source Ports: 21000 - 21999  │   |
|   │  User Session: 'carol' (Marketing)    ──> Outbound Source Ports: 22000 - 22999  │   |
|   └────────────────────────────────────────┬────────────────────────────────────────┘   |
|                                            │                                            |
|                                            ▼                                            |
|   Traffic Streams Arrive at Firebox from 10.0.2.100:                                    |
|   • Packet: 10.0.2.100:20412 ──> Matched to 'alice' (Finance Policy Applied)            |
|   • Packet: 10.0.2.100:21105 ──> Matched to 'bob'   (Engineering Policy Applied)        |
|   • Packet: 10.0.2.100:22850 ──> Matched to 'carol' (Marketing Policy Applied)          |
+-----------------------------------------------------------------------------------------+

Standard IP-based SSO cannot distinguish between Alice and Bob on an RDS host. WatchGuard overcomes this with the Terminal Services Agent (TS Agent):

• Installation: Installed directly on the Windows Remote Desktop Session Host server.
• Port Allocation Architecture: The TS Agent intercepts network socket creation at the OS transport layer. It assigns a unique, non-overlapping block of outbound source TCP and UDP ports (e.g., 1,000 ports per user) to each active user session.
• Firebox Synchronization: The TS Agent transmits its active port-allocation tables directly to the Firebox.
• Firebox Inspection: When an outbound packet arrives from the RDS host's IP (10.0.2.100), the Firebox inspects both the source IP address and the source port number. If the source port is 20412, Fireware maps the packet to Alice; if the source port is 21105, it maps the packet to Bob. This delivers completely isolated, user-aware firewall policy enforcement on a multi-user server.

---

Technical Comparison: WatchGuard SSO Deployment Methods

The following table compares the operational requirements and architectural characteristics of the different WatchGuard SSO components: