10.1 Authentication Servers & Directory Integration

10.1 Authentication Servers & Directory Integration

Quick Answer: Fireware OS supports multiple authentication server types: the local Firebox-DB database (featuring configurable password complexity and lockout thresholds), external Active Directory / LDAP servers, and RADIUS servers. Active Directory integration uses standard LDAP over TCP 389 or Secure LDAPS over TCP 636 (which requires importing the directory root CA into Fireware). RADIUS operates over UDP 1812 (authentication) and UDP 1813 (accounting) using a shared secret. When a user authenticates with an unqualified username (e.g., jdoe without @domain), the Firebox routes the request exclusively to the designated Default Authentication Server. If the default server responds with an authentication failure (reject), the Firebox halts and denies access—it never falls back across different authentication domains for an unqualified credential.

---

Authentication Architecture in Fireware OS

Traditional stateful packet inspection firewalls regulate network communications based strictly on Layer 3 and Layer 4 attributes: source IP address, destination IP address, protocol, and port numbers. In modern enterprise infrastructures, network endpoints are dynamic. Dynamic Host Configuration Protocol (DHCP) leases churn constantly, mobile devices migrate across wireless access points, and remote workers connect from changing home subnets. Relying strictly on IP addresses creates fragile security policies that either fail to protect sensitive resources or inadvertently grant excessive access to unauthorized users.

Fireware OS bridges this architectural gap by implementing User-Aware and Identity-Based Security. By binding network connections to authenticated user identities rather than static IP addresses, administrators can craft granular firewall rules based on corporate roles, department memberships, and security groups.

+-----------------------------------------------------------------------------------------+
|                         FIREWARE OS AUTHENTICATION ENGINE                               |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   Connection Request (Source IP: 10.0.1.45)                                             |
|         │                                                                               |
|         ▼                                                                               |
|   ┌─────────────────────────────────────────────────────────────────────────────────┐   |
|   │ 1. In-Memory Authenticated Users Table Check (IP-to-User Session Mapping)        │   |
|   └────────────────────────────────────────┬────────────────────────────────────────┘   |
|                                            │                                            |
|             ┌──────────────────────────────┴──────────────────────────────┐             |
|             ▼                                                             ▼             |
|     [ User Not Found ]                                            [ User Found ]        |
|             │                                                             │             |
|             ▼                                                             ▼             |
|   ┌───────────────────────────┐                                 ┌───────────────────┐   |
|   │ Trigger Authentication:   │                                 │ Match User/Group  │   |
|   │ • Single Sign-On (SSO)    │                                 │ against Firewall  │   |
|   │ • Captive Portal (Pt 4100)│                                 │ Policy 'From' List│   |
|   │ • Mobile VPN Negotiation  │                                 └───────────────────┘   |
|   └─────────────┬─────────────┘                                                         |
|                 │                                                                       |
|                 ▼                                                                       |
|   ┌─────────────────────────────────────────────────────────────────────────────────┐   |
|   │ 2. Query External / Internal Authentication Domain                               │   |
|   │    (Firebox-DB, Active Directory, LDAP, RADIUS, AuthPoint)                      │   |
|   └────────────────────────────────────────┬────────────────────────────────────────┘   |
|                                            │                                            |
|                                            ▼                                            |
|   ┌─────────────────────────────────────────────────────────────────────────────────┐   |
|   │ 3. Populate In-Memory User Table with Username, Domain, IP, and Group Memberships│   |
|   └─────────────────────────────────────────────────────────────────────────────────┘   |
+-----------------------------------------------------------------------------------------+

When a user authenticates, Fireware maintains an active session record in its in-memory Authenticated Users table. Each entry binds the client's source IP address to a specific username, authentication server domain, group membership list, idle timer, and maximum session expiration counter.

---

Firebox-DB: Local Database, Security Policies & Account Lockout

Firebox-DB is the native, on-box authentication database hosted directly within the encrypted flash filesystem of the Firebox appliance. It is completely independent of external network infrastructure and operates even during total WAN or directory server outages.

Administrative vs. End-User Authentication

It is vital to distinguish between administrative credentials and Firebox-DB end-user accounts:

