pfSense Lab Part 4: Captive Portal with AD

This lab series guides you from the initial deployment of pfSense. Then, it progresses to advanced configurations. It provides a structured, step-by-step journey through every major feature. If you missed any of the other parts, they are linked below. This way, you can catch up and get the most from the full lab experience.

As a reminder, here’s the architecture below we’re working with.

Why a Captive Portal is Essential

A Captive Portal feature in pfSense is vital for modern networks, especially in environments where controlling and securing network access is critical. Its importance can be summarized as follows:

Enhanced Security and Access Control: It ensures that only authorized users can access the internet or internal resources by requiring authentication before granting connection privileges. This prevents unauthorized use or abuse of network bandwidth.
Accountability and Monitoring: It allows administrators to track user activity, manage bandwidth, and enforce policies, ensuring compliance with organizational or legal standards.
User Management and Billing: In commercial settings such as hotels, cafes, airports, or conference centers, it supports user registration, voucher systems, or social media logins, providing flexibility in user access management.
Legal and Terms Enforcement: It provides an interface to display terms and conditions that users must accept, which is particularly important for legal compliance in public networks or hospitality industries.

By integrating a captive portal, organizations can enhance network security, maintain oversight, and improve user experience, which makes this feature indispensable in a variety of network setups.

What Is pfSense’s Captive Portal?

pfSense’s captive portal is a feature that intercepts clients’ HTTP/HTTPS requests, redirecting them to a login or acceptance page before granting full network access. It’s primarily used in:

Public Wi-Fi: Airports, cafes, hotels, and restaurants use it to authenticate users.
Enterprise Environments: To add an extra layer of security and manage guest or employee access.
Home Networks: For advanced parental controls or visitor networks.

The captive portal can be configured with various authentication methods such as local user accounts, vouchers, RADIUS, or social media logins, providing flexible access controls.

Implementation

When setting up a captive portal in pfSense, the first step is to create a zone. Captive portal zones define separate portals for different sets of interfaces. For example, LAN and wireless networks might use one portal, while a conference room could have a different one. Each zone has its own settings for authentication, allowed IP addresses, and portal appearance.

A zone can include multiple interfaces, but an individual interface can only belong to one zone. Attempting to assign the same interface to multiple zones will result in an error. Zones are created and managed under Services > Captive Portal in the pfSense interface, where you can add, edit, or delete them as needed. After creating a zone, you can configure its specific parameters like authentication methods, connection limits, and timeout settings. This separation allows precise control over network access for different parts of your network.

Maximum simultaneous connections: Specifies the maximum number of simultaneous connections to the portal web server per IP address.
Idle timeout: The timeout period, specified in minutes, after which inactive users will be disconnected by the portal. Users can reconnect immediately afterwards.
Hard timeout: A timeout period, specified in minutes, after which the portal will forcibly disconnect users regardless of activity.
Pass-Through credits: These credits give devices a grace period before they must authenticate through the portal. For example, a device may connect three times in a day without seeing the portal page, but no more than this before it must log in.
MAC address pass-through credits: The number of times a specific MAC address can connect through the portal.
Simultaneous user connections: Controls whether users are allowed to log in multiple times concurrently.
Per-user bandwidth restrictions: The captive portal can also limit the bandwidth for users to prevent excessive usage.

These settings help control user access, ensure fair usage, and secure the network by managing session duration and bandwidth effectively.

Securing the Captive Portal

Securing the captive portal involves enabling HTTPS so that all communication between users and the portal login page is encrypted. When HTTPS is enabled, the portal listens for and accepts HTTPS requests for its web page, which requires an SSL/TLS certificate. The HTTPS server name must match the Common Name (CN) in the SSL certificate to avoid certificate errors experienced by users.

You must select the SSL certificate that the portal uses for HTTPS connections. There is also an option called “Disable HTTPS Forwards,” which, when enabled, prevents clients from being redirected to the portal when accessing HTTPS sites on port 443. This avoids invalid certificate errors for users. Instead, users must attempt to visit an HTTP site first, which will then redirect them to the captive portal.

Using a trusted certificate authority (CA) is critical to secure the portal properly. A self-signed certificate leaves you without the support of a recognized CA and lacks the latest cryptographic methods needed to ensure proper authentication and encryption of data, devices, and applications. The use of trusted certificates ensures users know they are securely communicating with the legitimate portal and protects their data during authentication.

After successfully creating a certificate authority (CA) in pfSense, you can create certificates signed by this self-created CA. This process allows you to generate SSL/TLS certificates for your pfSense services, including securing the captive portal with HTTPS. These certificates authenticate your pfSense server and encrypt traffic to prevent eavesdropping.

