Testing authentication servers is possible using the tool located at Diagnostics > Authentication.
Testing user authentication is a simple process:
Navigate to Diagnostics > Authentication
Select an Authentication Server
Enter a Username
Enter a Password
Click the Test button.
This only performs a basic authentication test. Some special use cases, such as EAP, cannot be tested in this manner and may still fail when this test succeeds.
The firewall will attempt to authenticate the user against the chosen server, then it prints the results. The best practice is to try this at least once before attempting to use the server.
If the server returned a set of groups for the user, and the groups exist locally with the same name, the GUI prints the names of the groups in the test results.
If the firewall receives an error when testing authentication, double check the credentials and the server settings, then make any necessary adjustments and try again.
The Set debug flag option enables additional logging for authentication attempts made from this page. Currently this is only recognized by the LDAP authentication code path.
When debugging is enabled for LDAP authentication, the authentication process will write messages to the main system log with much more detail about the LDAP query and results. This can be a great help for dialing in authentication containers, group membership, and extended query contents. This is especially useful when communicating with an LDAP server over TLS, where a packet capture cannot see those details.
RADIUS Authentication Server Troubleshooting¶
Missing/Incomplete RADIUS Reply Attributes¶
There is a limit to the maximum number of attributes the RADIUS client on pfSense® software can receive.
The radius client library in pfSense software does not support RFC 7499. This
restricts the RADIUS request and response payloads to an upper limit of
bytes. Large lists of attributes, such as numerous ACL entries, will be
truncated to this limit.
LDAP Authentication Server Troubleshooting¶
When troubleshooting LDAP authentication, be sure to check the Debug Option for increased LDAP query and response logging.
When using authenticated (Not anonymous) binds, the username can be the short
DOMAIN\User for AD) or a full LDAP specification for a user (e.g.
The full DN of a Windows AD bind user can be found by navigating to the user in ADSI Edit found under Administrative Tools on the Windows server.
For a production setup, an unprivileged user should be used for binding if possible, and not AD Administrator-level account. Such an unprivileged user may need sufficient permissions to attempt binding as other users and access the LDAP directory.
Another common mistake with group membership is not specifying Entire Subtree for the Search Scope Level.
Active Directory Group Membership¶
Depending on how the Active Directory groups were made, the way they are specified may be different for things like Authentication Containers and/or Extended Query. For example, a traditional user group in AD is exposed differently to LDAP than a separate Organizational Unit.
ADSI Edit found under Administrative Tools on the Windows server can locate the DN for a given group.
The most common mistake with Extended Query is that the given directive fails to include both the item to be searched as well as how, such as:
Note that in the above example the DN of the group is given along with the
For users of RFC2307 groups, such as with OpenLDAP, an extended filter might look more like the following:
Troubleshooting via Server Logs¶
Authentication failures are typically logged by the target server (FreeRADIUS, Windows Event Viewer, etc), assuming the request is making it all the way to the authentication host. Check the server logs for a detailed explanation why a request failed. The system log at Status > System Logs may also contain information that hints at a resolution.
Troubleshooting via Packet Captures¶
Packet captures (Packet Capturing) can be invaluable for diagnosing errors as well. If an unencrypted method (RADIUS, LDAP without SSL/TLS) is in use, the actual password being used may not be visible but enough of the protocol exchange can be seen to determine why a request is failing to complete. This is especially true when a capture is loaded in Wireshark, which can interpret the responses, as seen in Figure Sample LDAP Failure Capture.