Project

General

Profile

Actions

Bug #9433

closed

User directory authentication over LDAPS fails in 2.4.4_2

Added by JT Gray about 5 years ago. Updated about 5 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
User Manager / Privileges
Target version:
-
Start date:
03/25/2019
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:
amd64

Description

I have two pfsense servers configured identically with the same users/passwords, etc. The only difference is one is version 2.4.3-RELEASE and the other is 2.4.4-RELEASE-p2. The server with pfsense version 2.4.3 authenticates users via AD over LDAPS without issue.

On the user authentication server page for the latter server, with version 2.4.4-RELEASE-p2, the Active Directory user server fails with "Could not connect to the LDAP server. Please check the LDAP configuration." I am able to retrieve and verify certificate details via openssl over port 636, but I only see these vague messages via System Logs:
"/diag_authentication.php: ERROR! Could not bind to LDAP server AD. Please check the bind credentials."
"/system_authservers.php: ERROR! ldap_get_user_ous() could not bind to server ."

It is my strong suspicion that the Global Root CA list is not functioning properly, causing the cert to not be validated and leading to this User Directory authentication failure. I have tried to debug further by running tcpdump, but the output did not appear meaningful. Further, I'm not 100% sure how to evaluate the contents of the Global Root CA list to validate my assumptions.

I welcome any confirmation of this bug and/or additional tips for debugging the matter further.

Thank you.

Actions #1

Updated by Jim Pingle about 5 years ago

  • Category set to User Manager / Privileges
  • Status changed from New to Not a Bug
  • Priority changed from High to Normal

The Global Root CA is working fine here on 2.4.4-p2, I can't reproduce the problem as stated.

Problems like this almost invariably end up being DNS/hostname related. Please start a thread on https://forum.netgate.com to discuss the issue with your environment. If a specific bug can be identified, this issue can be reopened once we have enough information to reproduce the problem.

Also, due to #9417 you will probably need to run options 16 and 11 from the console/ssh (or reboot) after making changes to an SSL LDAP server. You can apply the commit ID from that issue (996a1ad90e5682bf881bafd8b75d1b1a7e3f7831) using the System Patches package to see if that helps. Though the issue is targeted at 2.5.0, the patch applies to 2.4.4-p2 and works.

Actions #2

Updated by JT Gray about 5 years ago

Awesome, thanks - this fixed it for me!!

Jim Pingle wrote:

The Global Root CA is working fine here on 2.4.4-p2, I can't reproduce the problem as stated.

Problems like this almost invariably end up being DNS/hostname related. Please start a thread on https://forum.netgate.com to discuss the issue with your environment. If a specific bug can be identified, this issue can be reopened once we have enough information to reproduce the problem.

Also, due to #9417 you will probably need to run options 16 and 11 from the console/ssh (or reboot) after making changes to an SSL LDAP server. You can apply the commit ID from that issue (996a1ad90e5682bf881bafd8b75d1b1a7e3f7831) using the System Patches package to see if that helps. Though the issue is targeted at 2.5.0, the patch applies to 2.4.4-p2 and works.

Actions

Also available in: Atom PDF