Netgate is offering COVID-19 aid for pfSense software users, learn more.
Testing authentication servers is possible using the tool located at Diagnostics > Authentication. From that page, testing a user is simple:
Navigate to Diagnostics > Authentication
Select an Authentication Server
Enter a Username
Enter a Password
Click the Test button.
The firewall will attempt to authenticate the given user against the specified server and will return the result. It is usually best 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 groups are printed in the test results.
If an error is received when testing authentication, double check the credentials and the server settings, then make any necessary adjustments and try again.
If Anonymous binds are not being used, the username supplied can be the short
DOMAIN\User for AD) or a full LDAP specification for a user (e.g.
If the full DN of a Windows AD bind user is unknown, it 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 AS 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 be used to determine what the DN for a given group will be.
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
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 on pfSense® (Status > System Logs) may also contain some detail that hints at a resolution.
Troubleshooting via Packet Captures¶
Packet captures can be invaluable for diagnosing errors as well. If an unencrypted method (RADIUS, LDAP without SSL) 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. For more information on packet captures, see Packet Capturing.