In pfSense, you typically do this through the Certificate Manager under System > Certificate Manager. First, create the CA by specifying details such as the name, key length (2048 bits or higher is recommended), and lifetime. Once the CA is created, you can add new certificates signed by this CA, configuring them as server certificates for services like the captive portal. Using your own CA and certificates ensures secure authentication within your network, although external users will only trust the portal if you use a certificate from a recognized public CA.

The Captive Portal Authentication

The captive portal authentication section configures how users authenticate before gaining network access. If authentication is required for the zone, pfSense supports using the local user database, RADIUS, or LDAP for authentication.

In this case, LDAP (Lightweight Directory Access Protocol) was chosen. LDAP is an open, cross-platform protocol widely used for directory service authentication. It enables applications to communicate securely with directory servers, centralizing user credentials and access control.

Using LDAP offers better control over user management by centralizing data, which is especially useful in organizations with complex access needs. Centralized authentication helps ensure consistent policies across multiple network services and reduces challenges related to handling different types of user credentials or documents. This method also simplifies administration and enhances security by integrating with existing directory systems.

Creation of UO in our AD

Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. It stores information about objects on the network such as users, groups, computers, and organizational units (OUs). AD is essential for managing identities and access permissions across a network.

An Organizational Unit (OU) is a container within AD that can hold users, groups, computers, and even other OUs. It is the smallest administrative unit to which group policies or account permissions can be applied, allowing for delegated administration and better organization of network resources.

Creating an OU is a fundamental task in managing Active Directory. It helps segment and organize resources logically, often by department, location, or function, facilitating easier management and policy application.

To create an OU in Active Directory:

Open the Active Directory Users and Computers console from a domain controller or a machine with administrative tools installed.
Navigate to the domain or the parent container where you want the OU.
Right-click the container, select “New,” then “Organizational Unit.”
Enter a name for the OU that represents its purpose, such as a department or location.
Optionally, set additional settings like protecting the OU from accidental deletion.
Click OK to create the OU.

Once created, you can add users, groups, computers, and apply Group Policy Objects (GPOs) specifically to that OU for centralized management. OUs enable structured delegation of administrative rights and precise control over resources in the Active Directory environment.

Creating authorized users to access the captive portal service on the firewall involves adding user accounts with specific credentials that the portal will recognize for authentication.

When configuring authentication servers in pfSense to integrate with Active Directory (AD), you must add your AD server details carefully. Start by providing the IP address and the port used by your AD server, typically port 389 for LDAP.

Next, you need to specify the distinguished name (DN), which uniquely identifies the entry within the AD directory hierarchy. The DN is crucial for directing queries to the correct part of the directory.

To find the DN, you can use PowerShell, a Microsoft task automation and configuration management tool, on a Windows machine connected to the AD. Using the PowerShell command Get-ADUser, you can retrieve user details including their DN. This aids in accurately configuring your pfSense LDAP authentication server.

Once you have the IP, port, and DN, you input these in pfSense under System > User Manager > Authentication Servers. This setup enables pfSense to authenticate users against your AD, centralizing user management and improving authentication security.

Active Directory Connectivity Test

pfSense provides a feature to test connectivity to your added authentication servers like Active Directory (AD). This helps verify that pfSense can successfully communicate with the AD server before relying on it for authentication.

To test connectivity, you input a username and password from the users defined in your AD or within the organizational unit (OU) you created for pfSense access. If pfSense successfully authenticates this user against the AD server, it confirms the connection is working.

Captive Portal Authentication

The final step in setting up your pfSense captive portal with Active Directory authentication is to test the authentication process. When users are redirected and connected to the network through the captive portal, they should be able to successfully authenticate using their AD credentials via LDAP.

This means that after entering their username and password on the portal login page, pfSense will verify the credentials against the Active Directory server. A successful login confirms that your captive portal is properly integrated with your AD for user authentication, providing secure and centralized access control for your network.

Conclusion

The pfSense captive portal offers a robust solution for controlling and securing network access through user authentication. By integrating with Active Directory using LDAP, organizations can centralize authentication management, streamline user access, and enhance security policies.

The captive portal supports various customization options including connection limits, bandwidth controls, and HTTPS security, ensuring both flexibility and safety. Testing authentication connectivity and verifying user access are critical final steps to ensure seamless integration and a smooth user experience. Deploying such a system in your network environment provides an effective way to manage guest access while protecting internal resources.

Amatoch