Bug #8038
closed
Cannot authenticate via LDAP+SSL in 2.4.1
Added by Jimmy Chen almost 7 years ago.
Updated almost 7 years ago.
Category:
User Manager / Privileges
Affected Architecture:
All
Description
Same exact configuration that had been working previously in 2.3.x but is now not working after I upgraded to 2.4.1. I re-imported the root CA as well as the certificate for the Domain Controller just to see if it required the intermediate node in the chain. However, result is exactly the same. As long as I am using SSL, it fails to authenticate. If I switch to non-encrypted TCP, it works perfectly.
Oct 31 14:56:49 php-fpm 43805 /system_authservers.php: ERROR! ldap_get_user_ous() could not bind to server .
Oct 31 14:56:46 php-fpm 43805 /system_authservers.php: ERROR! ldap_get_groups() could not bind to server my.domain.com.
Files
- Category set to User Manager / Privileges
- Status changed from New to Feedback
- Assignee set to Jim Pingle
- Priority changed from High to Normal
- Affected Version set to 2.4.x
- Affected Architecture All added
- Affected Architecture deleted (
It works for me here with both a standard CA and with an intermediate CA chain on multiple firewalls and against multiple LDAP servers.
In the certificate manager on the CA tab, it should show the root CA and the intermediate, and it should show the root being the issuer of the intermediate. Then make sure that the intermediate CA of the chain is selected in the auth server settings entry for the LDAP server.
If you look in /var/run/certs/ you should see a file that matches the refid of the CA (and perhaps some others from different auth attempts), it should contain the entire chain (root+intermediate)
Also, between tests, restart the GUI and PHP-FPM to be sure PHP isn't doing something dumb with caching the auth test result. We've seen that before but it's tricky to reproduce, and seems to be a PHP/PHP-FPM quirk. Either use options 16 then 11 from the console menu, or manually run /etc/rc.php-fpm_restart ; /etc/rc.restart_webgui
I tried everything you suggested but the result is still exactly the same. I attached screenshots of the configuration and connectivity test.
Is there some way to get further debug logging for exact reason why it's failing? The System Logs entries seem too generic to be of any help.
There must still be something about the chain that isn't quite right, the same test here works perfectly fine using Save & Test on the Auth Settings tab for all of my LDAP servers using SSL.
There isn't any good way to get LDAP debug info out of the PHP LDAP module these days, at least not that I've seen.
You can try making a single CA entry with both certificates pasted in to see if that works, but it shouldn't be necessary with the current chaining code.
Is that DC1 CA entry really an intermediate CA? Usually a CA would not have a hostname for its CN.
DC1 CA is the Root CA cert of the Domain Controller. DC1 is the certificate of the domain controller signed by the Root CA. Back in 2.3, I used to only have to add the Root CA into Cert Manager and use that for the authentication config.
- Status changed from Feedback to Rejected
Then that's not an intermediate CA. All you need is the root. Having that non-CA in the CA manager is probably the problem. Just import the root, select the root in the LDAP settings. If that doesn't work, then follow up on the forum. Nothing changed for that scenario and it should work the same now as before, and does on all my test systems.
An intermediate means an intermediate CA, meaning the root CA signs the intermediate CA, intermediate CA signs the server cert, but it needs the root+intermediate CA to validate the entire chain. You never have to import the server cert to the client (in this case, pfSense).
We have code on 2.4.2 to prevent importing a non-CA on the CA tab, which can prevent that sort of misconfiguration.
Also available in: Atom
PDF
Updated by 
Updated by 
