ldap authentication on drupal 6

I have tried endlessly to get this to work and always get this error.

I am running the version 6.x-1.0-alpha2 of the module and Drupal version 6.6. I have all three ldap modules enabled and have plans to use the groups module if I can get the auth module to work.

warning: ldap_start_tls(): Unable to start TLS: Connect error in /web/www/websites/ibb/dev/modules/ldap_integration/ldap_integration/LDAPInterface.php on line 153.

Thanks in advance for any help that can be provided.

I empathize - what a hassle I've had. I come from a Linuxy world, and our company is Microsofty, so the tools and nomenclature were alien to me, though I understood the concepts. Fortunately, the problem was all about my own ignorance of our company's server configuration. With the right tools and information, and with significant help from a colleague, we were able to Make It Work.

We are still evaluating Drupal for our environment, so we're running it on a Windows XP installation of Apache and MySQL in an Active Directory environment. Later we will move it to a LAMP box.

LDAPAuth module requires information on the structure of the directory -- container and attribute nomenclature as "cn=,ou=,dn=" -- as well as a nonanonymous search account for LDAP queries. We created an AD account with the username "drupalsvc" specifically for this.

The main challenge was to determine the DNs required. We inherited our Active Directory setup, and it is very convoluted since it grew more or less organically. After that, it was a question of getting the correct syntax and qualified information -- what values to fill out for "cn=,dn=,dn=," etc -- to fill in the LDAPAuth module configuration with.

As we experimented, we kept running into the big, unhelpful error: "Username or Password not found." Examination of the Apache logs did not reveal any errors.

We knew some of our DN= values from our Active Directory Users and Computers console tool.

dn=ourcompanyname,dn=local

We tried configuring LDAPAuth to use this as our non-anonymous user account for LDAP queries: CN=drupalsvc,OU=users,DC=ourcompanyname,DC=local

We continued to get the "Username or password not found" error when logging into Drupal with an AD user account. We suspected we were using the wrong CN=,OU=,etc information for the configuration.

Our strategy was to run a query against a known user in order to learn the DNs and values for that one user. We chose the drupalsvc user since we had just created it and so already knew all about it. We could use that information as a template to fill in the configuration info that LDAPAuth required. Our main diagnostic tool was a Windows command line utility called "dsquery." (We used a lot of "dsquery /?" to learn more about how to use the tool.)

We began by querying the drupalsvc account object directly:

C:\>dsquery * "CN=drupalsvc,OU=users,DC=ourcompanyname,DC=local" -scope base -attr *

dsquery failed: Directory object not found.

We knew the object existed in the Users container, so the error surprised us. We used dsquery to find the object by scanning the directory:

C:\>dsquery user -name drupal*
"CN=Drupal Service Account,CN=Users,DC=ourcompanyname,DC=local"

Ahha! This shows that we were using the wrong information in our first query. We had used the username, but the CN= syntax was expecting a full name: note "Drupal Service Account".

We queried the drupalsvc account directly with our new information, using a full name instead of a user id:

C:\>dsquery * "CN=Drupal Service Account,CN=Users,DC=ourCompanyName,DC=local" -scope base -attr *

We got back a list of all attributes plus the values, so we were in business.

In the end, this was our LDAPAuth module configuration:

Server Settings:
* LDAP server:  ourActiveDirectoryControllerName.ourCompany.local
* LDAP Port: 389
* Start-TLS: no 
* Store passwords: no

Login Procedure:
* Base DNs:  dc=ourCompanyName,dc=local
* UserName Attribute: sAMAccountName  (We saw this in the dsquery results, which was reassuring.)
* Email Attribute: email (Ditto)

Advanced Configuration:
* DN for non-anonymous search: CN=Drupal Service Account,CN=Users,DC=ourCompanyName,DC=local

At this point we were able to log in with any regular user account.

We will add TLS to our configuration once we move to production. At the moment, we get PHP errors while trying to connect to it.

Hope this helps. Feel free to contact me.
Cameron Goble
Albuquerque NM USA

Same issue. NOTE: FOR ALL who just realized they needed PHP-LDAP installed and went and apt'd it, YOU MUST RESTART APACHE after it's installed, or you will continue to see the same "undefined" error for ldap auth itself.

LDAP auth seems to be working, but throws about a dozen lines of this error:
warning: ldap_start_tls() [function.ldap-start-tls]: Unable to start TLS: Connect error in /var/www/sites/all/modules/ldap_integration/ldap_integration/LDAPInterface.php on line 153.
I would really need the connection to the server - in this case an AD server on Win2k3 - to be encrypted, not throwing everyone's uname/pw over the net in the clear.

Note also that we have an RT install also authenticating via TLS to the same AD server, and it is working.
Any progress on this issue? Any info that would be helpful to you?

edit: has anyone gotten the Groups function to work? Won't seem to assign roles based on LDAP group from AD OUs at the moment, either.

I got same, I tried to contact hosting to fix it, they told me that I should fix it my self :(

For my Acquia Drupal installation (theme = Acquia marina) I decided to have a wysiwyg editor and I add the CKeditor module.
When configuring a new LDAP sever you need to enter one or more valid base DNs.
In my Drupal installation the field for enter the Base DNs was handled by default with the CKeditor.

The CKeditor add a couple of tag

considering the row with the base DN value a paragraph, preventing the ldap_integration module to find the username in the Directory.

It happens also if you edit the server entry and save it again without changing the Base DNs field: the CKeditor apply the paragraph tag always when you save.

The same problem happens with other field of the ldap server form like
- PHP to filter users based on their LDAP data
- PHP to transform login name

To bypass this problem you can:
- use the option "Switch to plain text editor" below each of these fields (but remember to do it before every save, also if you don't change the value)
- tell the CKeditor to not handle this fields modifying the visibility settings in the CKEditor Global profile