cypht icon indicating copy to clipboard operation
cypht copied to clipboard

Binding to LDAP with authentication breaks LDAP_contacts (anonymous works)

Open robert-winkler opened this issue 4 years ago • 9 comments

Switching from anonymous to authenticated binding breaks LDAP contacts

I store my contacts in OpenLDAP. Anonymous binding to the DB to read the contacts in cypht works. However, when changing to auth=true in the ldap.ini, the connection to the LDAP server breaks. There is no error message. I tried both: 1) entering the login data in the ldap.ini ("admin", "cn=admin", ..); and 2) leaving admin='' path='' blank and configuring the access data in the Web-Interface.

I consider this issue critical, since anonymous binding to an LDAP server should be disallowed.

The admin connection to the LDAP server and reading/writing entries using phpLDAPadmin works; thus the configuration of the server looks fine.

Version and Environment

Rev: I used the install script. There is no obvious version, but this might help: 1664 Jul 19 20:04 composer.json

OS: Ubuntu 18.04.3 LTS PHP: PHP 7.2.19-0ubuntu0.18.04.2 (cli) (built: Aug 12 2019 19:34:28) ( NTS )

robert-winkler avatar Oct 25 '19 19:10 robert-winkler

Sounds like a bug. Sorry for the late response. I will check into it as soon as I can (also adding this as a must fix before the next RC release). Thanks for the report!

jasonmunro avatar Nov 12 '19 05:11 jasonmunro

This seems to be working for me here, but there could definitely still be a bug. One thing I noticed is that when I set my credentials via the ini file, I need to setup the entire dn, but when doing so via the settings page only the username and the code builds the dn.

For example my username in the ini file set to "cn=admin,dc=foo,dc=com" translates to just "admin" when setting the username using the settings page.

Best way to troubleshoot this is to make the following code changes locally, then load the contacts page, and check wherever PHP errors are logged (also you must be in debug mode for the errors to be logged).

Code changes to debug: https://gist.github.com/jasonmunro/2afcaae292757c87e7c87a6593b8fc42 Info on debug mode: https://github.com/jasonmunro/cypht/wiki/Troubleshooting-Login-Issues#debug-mode

Hope that helps!

jasonmunro avatar Nov 13 '19 23:11 jasonmunro

Hi Jason,

  1. I applied the patch and run> php /usr/local/share/cypht/scripts/config_gen.php.

  2. opened mail-debug.

  3. The admin is set in the Site settings.

  4. and looked for the error.log file after trying to add a contact in LDAP_contacts.

=> no error! (I created a fresh file and it remains empty..)

setting the "cn=admin,dc=foo,dc=com" (my domain instead of foo) did not work either.

using the same parameters with phpLDAPadmin works (i.e. the configuration of the LDAP server should be o.k.). 

any ideas?

Best, Robert

On Wed, 13 Nov 2019 15:39:59 -0800 jasonmunro/cypht [email protected] said


 This seems to be working for me here, but there could definitely still be a bug. One thing I noticed is that when I set my credentials via the ini file, I need to setup the entire dn, but when doing so via the settings page only the username and the code builds the dn.    For example my username in the ini file set to "cn=admin,dc=foo,dc=com" translates to just "admin" when setting the username using the settings page.    Best way to troubleshoot this is to make the following code changes locally, then load the contacts page, and check wherever PHP errors are logged (also you must be in debug mode for the errors to be logged).    Code changes to debug: https://gist.github.com/jasonmunro/2afcaae292757c87e7c87a6593b8fc42 [1]  Info on debug mode: https://github.com/jasonmunro/cypht/wiki/Troubleshooting-Login-Issues#debug-mode [2]    Hope that helps!    —  You are receiving this because you authored the thread.  Reply to this email directly, view it on GitHub [3], or unsubscribe [4].

Links:

[1] https://gist.github.com/jasonmunro/2afcaae292757c87e7c87a6593b8fc42 [2] https://github.com/jasonmunro/cypht/wiki/Troubleshooting-Login-Issues#debug-mode [3] https://github.com/jasonmunro/cypht/issues/359?email_source=notifications&email_token=ACMIC3IAA4DEGCNAVRQS34LQTSF47A5CNFSM4JFHVDJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEAB4II#issuecomment-553655841 [4] https://github.com/notifications/unsubscribe-auth/ACMIC3MZ3VWPSNIWIPBIRXLQTSF47ANCNFSM4JFHVDJA

robert-winkler avatar Nov 14 '19 03:11 robert-winkler

Robert, Thank you for the follow up. Every page load should log information in the PHP error log location when in debug mode, so if there is nothing in the log I think debug mode might not be enabled or PHP logging is going somewhere else (?)

jasonmunro avatar Nov 14 '19 04:11 jasonmunro

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hi Jason,

This is php7.2 on an Ubuntu 18.04 LTS Linux (nothing exotic ;-)) and error logs should go into this dirs and I also searched on the file system. However, maybe I need to configure the php.ini. I'm investigating this ASAP (hopefully today).

Best regards,

Robert

Jason Munro [email protected] wrote:

Robert, Thank you for the follow up. Every page load should log information in the PHP error log location when in debug mode, so if there is nothing in the log I think debug mode might not be enabled or PHP logging is going somewhere else (?)


Robert Winkler

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRujpWQ/v2xE00/+4Z82ycOpoE0FwUCXc1ikgAKCRB82ycOpoE0 FxDkAPwJHQzEmuIH5MSpG5zFjHSrfdpsVcIWT5Te4JhX35TH1AEA5G56RmolHHDU IZSiyqcfutsATmqON9UN8v9yET5uMQ4= =gGhP -----END PGP SIGNATURE-----

robert-winkler avatar Nov 14 '19 14:11 robert-winkler

@robert-winkler we need your logs :-)

marclaporte avatar Sep 19 '20 04:09 marclaporte

Hi, I don't get a PHP error. This is what I did:

  • Check Apache and PHP version.
  • Define PHP error log location: error_log = /var/log/php_errors.log in /etc/php/7.3/apache2/php.ini
  • Restart Apache service apache2 restart
  • Open Cypht in debug mode .../mail-debug/?page=contacts
  • Add LDAP contact
  • No /var/log/php_errors.log...

robert-winkler avatar Dec 17 '20 21:12 robert-winkler

@robert-winkler I have every reason to believe this issue is real and we have a bug. However we need to move forward with a release so I'm going to keep this open but remove it as a blocker.

jasonmunro avatar Mar 10 '21 03:03 jasonmunro