Bug #9433
closed
User directory authentication over LDAPS fails in 2.4.4_2
Added by JT Gray over 5 years ago.
Updated over 5 years ago.
Category:
User Manager / Privileges
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.
- 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.
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.
Also available in: Atom
PDF
Updated by 
Updated by