Project

General

Profile

Actions
Copy link

Bug #15060

open

LDAP bind fails when authentication servers use different CA chains

Added by Giovanni Vecchi about 1 year ago. Updated 11 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
User Manager / Privileges
Target version:
-
Start date:
Due date:
% Done:

0%

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.

Related issues

Has duplicate Bug #15588: The picking of CA in the LDAP config is inconsistent.Duplicate

Actions
Actions
Copy link
 #1

Updated by Giovanni Vecchi about 1 year 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
 #2

Updated by Ph. T about 1 year 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
 #3

Updated by Marcos M about 1 year 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

Actions
Copy link
 #4

Updated by Lev Prokofev 11 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
 #5

Updated by Jim Pingle 11 months ago

  • Assignee set to Jim Pingle
  • Target version set to 2.8.0
  • Plus Target Version set to 24.03
Actions
Copy link
 #6

Updated by Jim Pingle 11 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
 #7

Updated by Jim Pingle 6 months ago

  • Has duplicate Bug #15588: The picking of CA in the LDAP config is inconsistent. added
Actions
Copy link

Also available in: Atom PDF