Bug #15060
open
LDAP bind fails when authentication servers use different CA chains
0%
Description
The goal is to have 2 separate ldap databases, one for GUI/System authentication and one for OpenVPN authentication: ldap databases differ, bind user credentials differ and ldap servers hostname differ (as well as their SSL certificates).
Steps to reproduce the issue:
- deploy a fresh pfSense+ as AWS AMI (AMI ID: ami-0e1a56989ef6d9eb2, AMI Name: pfSense-plus-ec2-23.09-RELEASE-amd64 23-d6a66a49-ceec-4a27-ad5b-ea8a3eb55b15)
- configure Authentication Server #1 (Active Directory in my case) with ldap bind user #1
- Authentication Server #1 configuration successfully tested with Diagnostic > Authentication configure Authentication Server #2 (Okta LDAP Interface in my case) with ldap bind user #2
- Authentication Server #2 configuration successfully tested with Diagnostic > Authentication testing again Authentication Server #1 with Diagnostic > Authentication will fail with error "Could not bind to LDAP server Authentication Server #1" delete Authentication Server #2
- testing again Authentication Server #1 with Diagnostic -> Authentication will succeed
The issue is reboot resistant.
Updated by Giovanni Vecchi 5 months ago
As per Support reply to my #2138801585 ticket: "Unfortunately, what you are seeing is a limitation of the underlying PHP LDAP library and we in TAC are going to be unable to provide a solution for you at this time.
Monitoring the redmine you created will be the best path forward to see any work being done to correct this issue."
Updated by Ph. T 4 months ago
I have a similar problem. If you use one server and another with the same CA-Chain you do not have a problem.
If you use several LDAP/ADS-Servers for authentification and these have different CA-Chains the bind fails
(it seems it is the bind of the last server which persists).
The bug also exists in pfsense CE. The sorce of the bug is a problem with the handling of Certificate-Chains.
You might try the following:
/etc/inc/auth.inc (Line 1076)
ldap_set_option($ldap, LDAP_OPT_X_TLS_REQUIRE_CERT, LDAP_OPT_X_TLS_HARD);
ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR, $cert_path);
ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, $cert_filename);should be
ldap_set_option($ldap, LDAP_OPT_X_TLS_REQUIRE_CERT, LDAP_OPT_X_TLS_HARD);
ldap_set_option($ldap, LDAP_OPT_X_TLS_CACERTDIR, $cert_path);
ldap_set_option($ldap, LDAP_OPT_X_TLS_CACERTFILE, $cert_filename);
It seems, that this solves the problem wiht different chains for different Servers.
Updated by Marcos M 4 months ago
- Project changed from pfSense Plus to pfSense
- Subject changed from LDAP Bind failed if multiple Authentication Servers are configured with different bind users and different ldap servers to LDAP bind fails when authentication servers use different CA chains
- Category changed from User Manager / Privileges to User Manager / Privileges
- Status changed from New to Ready To Test
- Priority changed from Very High to Normal
- Affected Plus Version deleted (
23.09)
The first parameter type changed in PHP 8.1:
The ldap parameter expects an LDAP\Connection instance now; previously, a valid ldap link resource was expected.
https://www.php.net/manual/en/function.ldap-set-option.php
The option is set globally when null is used instead. Originally, a resource was passed instead of null but was later changed due to some inconsistencies - details on #9417. Given the feedback on #note-2 and presuming this was ultimately an upstream issue in PHP (as noted on the referenced redmine), it may be this is now resolved and we can return to passing $ldap instead of null.
Here's the above change as a patch (may be applied using the System Patches package): Show
Updated by Lev Prokofev 3 months ago
I tested the patch on the client machine (#2346370170), and both LDAP servers can bind now.
Software version:
23.09.1-RELEASE (amd64)
built on Wed Feb 7 11:52:00 MST 2024
FreeBSD 14.0-CURRENT
Updated by Jim Pingle 3 months ago
- Assignee set to Jim Pingle
- Target version set to 2.8.0
- Plus Target Version set to 24.03
Updated by Jim Pingle 3 months ago
- Status changed from Ready To Test to New
- Assignee deleted (
Jim Pingle) - Target version deleted (
2.8.0) - Plus Target Version deleted (
24.03)
Patch doesn't really help it, it's still broken or inconsistent when I try.
- One LDAP server with custom CA (not in global trust store)
- One LDAP server with ACME CA (globally trusted)
With the patch applied, the custom CA never works, ACME CA always works.
With the patch reverted (current behavior), whichever one I try first always works, but sometimes they do both work if the timing is right.
Be sure to restart PHP and the GUI (/etc/rc.php-fpm_restart ; /etc/rc.restart_webgui) after making code changes and before attempting to test authentication (e.g. reset PHP/GUI, then test A and test B, change the PHP code/patch, reset PHP/GUI, then test A and test B).