Bug #15060: LDAP bind fails when authentication servers use different CA chains - pfSense - pfSense bugtracker

Custom queries

2.4.5-p1 - Resolved/Closed
2.5.0 - Resolved/Closed
2.5.1 - Resolved/Closed
2.5.2 - Resolved/Closed
2.6.0 - Resolved/Closed
2.7.0 - Resolved/Closed
2.7.1 - All Open Issues
2.7.1 - Resolved/Closed
2.7.2 - Resolved/Closed
2.8.0 - All Open Bugs
2.8.0 - All Open Features
2.8.0 - All Open Issues
2.8.0 - All Open Regressions
2.8.0 - Feedback
2.8.0 - Needs Attention
2.8.0 - New/Confirmed
2.8.0 - Pull Requests
2.8.0 - Regressions affecting 2.7.0
2.8.0 - Resolved/Closed
21.02.2/2.5.1 - Resolved/Closed
21.05 Plus - All Closed Issues
21.05.1 Plus Target - All Closed Issues
21.05.1 Target - All Closed Issues
22.01 Plus - All Closed Issues
22.01 Target - All Closed Issues
22.05 Plus - All Closed Issues
22.05 Target - All Closed Issues
23.01 Plus - All Closed Issues
23.01 Target - All Closed Issues
23.05 Plus - All Closed Issues
23.05 Target - All Closed Issues
23.05.1 Plus - All Closed Issues
23.05.1 Target - All Closed Issues
23.09 Plus - All Closed Issues
23.09 Target - All Closed Issues
23.09.1 Plus - All Closed Issues
23.09.1 Target - All Closed Issues
24.03 Plus - All Closed Issues
24.03 Target - All Closed Issues
24.07 Plus - All Closed Issues
24.07 Plus - All Open Issues
24.07 Plus - Feedback Issues
24.07 Plus - Needs Attention/Work
24.07 Plus - New/Confirmed/In Progress Issues
24.07 Plus - Pull Request Review
24.07 Plus - Waiting on Merge
24.07 Target - All Closed Issues
24.07 Target - All Open Issues
All Open Issues assigned to Me
All Open Pull Requests
Any Target - All Open Regressions
Any Target - Feedback Issues
CE-Next - All Closed Issues (Move to specific target)
CE-Next - All Open Issues
CE-Next - Feedback (Likely needs target changed)
New Issues by Category - Future Target
New Issues by Category - No Target
New Issues by Category - No Target+Future
No Target - All Open Issues (Base Only)
No Target - New Issues (Base Only)
No Target - New Issues (Base and Packages)
Release Notes - Plus Target Version (DO NOT EDIT)
Release Notes - Target Version (DO NOT EDIT)

Actions

Copy link

Bug #15060

open

LDAP bind fails when authentication servers use different CA chains

Added by Giovanni Vecchi 6 months ago. Updated 3 months ago.

Status:

New

Priority:

Normal

Assignee:

Category:

User Manager / Privileges

Target version:

Start date:

Due date:

% Done:

Estimated time:

Plus Target Version:

Release Notes:

Default

Affected Version:

Affected Architecture:

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.

History
Notes
Property changes

Actions

Copy link

Updated by Giovanni Vecchi 6 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."

Actions

Copy link

Updated by Ph. T 5 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.

Actions

Copy link

Updated by Marcos M 5 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 Hide

diff --git a/src/etc/inc/auth.inc b/src/etc/inc/auth.inc
index 58dac078df..b1fdb33e9f 100644
--- a/src/etc/inc/auth.inc
+++ b/src/etc/inc/auth.inc
@@ -1097,8 +1097,8 @@ function ldap_setup_caenv($ldap, $authcfg) {
         ldap_set_option($ldap, LDAP_OPT_X_TLS_REQUIRE_CERT, LDAP_OPT_X_TLS_NEVER);
         return;
     } elseif ($authcfg['ldap_caref'] == "global") {
-        ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR, "/etc/ssl/");
-        ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, "/etc/ssl/cert.pem");
+        ldap_set_option($ldap, LDAP_OPT_X_TLS_CACERTDIR, "/etc/ssl/");
+        ldap_set_option($ldap, LDAP_OPT_X_TLS_CACERTFILE, "/etc/ssl/cert.pem");
         ldap_set_option($ldap, LDAP_OPT_X_TLS_REQUIRE_CERT, LDAP_OPT_X_TLS_HARD);
     } else {
         $caref = lookup_ca($authcfg['ldap_caref']);
@@ -1120,8 +1120,8 @@ function ldap_setup_caenv($ldap, $authcfg) {
         @chmod($cert_filename, 0600);

         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);
+        ldap_set_option($ldap, LDAP_OPT_X_TLS_CACERTDIR, $cert_path);
+        ldap_set_option($ldap, LDAP_OPT_X_TLS_CACERTFILE, $cert_filename);
     }
 }

Actions

Copy link

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

Actions

Copy link

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

Actions

Copy link

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).

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

pfSense

Custom queries

Bug #15060

LDAP bind fails when authentication servers use different CA chains

Updated by Giovanni Vecchi 6 months ago

Updated by Ph. T 5 months ago

Updated by Marcos M 5 months ago

Updated by Lev Prokofev 3 months ago

Updated by Jim Pingle 3 months ago

Updated by Jim Pingle 3 months ago