ldap_bind() hanging / freezing

Question

So I have reduced my problem to a simple php script

test.php

<?php 
  ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7); //for logging
  if($con = ldap_connect( 'ldaps:domain.com', 636 )){
    $bind_return = ldap_bind($con, 'username', 'super_secret_password');
  }
?>

When I go to localhost\test.php, the browser indicates it is waiting for a response, and will just hang there.... forever (more accurately until I stop it, sometimes an hour later, but you get the idea). Using xdebug, I'm able to pinpoint the hanging to the ldap_bind() call. When I try to step over or into the ldap_bind() line of code, my xdebug hangs and becomes unresponsive.

The logged output from ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7); is:

ldap_create
ldap_url_parse_ext(domain.com)
ldap_bind_s
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP domain.com:636
ldap_new_socket: 15
ldap_prepare_socket: 15
ldap_connect_to_host: Trying domain.com:636
ldap_pvt_connect: fd: 15 tm: -1 async: 0

And then nothing after that. I'm not sure what to make of it, and Google has not been kind.

ldap_connect() is successful, the return is something like (resource) resource id='2' type='ldap link'. max_execution_time does NOT interrupt the execution of the script. If I put something like while(true){} before the problematic line of code then the max_execution_time will trigger and I will see an error. So ldap_bind() is somehow even stopping the php environment from timing out. Wrapping the code in a try/catch block does nothing to alleviate the hanging.

I have tried:

1) Restarting the server many, many times

2) Reinstalling php5, php-ldap, libapache2-mod-php5, and apache2

3) Scouring the internet

The funny thing is ldap_bind() was working perfectly a few weeks ago, it still works perfectly on my production site, but I've been trying to figure this out for a long while now and am so close to lighting my computer on fire. Any help is appreciated.

UPDATE:

So I installed ldap-utils and ran a ldapsearch -H ldaps://domain.com, and it hung. I ran it with the debugging option ldapsearch -d 1 -H ldaps://domain.com and the output was:

ldap_url_parse_ext(ldaps://domain.com/)
ldap_create
ldap_url_parse_ext(ldaps://domain.com:636/??base)
ldap_pvt_sasl_getmech
ldap_search
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP domain.com:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying domain.com:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
^^^^It hangs right here^^^^

Seems familiar, no? Running an strace on the whole command produces a long trace but hangs at this point

write(3, "\26\3\0\0p\1\0\0l\3\3T\254/\31\24\200\25 \247\221\7\251\240\271\35\"\272\203V \305"..., 117) = 117
read(3,  

Again, it hangs right here, the cursor just blinking after the "read(3,"

I came across this bug report with openldap that is eerily identical to my own problem, down to the strace hanging at the read command. However, there doesn't seem to be a discussion about solutions as openldap is pointing the finger at gnuTLS.

Answer 1

It sounds like it is something environmental. This could be a firewall change, network route change, SSL Certificate expiration, change in the LDAP server, etc.

I would execute a series of diagnostic protocols working up the ISO stack.

Start with a telnet to port 636 on the remote server. If that works, download openldap and give that a shot. See if you can manually connect with that. If that works run your debug version in production (from the command line) and see what the next step after ldap_pvt_connect is. Also, try the command line version, you have more finite control of things and you don't have a webserver in the mix.