LDAP Error: Protocol Error, Unable to bind, LDAP result: -1

[nahidrezaei]

here is my query result

[netniV]

Try clearing the specific DN and specific password, does that work?

[mppare]

I cleared specific DN and specific password. I get: LDAP Search Error: Specific DN and Password required.

I changed the LDAP Mode to "Anonymous Searching" - get the same LDAP search error.

I changed the LDAP Mode to "No Searching" and populated the Distinguished Name (DN) field to <username>@[my domain] - get same LDAP search error.

[netniV]

Are you doing group membership? Or just LDAP auth?

[mppare]

Nope, we are doing just plain LDAP auth - the same exact as our existing working 0.8.8b environment.

[mppare]

Here is some additional info:

On the old server (LDAP works), I pulled this from the ldap section of the Apache Technical Support page.
LDAP Support enabled
RCS Version $Id: ldap.c 299434 2010-05-17 20:09:42Z pajoye $
Total Links 0/unlimited
API Version 3001
Vendor Name OpenLDAP
Vendor Version 20423
SASL Support Enabled

Consequently, on my new server (LDAP can't bind), here is the same configuration section:
LDAP Support enabled
RCS Version $Id$
Total Links 0/unlimited
API Version 3001
Vendor Name OpenLDAP
Vendor Version 20444
SASL Support Enabled

Looks like missing RCS version?

[netniV]

Aside from setting the server name, these are my settings which work:


If you are struggling, check that you are able to reach the server in question and that the port is open through any firewalls. Also, make sure the PHP LDAP is installed and enabled.

I don't normally use LDAP so I just through the settings together to a quick VM running an AD DC. Then I just logged in using the username, without the @netniv.local

[netniV]

Also, whilst PHP LDAP may be installed, make sure it is enabled as a module. This is normally done by editing php.ini to add

Code: Select all

extension=ldap.so

Note that some systems have two versions of php.ini, one for the web and one for cli. On ubuntu/debian systems, you can use a2enmod ldap which should enable the module for apache2.

[mppare]

I already tried the "no searching" mode and that did not work. I also confirmed that php-ldap is installed and enabled. The extension is enabled in /etc/php.d/ldap.ini but I also added it to php.ini. I know it is the correct php.ini - I already made some changes to it (memory adjustments) and confirmed that these carried over after I restarted httpd.

I also confirmed that the VM can communicate with the configured AD controller. I was able to establish sessions to the AD controller on ports 389 and 636.

I'm going to try something different on a test VM using php 7.1

[mppare]

Same problem in php 7. I also verified (with ldapsearch) that I'm able to read AD successfully using the same AD account I configured in the Cacti UI.

I really think that there is an issue with Cacti.

Has anyone else been able to get ldap working in 1.1.38?

[netniV]

I have had LDAP working for LDAP only but I now use the multiple domain mode rather than just the LDAP only mode. Why not try configuring the system that way instead? In 1.3, I will be moving all LDAP to the multi-domain mode because I can not see a logical reason for maintaining two separately identical methods of authentication.

[mppare]

Yeah I already tried multiple domains, same issue.

[netniV]

Is this going through a firewall?

[mppare]

Yes, most likely going through a firewall. BUT:

ldapsearch from the console works.

If I run tcpdump at the console and attempt to login to Cacti via an LDAP-configured account - no packets are captured.

If I run tcpdump at the console while trying ldapsearch from a 2nd console, I see packets to/from AD box

Console is same box I'm running cacti on.

[netniV]

OK what that suggests then is that SELinux is getting in the way. I have seen it before were the default is that HTTPD (Apache or nginx) is not allowed to make outgoing network connections. It's one of the security features. Try running the following and see if it suddenly works for you:

Code: Select all

setsebool -P httpd_can_network_connect 1

If so, I'll try to make it quite clear to check for that in the documentation.