• Device Management Passphrases: The default status (read-only monitoring) and admin (read-write configuration) passphrases govern direct administrative login to Firebox System Manager (FSM), Policy Manager, the Web UI, and Command Line Interface (CLI).
• Role-Based Administration (RBA): Fireware allows administrators to create granular management accounts assigned predefined administrative roles (such as Device Administrator, Device Monitor, Guest Administrator, and Logs and Reports).
• Firebox-DB End Users and Groups: Defined under Setup > Authentication > Authentication Servers > Firebox-DB. These accounts do not possess administrative rights to modify firewall settings; instead, they are used to authenticate human users accessing the web through the captive portal, connecting via Mobile VPN (SSL, IKEv2, L2TP), or accessing protected internal resources.

+-----------------------------------------------------------------------------------------+
|                           FIREBOX-DB SECURITY PARAMETERS                                |
+---------------------------------------------+-------------------------------------------+
| PARAMETER                                   | OPERATIONAL BEHAVIOR                      |
+---------------------------------------------+-------------------------------------------+
| Minimum Password Length                     | Configurable from 8 to 32 characters      |
| Complexity Requirements                     | Uppercase, lowercase, digits, and symbols |
| Password Expiration Interval                | Configurable lifetime in days (e.g., 90)  |
| Password History Enforcement                | Prevents reuse of previous N passwords    |
| Account Lockout Threshold                   | Locks account after X failed attempts     |
| Lockout Duration                            | Unlocks after Y minutes or manual reset   |
+---------------------------------------------+-------------------------------------------+

Password Complexity & Brute-Force Lockout Rules

To meet regulatory compliance standards (such as PCI-DSS and HIPAA), Fireware allows security administrators to enforce strict password and account lockout parameters for Firebox-DB accounts:

• Password Length and Composition: Administrators can mandate a minimum password length (recommended 12+ characters) and require at least three of the four standard character sets: uppercase letters, lowercase letters, numbers, and non-alphanumeric special characters.
• Password Expiration & History: Forces users to change passwords every 30 to 90 days, while retaining a history buffer (e.g., last 5 passwords) to prevent cyclic password reuse.
• Account Lockout Threshold: To thwart automated dictionary and brute-force password-guessing attacks against the authentication portal or VPN endpoints, Fireware can automatically lock an account after a specified number of consecutive failed authentication attempts (typically 3 to 5 attempts).
• Lockout Reset Mechanics: Once locked, the account can be set to unlock automatically after a cooling-off period (e.g., 30 minutes) or remain locked indefinitely until an administrator manually clears the lockout status in Firebox System Manager (Status Center > Authentication List).

---

Active Directory & LDAP Integration

For enterprise environments, managing independent credentials across firewalls and workstations introduces severe administrative overhead. Integrating the Firebox with Microsoft Active Directory Domain Services (AD DS) or generic Lightweight Directory Access Protocol (LDAP) directories centralizes identity lifecycle management, password enforcement, and role offboarding.

+-----------------------------------------------------------------------------------------+
|                    FIREBOX ACTIVE DIRECTORY / LDAP INTEGRATION                          |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|     Firebox                                      Active Directory Domain Controller     |
|   ┌─────────┐                                              ┌─────────┐                  |
|   │         │ 1. Bind Request (Search User DN + Password)  │         │                  |
|   │         ├─────────────────────────────────────────────>│         │                  |
|   │         │ 2. Bind Acknowledged (LDAP Session Open)     │         │                  |
|   │         │<─────────────────────────────────────────────┤         │                  |
|   │         │ 3. Search Request: (sAMAccountName=jdoe)     │         │                  |
|   │         ├─────────────────────────────────────────────>│         │                  |
|   │         │ 4. Search Result: User Object + DN + memberOf│         │                  |
|   │         │<─────────────────────────────────────────────┤         │                  |
|   │         │ 5. Re-bind / Auth Query with User Password   │         │                  |
|   │         ├─────────────────────────────────────────────>│         │                  |
|   │         │ 6. Access Granted / Kerberos Ticket Result   │         │                  |
|   │         │<─────────────────────────────────────────────┤         │                  |
|   └─────────┘                                              └─────────┘                  |
|      Fireware OS                                          Windows Server                |
+-----------------------------------------------------------------------------------------+

Directory Configuration Parameters

