LDAP Server: "Failed to bind to server. ldap error #-1 Can't contact LDAP server" [#2857418]

Hello,

I am trying to set up my LDAP server, but after I add the server, it says, "Connection successful, bind failed." under Server Reachable.

When I test the LDAP server configuration, the Test Results are:

TEST	RESULT
Binding with DN for non-anonymous search (CN=firstname lastname,OU=organization,DC=company,DC=ca). Using password stored in configuration.
Failed to bind to server. ldap error #-1 Can't contact LDAP server	FAIL

The output of the detailed logging is as follows:

TYPE	MESSAGE
ldap	LDAP ldap_search error. basedn: dc=company,dc=ca\| filter: (sAMAccountName=firstname_lastname)\| attributes: Array ( ) \| errmsg: Can't contact LDAP server\| ldap err no: -1\|
ldap_server	ldap_search() function error. LDAP Error: Can't contact LDAP server, ldap_search() parameters: ldap_search() call: base_dn: dc=company,dc=ca, filter = (sAMAccountName=firstname_lastname), attributes: , attrsonly = 0, sizelimit = 0, timelimit = 0, deref = , scope = 3

I understand this is a LDAP_OPERATIONS_ERROR.

My LDAP server configuration is:

SERVER

Name -SERVERNAME
Machine name - servername
Enabled - True
LDAP Server Type - Active Directory
Server Address - IPaddress
LDAP port - 389
Use Start-TLS - False

BINDING METHOD

Binding Method for searches - Service Account Bind: Use credentials in the Service Account field below to bind to LDAP
DN for non-anonymous search - CN=firstname lastname,OU=organization,DC=company,DC=ca
Password for non-anonymous search - password
Clear existing password from database - True

USERS

Base DNs for LDAP Users, Groups, and Other Entries - dc=company,dc=ca
AuthName Attribute - sAMAccountName
AccountName Attribute - sAMAccountName
Email Attribute - mail
Email Template -
Persistant and Unique User ID Attribute -
Does PUID hold a binary value? - False
Expression for User DN -
Testing Drupal Username - firstname_lastname
DN of Testing Username - CN=firstname lastname,OU=organization,DC=company,DC=ca

All the fields in GROUPS and PAGINATION are either blank or unchecked.

Any ideas on how to debug this? It would be greatly appreciated.

Thank you.

Comment	File	Size	Author
#8	tcpdump.txt	720 bytes	amyli

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

2 March 2017 at 19:48

amyli created an issue. See original summary.

Comment #2

grahl

he/him

Zürich

CreditAttribution: grahl as a volunteer commented 6 March 2017 at 18:24

You should be able to get a successful bind, just with ldap_servers alone and nothing else enabled so I'm ignoring ldap_user for now.

What I found odd in your description is that you had "Clear existing password from database - True". This is not an option one would normally use since clearing the password is only relevant for sites where you want to unset the password in the database for some reason. Setting that checkbox will ignore anything you put into the password field on save.

FYI: I have sometimes noticed a false positive pertaining to a connection when the remote host does not explicitly reject the connection (e.g. local Docker loopback network) so maybe the connection is the issue, too.

Comment #3

6 March 2017 at 18:40

grahl committed c93edc0 on 8.x-3.x

Issue #2857418: UX improvement for saved password

Comment #4

grahl

he/him

Zürich

CreditAttribution: grahl as a volunteer commented 6 March 2017 at 18:41

I've pushed a UX improvement for this to the dev branch, no change in behavior.

Comment #5

amyli CreditAttribution: amyli commented 7 March 2017 at 20:21

Hi grahl,

Thank you for replying. Yes, I later unchecked the "Clear existing password from database" but the binding still failed.

I did a tcpdump between my Apache web server where my Drupal site is hosted and the LDAP server. Then I tried to test the LDAP server configuration, and I still received the same error. tcpdump showed no talking between the LDAP server and the Drupal site through port 389.

Any advice on how I should proceed or what I should look for?

Comment #6

grahl

he/him

Zürich

CreditAttribution: grahl as a volunteer commented 8 March 2017 at 19:05

Hi amyli

Thanks for the thorough debugging. Hmm, that's really weird!

I personally have a working setup with a FQDN, localhost as well as 127.0.0.1 directly, so your setup definitely should work. There isn't anything in the field except the IP, correct? No ldap:// or trailing spaces?

Can you locally connect to the LDAP server or is that not an option in your environment? The only thing that comes to mind otherwise is a firewall issue.

Comment #7

amyli CreditAttribution: amyli commented 9 March 2017 at 19:13

Yes, I agree it's really weird and I think it might just be a firewall issue too. I've tried only putting the IP and then only putting the hostname.domain. I did not put "ldap://" and I double checked that there is no trailing white spaces.

I will try to locally connect to the LDAP server this afternoon and get back to you on that.

Comment #8

amyli CreditAttribution: amyli commented 10 March 2017 at 21:23

File	Size
tcpdump.txt	720 bytes

I've tried using only the IP and using only a FQDN. There's no "ldap://" or trailing spaces.

Interestingly enough, when I run ldapsearch -x -h serverAddress -p 389 -b "dn" in the command-line, I am able to search successfully and tcpdump shows traffic between the LDAP server and the Apache web server where my Drupal site is hosted.

Please find the attached tcpdump output when I try to test the LDAP server configuration. I apologize for forgetting to attach it on Tuesday.

Comment #9

amyli CreditAttribution: amyli commented 15 March 2017 at 12:50

Comment #10

grahl

he/him

Zürich

CreditAttribution: grahl as a volunteer commented 15 March 2017 at 20:20

Err, okay that is weird. Could you please try the example here from the LDAP help page to see if you can get it to bind with your configuration in a test.php?

http://php.net/manual/en/function.ldap-bind.php

If that works, could you please share an anonymized version of your ldap_servers yaml configuration?

Comment #11

amyli CreditAttribution: amyli commented 16 March 2017 at 18:17

The ldap_bind function failed for me. I guess this is a PHP problem now, not Drupal.

May I ask which PHP packages you are using? I am on CentOS 7 and I installed the following PHP packages:

php56w.x86_64	5.6.30-1.w7	@webtatic
php56w-cli.x86_64	5.6.30-1.w7	@webtatic
php56w-common.x86_64	5.6.30-1.w7	@webtatic
php56w-devel.x86_64	5.6.30-1.w7	@webtatic
php56w-gd.x86_64	5.6.30-1.w7	@webtatic
php56w-intl.x86_64	5.6.30-1.w7	@webtatic
php56w-ldap.x86_64	5.6.30-1.w7	@webtatic
php56w-mbstring.x86_64	5.6.30-1.w7	@webtatic
php56w-mcrypt.x86_64	5.6.30-1.w7	@webtatic
php56w-mysql.x86_64	5.6.30-1.w7	@webtatic
php56w-opcache.x86_64	5.6.30-1.w7	@webtatic
php56w-pdo.x86_64	5.6.30-1.w7	@webtatic
php56w-xml.x86_64	5.6.30-1.w7	@webtatic

I also forgot to mention I attached the output from tcpdump when I test the LDAP server configuration - sorry about that.

Comment #12

grahl

he/him

Zürich

CreditAttribution: grahl as a volunteer commented 18 March 2017 at 08:10

Good luck trying to narrowing this down...

I know that CentOS 7.x with IUS PHP 5.6 as well as macOS homebrew with PHP 7.0 both provide working sets of packages.

The only thing which I know can be tricky on CnetOS is TLS, since OpenLDAP will throw exceptions if the certificate chain for a custom CA is not correctly presented.

Comment #13

amyli CreditAttribution: amyli commented 28 March 2017 at 18:27

Status:

Active

» Fixed

grahl!

I am able to bind to the LDAP server successfully now! It turns out SELinux didn't allow the httpd daemon to talk to the LDAP server on the same machine. I ran setsebool -P httpd_can_network_connect on to enable SELinux network connectivity through httpd.

Thank you very much for all your help - I really appreciate it.