Troubleshooting LDAP Authentication

If trouble is encountered getting a connection to an LDAP server, there are several things to check. Most of the time it is trouble-free, but in particular, LDAP with SSL can be tricky.

Bind Credentials

If Anonymous binds are not being used, the username supplied can be the short name (e.g. DOMAIN\User for AD) or a full LDAP specification for a user (e.g. CN=administrator,CN=Users,DC=example,DC=com).

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.

Extended Query

Ensure a directive is used that includes what should be searched as well as how, such as:


Debugging LDAP

If the hostname and CA certificate are believed to be correct, LDAP can be debugged by applying the following patch (2.1 only) using the System Patches package:

Path Strip: 1
Base: /
Ignore Whitespace: Checked

Once applied, from the console or ssh, run option 11 to restart the WebGUI. The patch enables some debug logging for LDAP and also tells lighttpd to write the error log for the debug messages. Once the GUI has restarted, try the LDAP query again, and then check /var/log/lighttpd-breakage.log which should have sufficient detail to track down the cause of the problem. If assistance is needed with decoding the output, post in the Netgate Forum or pfSense subreddit for help or seek assistance from Netgate Global Support.

Group Membership

Group membership can be tricky with LDAP due to the various ways in which the LDAP schema can vary. It may be that the LDAP sever requires the RFC 2307 option to be active, or inactive, or the attributes of the group membership could be different. Consult your LDAP server documentation and schema to confirm how group membership must be checked.

For pfSense to see a group from LDAP, a local group must exist on pfSense with an identical name to the group on the LDAP server.