When configuring an Active Directory or LDAP authentication server in Fireware (Setup > Authentication > Authentication Servers > Active Directory), the following core parameters are established:

1. Primary & Backup Server IP/FQDN: The IP address or Fully Qualified Domain Name of the Primary Domain Controller (DC) and a redundant secondary DC to ensure continuous service availability.
2. Directory Ports (Plain LDAP vs. LDAPS):
   • Standard LDAP (TCP 389): Authentication queries and password data traverse the network unencrypted unless explicitly negotiated over StartTLS. Microsoft Active Directory default security baselines increasingly disable or flag plain LDAP binds due to exposure of plaintext credentials.
   • Secure LDAP / LDAPS (TCP 636): Encrypts the entire query and authentication transaction inside a TLS tunnel. To establish LDAPS, the Firebox must trust the Active Directory server's TLS certificate. The administrator must export the issuing Active Directory Certificate Services (AD CS) Root Certificate Authority (CA) certificate and import it into the Firebox under System > Certificates as an IPSec, Web Server, Security Services or General CA certificate.
3. Searching the Directory (Search Base DN):
   • The Search Base defines the Distinguished Name (DN) of the container or Organizational Unit (OU) where the Firebox initiates searches for user objects (e.g., OU=Corporate Users,DC=ad,DC=example,DC=com).
   • Setting the Search Base too broad (e.g., root DC=example,DC=com) in a large enterprise with hundreds of thousands of objects can lead to query timeouts. Setting it too narrow risks excluding legitimate users residing in sister OUs.
4. Searching Attribute (Search User Bind DN):
   • Active Directory generally disallows anonymous LDAP binds. The Firebox must be provisioned with a dedicated Service Account distinguished name (e.g., CN=svc-firebox,OU=Service Accounts,DC=ad,DC=example,DC=com) and static password to bind to AD and search for users.
5. User and Group Attributes:
   • User Attribute: Fireware queries sAMAccountName (standard pre-Windows 2000 logon name, e.g., jdoe) or userPrincipalName (UPN, e.g., jdoe@example.com).
   • Group Attribute: Active Directory returns group memberships within the multi-valued memberOf attribute. Fireware evaluates this list against its locally defined group policies to authorize access.

---

RADIUS Authentication & Network Policy Server (NPS)

Remote Authentication Dial-In User Service (RADIUS) is an industry-standard client/server protocol (RFC 2865, RFC 2866) widely leveraged to centralize network access authentication, authorization, and accounting. Firebox appliances frequently integrate with RADIUS servers such as Microsoft Network Policy Server (NPS), Cisco Identity Services Engine (ISE), FreeRADIUS, and two-factor authentication appliances.

+-----------------------------------------------------------------------------------------+
|                        RADIUS PROTOCOL ARCHITECTURE & PORTS                             |
+---------------------------------------------+-------------------------------------------+
| FUNCTION                                    | PORT NUMBERS                              |
+---------------------------------------------+-------------------------------------------+
| Authentication & Authorization (Modern RFC) | UDP Port 1812                             |
| Accounting (Modern RFC)                     | UDP Port 1813                             |
| Authentication (Legacy Pre-RFC)             | UDP Port 1645                             |
| Accounting (Legacy Pre-RFC)                 | UDP Port 1646                             |
+---------------------------------------------+-------------------------------------------+

RADIUS Mechanics & Attributes

• Client/Server Relationship: The Firebox acts as the RADIUS Client (Network Access Server / NAS), while the target server (e.g., Windows NPS) acts as the RADIUS Server. In the RADIUS server configuration, the Firebox interface IP must be explicitly declared as an authorized RADIUS Client.
• Shared Secret: A shared cryptographic string configured identically on both the Firebox and the RADIUS server. It is used to authenticate transactions and obfuscate user passwords using HMAC-MD5 hashing during transmission over UDP.
• Authentication Protocols: The Firebox supports multiple inner authentication mechanisms depending on the service, including Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and MS-CHAPv2. When integrating with Active Directory via Microsoft NPS, MS-CHAPv2 is required for secure authentication without transmitting reversible passwords.
• Group Authorization via RADIUS Attributes: Because RADIUS does not expose a native directory tree like LDAP, group authorization relies on returning specific attributes in the Access-Accept packet. Administrators configure Network Policy Server (NPS) Connection Request and Network Policies to return RADIUS Attribute 25 (Class) or vendor-specific attributes (VSAs). The Firebox reads the Class attribute value (e.g., VPN-Admins) and matches it against local Fireware group definitions to enforce user-specific firewall policies.
• RADIUS Accounting: Over UDP port 1813, the Firebox transmits Accounting-Start, Interim-Update, and Accounting-Stop packets to the RADIUS server. This stream records connection start times, total elapsed session duration, IP addresses assigned to VPN clients, and aggregate byte counts transferred, creating an unalterable compliance audit trail.

