Given the multiple elements involved, I really hesitated to create a bug report, but not sure what else to do at this point.

Our setup is like so (all x86_64).....

Drupal/Client system:
- Redhat 6
- Drupal 7.7
- PHP 5.3.3.-3
- PostgreSQL 8.4.7-2
- OpenLDAP client
LDAP Server:
- Redhat 5.6
- 389-DS noarch 1.1.3-4
- 389-DS base 1.2.2-1

Our (sanitized) LDAP server config is inthe attached html file (saved as .txt)

The LDAP Server type is set as "default", but I could not see anything wrong with that vis-a-vis 389-DS.

A password is stored for non-anonymous search; I verified that binddn and bindpw are set correctly in the ldap_servers table..

When I hit "Test" I get the following:

* Warning: ldap_start_tls(): Unable to start TLS: Connect error in LdapServer->connect() (line 179 of /var/www/html/sites/all/modules/ldap/ldap_servers/LdapServer.class.php).
Connection Info
o Binding with DN for non-anonymous search (cn=portal-ro,ou=DSA,dc=deohs,dc=washington,dc=edu). Using password stored in configuration
o Binding with DN for non-anonymous search (cn=portal-ro,ou=DSA,dc=deohs,dc=washington,dc=edu). Using password stored in configuration
o Failed to connect to LDAP server. See watchdog error logs for details.

Line 179 looks like the last, catch-all error and that presumably means that the function was able to identify our LDAP server as v3

The (sanitized) slapd log for this LDAP server shows:

[26/Sep/2011:15:10:13 -0700] conn=987693 fd=432 slot=432 connection from to
[26/Sep/2011:15:10:13 -0700] conn=987693 op=0 EXT oid="" name="startTLS"
[26/Sep/2011:15:10:13 -0700] conn=987693 op=0 RESULT err=0 tag=120 nentries=0 etime=0
[26/Sep/2011:15:10:13 -0700] conn=987693 op=-1 fd=432 closed Encountered end of file.

My searching suggests that this EOF error is suually tied to a certificate problem. However, we are able to succesfully connect from the client Drupal system to the 389 LDAP server using the exact same DSA binddn and bindpw using the (sanitized) PHP script appended below.

In addition the client setting in /etc/openldap/ldap.conf for CA_CERTREQ (never, required, allow) does not seem to matter. Drupal fails in all cases while the script below works regardless of that setting.

I checked phpinfo() definitely includes /etc/php.d/ldap.ini as parsed.

I hope that I have done enough to document the problem and I would be eager for any suggestions or suggestions on what else to pursue. I am at a loss and we are really looking to get LDAP working to support other functions (like Maestro workflow).



PHP Script that successfully connects using TLS:


   if(ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3))
      if(ldap_set_option($ds, LDAP_OPT_REFERRALS, 0))
            $ldapbind = @ldap_bind($ds,$usr,$pwd);
            $dn = "ou=People,dc=example,dc=com";
            $justthese = array("ou", "sn", "givenname", "mail");
            $sr=ldap_search($ds, $dn, $filter, $justthese);
            $info = ldap_get_entries($ds, $sr);
            echo $info["count"]." entries returned\n";
            for ($i=0; $ii<$info[$i]["count"]; $ii++){
               $data = $info[$i][$ii];
               echo $data.":  ".$info[$i][$data][0]."\n";
      echo "(Connection ERROR)\n";
      echo "(Connection OK)\n";


ldap_config.html_.txt9.19 KBgeste
Members fund testing for the Drupal project. Drupal Association Learn more


geste’s picture

I should have added that I updated to most recent 7.x-1.x-dev before I repeated testing yesterday. Jim

johnbarclay’s picture

No idea on this one. Thanks for the details. I dug around and don't see anything wrong.

Some debugging thoughts:
1. hard code your connection code in the beginning of LdapServer.class.php. replace function connect() with:

function connect() {
  ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
  ldap_set_option($ds, LDAP_OPT_REFERRALS, 0);
  $this->connection = $ds;
  return LDAP_SUCCESS;

2. If you are running the above script from the command line, it may have a different php.ini file that the webserver php. If thats the case look for differences in the 2 php.ini.

3. If its easy to check, try on php 5.2.x see if that helps.

geste’s picture


Thanks for the debugging ideas. In the first case, I substituted the pre-set connect() as above, and while it does not produce an error, it looks like it just stops when it tries to bind. Just sits there pretty much forever.

In the second case, yes I have been running the test script at the CLI, but I can only see one PHP config and php.ini.

One confounding factor is that in Redhat 6 some of the auth functions are rearranged such that:

/etc/ldap.conf is obsolete, superceded by nslcd (and nslcd.conf)
/etc/openldap/ldap.conf remains but has some overlapping directives (like tls_certdir) with the new nslcd.conf

In all cases, tls_certfile and tls_certdir in the conf files point to the same /etc/opendap/cacerts/(cacert.asc) location and file. There are some differences with the newer nslcd.conf; for example, it won't permit the older upper-case directives like TLS_CACERT.

To verify that our test script was indeed using the cert we thought it was, I set tls_reqcert to "demand" and saw that the test LDAP script succeeded. However, when I deleted/renamed /etc/openldap/cacerts/cacert.asc, the test script failed. That is what I'd expect.

When I repeat this exercise with the Drupal LDAP Server test (with TLS enabled) the result and failure message (including the slapd log messages) are the same in each case as in my original post. So the presence or absence of /etc/openldap/cacerts/cacert.asc does not appear to make any difference to the LDAP module server test. That makes me think it is looking elsewhere for a cert, but I can't guess where that may be.

For the moment, I am disabling TLS in the server config so I can pay attention to other things like group<->role synch, but I will try to get back to this (maybe downgrade to PHP 5.2) as we do want to make it work eventually.

(A side note: at times when I save server config, I see a message "Possible invalid format for Unique Persistent Attribute: The format may be correct for your ldap, but please double check." I see how this originates in ldap_servers/LdapServerAdmin.class.php, but can't discern what iot means yet or if it has any bearing. I'm guessing it is benign and just has to do with differences in 389-DS).



geste’s picture

I said:

"(A side note: at times when I save server config, I see a message "Possible invalid format for Unique Persistent Attribute:......)"

I see now how this is probably related to an unimplemented feature.

johnbarclay’s picture

"Possible invalid format for ... 'The format may be correct for your ldap, but please double check.". This warning is given when an ldap attribute name (cn, dn, mail, etc.) is checked to be within ldap standards. Active Directory and other LDAP implementations commonly break these standards, so your attribute name may be correct and still get this error.

I added this note to: [#1065900]

johnbarclay’s picture

Title: Server: Server test startTLS fails comnnecting to 389-DS » LDAP Server: Server test startTLS fails connecting to 389-DS
Category: bug » support

Unsure if this is a bug or not. But don't want to close the issue so changing to support issue.

johnbarclay’s picture

Status: Active » Closed (cannot reproduce)
squ1rr3l’s picture

I'm having this same issue, seems to be system related. I migrated a working Drupal installation from an Ubuntu server to Red Hat 6, and this error popped up and LDAP authentication fails.

I haven't found a solution at this point.

If I turn of the "Start_TLS" flag, it causes apache to seg fault:

[Wed Dec 05 16:15:49 2012] [notice] child pid 8549 exit signal Segmentation fault (11)
[Wed Dec 05 16:16:07 2012] [notice] child pid 8547 exit signal Segmentation fault (11)