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.