---

Authentication Server Search Order & Domain Fallback Behavior

An enterprise Firebox can have multiple authentication domains configured simultaneously—for example, local Firebox-DB, a corporate Active Directory domain (ad.example.com), an engineering LDAP server (ldap.dev.local), and a cloud RADIUS server for multi-factor authentication.

+-----------------------------------------------------------------------------------------+
|                   FIREWARE AUTHENTICATION SERVER SEARCH LOGIC                           |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   User Submits Credentials                                                              |
|             │                                                                           |
|             ▼                                                                           |
|   Is Domain Specified? (e.g., 'CORP\jdoe' or selected from portal dropdown)            |
|             │                                                                           |
|      ┌──────┴───────────────────────────────────────┐                                   |
|      ▼                                              ▼                                   |
|   [ YES: Explicit Domain ]                       [ NO: Unqualified Username ]           |
|      │                                              │                                   |
|      ▼                                              ▼                                   |
|   Query Specified Server                         Query Configured DEFAULT SERVER        |
|      │                                              │                                   |
|      ▼                                              ▼                                   |
|   Server Reachable?                              Server Reachable?                      |
|      ├── NO (Timeout) ──> Query Backup DC           ├── NO (Timeout) ──> Query Backup DC|
|      │                                              │                                   |
|      └── YES                                        └── YES                             |
|           │                                              │                              |
|           ▼                                              ▼                              |
|   Directory Response                             Directory Response                     |
|      ├── Success ──> LOGON PERMITTED                ├── Success ──> LOGON PERMITTED     |
|      │                                              │                                   |
|      └── REJECT (Wrong Password)                    └── REJECT (Wrong Password)         |
|           │                                              │                              |
|           ▼                                              ▼                              |
|       ACCESS DENIED                                  ACCESS DENIED                      |
|   (No fallback to other servers)                 (STOPS IMMEDIATELY; NO FALLBACK!)      |
+-----------------------------------------------------------------------------------------+

The Default Authentication Server

Under Setup > Authentication > Authentication Servers, administrators designate one authentication domain as the Default Authentication Server.

• If an end user logs in using an unqualified username (such as entering asmith without prepending DOMAIN\ or appending @domain.com), Fireware sends the authentication request exclusively to the Default Authentication Server.
• If the user belongs to any secondary domain, they must explicitly specify their domain by selecting it from the drop-down menu on the authentication portal or typing their fully qualified username (e.g., asmith@ad.example.com or Firebox-DB\asmith).

Server Fallback vs. Rejection Rules

A fundamental concept tested on the WatchGuard certification exam is the behavioral difference between an unreachable server (timeout) and an invalid credential (reject):

1. Server Timeout (Unreachable): If the Primary server defined within an authentication domain fails to respond within the configured timeout window (due to a network outage, server crash, or unreachable routing path), Fireware automatically fails over to the configured Secondary (Backup) server within that same domain.
2. Directory Reject (Authentication Failure): If the authentication server is online and responds with an explicit authentication denial (such as an LDAP Invalid Credentials response, Windows Event 4625 bad password, or RADIUS Access-Reject), Fireware immediately terminates the authentication process and denies access.
3. The Cross-Domain Rule: Fireware NEVER falls back to a different authentication domain if the primary domain rejects the credentials. If an unqualified user enters a username that does not exist on the Default Authentication Server, the default server rejects the user, and Fireware drops the session. It does not test the credentials against Firebox-DB or secondary RADIUS servers. This strict containment prevents credential leakage, brute-force exploitation across domains, and severe authentication latency.

---

Technical Comparison: Authentication Server Mechanisms

The following table compares the operational parameters and deployment considerations for Firebox-supported authentication methods: