(I posted this as a comment on the Docs page as well, then realized this is where it belongs...)

I am not having any success with the Drupal LDAP integration module. I have been trying on and off for the past few months. When I saw these new and much improved docs, I thought I would finally be able to get Drupal integrated with our Active Directory. Unfortunately, even the new docs do not seem to get me any further ahead:

Drupal is on a WAMP setup; Windows 2003 Server, Apache 2.2, MySQL 4, and PHP 5. I have been able to connect other web applications to our Active Directory without issue. For example, I have been able to use Bugzilla's ldap integration to allow our users single sign on without a problem. I know it is written in Perl and not PHP, but the point is that all the DNs, OUs, and sAMAccountName I am using for Drupal LDAP integration, are the same I am using for the Bugzilla install. They work for Bugzilla LDAP Integration, but not for Drupal LDAP Integration.

The LDAP Support is enabled in PHP; the following is from phpinfo():

ldap
LDAP Support: enabled
RCS Version: $Id: ldap.c,v 1.161.2.3.2.3 2007/01/05 15:06:55 iliaa Exp $
Total Links: 0/unlimited
API Version: 2004
Vendor Name: OpenLDAP
Vendor Version: 0

Here are (similar) settings to my actual LDAP info:

Configure LDAP Server
Server Settings: Activated
Name: serverNameLDAP
LDAP Port: 636
Use TLS encryption: checked
Store passwords in encrypted form: unchecked

Login Procedure
Do not store users' passwords during sessions: checked
When logging in, Drupal will look up for the user in LDAP directory only
Base DNs:
DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain
UserName attribute:sAMAccountName

Advanced Configuration
DN for non-anonymous search:
CN=userName,OU=orgUnit3,OU=orgUnit2,OU=orgUnit1,DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain
Password: userName's password

With the above settings, Drupal then logs this error:

ldap_start_tls() [<a href='function.ldap-start-tls'>function.ldap-start-tls</a>]: Unable to start TLS: Can't contact LDAP server in C:\www\drupal\sites\all\modules\contrib\ldap_integration\ldap_integration\LDAPInterface.php on line 121.

If I use port 636 without TLS, I get the following error:

LDAP Bind failure for user CN=userName,OU=orgUnit3,OU=orgUnit2,OU=orgUnit1,DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain. Error 81: Can't contact LDAP server.

If I use port 389 without TLS checked Durpal does not log any bind errors, but simply states:

Login attempt failed for <em>domainUser</em>: %error.

The user in the log file for this failed login attempt is registered as Anonymous.

If anyone has any ideas, suggestions, and or guesses as to what it is I am doing wrong, it would be very appreciated.

Thanks

CommentFileSizeAuthor
#9 ldaptest.php__0.txt1.48 KBdc45
#1 ldaptest.php_.txt1.35 KBkreaper

Comments

kreaper’s picture

kreaper commented
Assigned: Unassigned » kreaper
StatusFileSize
new ldaptest.php_.txt1.35 KB

Sorry to see that you are having issues. Help is here. We'll get you there, don't worry.

To clarify port/tls issues, here are the three combinations that are possible

  1. port 389 and TLS unchecked -- means NO encryption will be performed
  2. port 389 and TLS checked -- means to channel both secure and plain requests on a single connection (on demand)
  3. port 636 and TLS unchecked -- means all traffic is encrypted

    4. The following is NOT a valid combination

  4. port 636 and TLS checked

I have attached a ldaptest.php. You can use that to check the AD-PHP-LDAP settings. This will run outside of drupal so it will be helpful for other projects as well :)

This script should tell you which setting will definitely work -- (keeping the port at 389, find out what TLS setting will work. For AD 2003, both should work).

The next question is why is the user set to anonymous. When you go back to the Advanced configuration, do you see the DN filled in with the "Clear current password" box available ?

let me know.

kpm’s picture

kpm commented

Yes, when I go back to the Advanced configuration, the DN is filled in and the "Clear current password" box is available. I have cleared and reset, tried stripped down user accounts, and even myself, but still get the same errors in the log.
Thanks for the help!

kreaper’s picture

kreaper commented

Did the ldap test script help you at all ?
Did you establish which settings work ?

Also if I understand your posting, After setting 389 and unchecking, you are getting the LDAP error

Login attempt failed for domainUser: %error.

is domainUser=anonymous or domainUser=

kreaper

kpm’s picture

kpm commented

Hi, sorry I got sidetracked with other work yesterday and neglected to run the ldaptest.php script. Just did that now though and received the following:

LDAP query test
Connecting ... connect result is Resource id #2
Binding ... Starting TLS... Cannot start TLS Bind result is
Searching for samaccountname=* ...Search result is
Number of entires returned is
Getting entries ...
Data for items returned:
Closing connection

I ran it as provided and then edited the variables at the top, each time, same results. I used an IP for host, severName, and the server's fqdn as well. Here are the changes I made:

$host = "serverName.thirdLevelDomain.secondLevelDomain.topLevelDomain";
$port = "389";
$tls = false;
$dn = 'CN=userName,OU=orgUnit3,OU=orgUnit2,OU=orgUnit1,DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain';
$pass = 'password';
$base = "DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain";
$scope = "sub";
$filter = "samaccountname=*";

With regards to your last question that is correct. Here is what Drupal logs after an attempt to login as a domain user:

Type: user
Date: Tuesday, February 27, 2007 - 09:12
User: Anonymous
Location: http://serverName/node?destination=node
Referrer: http://serverName/
Message	Login attempt failed for <em>domainUser</em>: %error.
Severity	notice
Hostname	10.40.30.33

So it appears I am not able to get Drupal connecting with the AD at the "DN for non-anonymous search" user and password level. But I use the exact same "non-anonymous search" user with the AD integration with Bugzilla, and it works there.
Thanks

kpm’s picture

kpm commented

Any other ideas??

Thanks

murph1379’s picture

murph1379 commented

I had the same problems you're describing, and I got it to work... here's how:

port: 389
TLS: off
base DNs: cn=Users,dc=example,dc=com

and *the key*, the bind DN: ldapreaduser@domain.com

kpm’s picture

kpm commented

Glad to hear it is working for you. I wish I could say the same, but that combination has not, and still does not work on our network... I just tried again from scratch after giving it a rest for a week or two... maybe I was getting a typo in there some where?? But then again, that is hard to do when you are copying and pasting from an LDAP browser or a dsquery command... maybe it is because we have two domain controllers... I honestly don't know and am bone dry out of ideas...

kpm’s picture

kpm commented
Title: LDAP Bind failure for user... » PROGRESS!!!

Ok, literally on the verge of giving up, I uninstalled and reinstalled the module... No luck, same outcomes... Then I created another user in one of the Organizational Units (OU) within another OU. I then edited the base DN from:
DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain
to:
OU=orgUnit1,DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain
I was then able to make a connection with a user withing orgUnit1 or any sub OUs within orgUnit1.
However, I still could not connect with a user at a higher level base DN, which is not surprising considering the change I made. But at least I could connect! So, it seems I have to add multiple DNs at the first level down from the base DN to make it work.
What a relief.
So now my base DN is not really the base DN (as I understand or misunderstand it...), but a series of OUs within it like so:

OU=orgUnit1,DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain
CN=orgUnit2,DC=thirdLevelDomain,DC=secondLevelDomain,DC=topLevelDomain

Thanks for all the input everyone!

dc45’s picture

dc45 commented
StatusFileSize
new ldaptest.php__0.txt1.48 KB

I am having the same issue as kpm with nearly the exact same setup (using mysql 5)

I was unable to get the test script to work until I added this:

ldap_set_option($ds, LDAP_OPT_REFERRALS, 0);

I added this line to initConnection method in the LDAPInterface.php file. Still didn't work...

The only error message that I receive is:

Login attempt failed for <em>user</em>: %error.

Thank you for any assistance that may be given...

scafmac’s picture

scafmac commented

dc45,

I'm running a half dozen drupal sites with LDAP. One new one I set up was having problems authenticating users. I was just about to toss the site since I had already setup a replacement version when I saw your last post. So instead of tossing it, I kept tracking the problem in case it was the same as yours - very similar in that there were no ldap errors, only a Login attempt failed error.

So I tracked my problem back to a space at the end of the uid setting - so instead of sAMAccountName I had sAMAccountName   on the server settings page. Notice the extra space? This is passed to AD as part of the filtering. I'm not sure if other rogue spaces will cause similar problems, but you should check all of your settings for such a rogue space. I'm going to post a bug about this.

Let me know if this solves your problem.

dc45’s picture

dc45 commented

scafmac,

You nailed it. Once I removed the space after the sAMAccountname it worked.

I have been literally bashing my head against the wall for two days now just to find out an extra space was the problem.

Thank you again!

stevenpatz’s picture

stevenpatz
he/him
commented
Title: PROGRESS!!! » LDAP Bind failure for user...
dc45’s picture

dc45 commented

As a follow up to my original post...

After scafmac pointed me towards the rogue space on the ldap filter, I went back and undid my change which was adding the follwoing line to the LDAPInterface.php file.

ldap_set_option($ds, LDAP_OPT_REFERRALS, 0);

I was unable to login again. I added the line back in and then I was successful.

I found this bug report with some interesting information about Windows 2003 and the PHP LDAP library. It seems this option needs to be set to get this to work.

emdalton’s picture

emdalton commented

I am having similar problems. I have Drupal 5.1 on LAMP (Ubuntu). I believe the LDAP server is on Win2003. My LDAP Auth configuration looks like this:

LDAP server: as provided by my server admin
LDAP port: 389
No TLS encryption, no storage of encrypted passwords
I don't store user's passwords
I authenticate against both Drupal and LDAP (because LDAP isn't working yet)
Base DNs: cn=Users,dc=,dc=edu (no spaces)
UserName attribute: sAMAccountName (no trailing spaces, I checked)
DN for non-anonymous search: I have tried a variety of approaches using my own login, including
username
AD\username
username@univ.edu
cn=username,dc=,dc=edu
nothing (with password cleared)

Regardless of the DN entered here, I get "Sorry. Unrecognized username or password. Have you forgotten your password?" on the Drupal page, and "LDAP Bind failure for user . Error 49: Invalid credentials". It doesn't matter what I use for the drupal login, I get the same error. The only exception is if I put nothing in the advanced configuration and clear the password; in that case I get a simpler "Login attempt failed for username: %error."

According to what I see here: http://lists.fsck.com/pipermail/rt-users/2006-June/039716.html
the bind failure/invalid credentials error is a result of connecting to the server, but not having correct credentials for the DN login/password (what's in the Advanced Configuration section), rather than anything to do with what the user types into the Drupal login box, and my experiments seem to confirm that. For example, if I change the port number to 636, I get "LDAP Bind failure for user cn=username,dc=univ,dc=edu. Error 81: Can't contact LDAP server". If I check TLS I get "ldap_start_tls() [function.ldap-start-tls]: Unable to start TLS: Can't contact LDAP server in /var/www/apache2-default/drupal-5.1/sites/all/modules/ldap_integration/ldap_integration/LDAPInterface.php on line 121." and "Could not start TLS. (Error 81: Can't contact LDAP server)."

I conclude from all this that my overall address, ports, and Base DNs are fine, but the system is failing on the DN for non-anonymous search. Yet I am using a known good login and password. Does anyone have any further suggestions? Thanks.

emdalton’s picture

emdalton commented

Sorry, I used some angle brackets in the preceding post. Rest assured, the dc= with nothing after it has something after it.

scafmac’s picture

scafmac commented

Two things.
- Try with no encryption on port 389 (since it was the only one that didn't throw an error binding - does your ldap server have encryption enabled?) and make sure there is no space at the end of the user attribute name (samaccountname) which would cause the authentication of the user to fail with no bind errors;
- Download the latest version of ldap_integration - fixes a few bugs including the rogue whitespace previously mentioned;

I assume that it is actually an AD server running on windows, not LDAP? Otherwise the user attribute is probably wrong.

emdalton’s picture

emdalton commented

Here's what finally worked, after some discussions with our LDAP admin folks:

LDAP port: 636 (389 also works, but is less secure)
Base DNs: cn=Users,dc=*univ*,dc=edu (where *univ* is our university domain name)
UserName attribute: cn

Our LDAP server does allow anonymous searches, so I didn't need any values there. The trick is that we have both AD and LDAP, and I thought they were more tightly integrated than they are in our environment, so I needed to be using non-AD settings and a different login and password combo than I had been assuming. Just thought I'd share that, in case it helps someone else.

bubreg’s picture

bubreg commented

I had the same problem, the solution was not to use fqdn in bind user name. Instead of giving OU=unit,CN=ldapuser,DC=sample put ldapuser@sample in this field.

kreaper’s picture

kreaper commented

Is this issue closed ? This seems to be specific to an AD implementation. There is nothing in the code that needs to be changed, as I understand ..

kpm’s picture

kpm commented
Status: Active » Closed (fixed)
fireplus’s picture

fireplus commented
Version: 5.x-1.1 » 5.x-1.3

|I just start with Drupal , I am still having the same problem with (kpm) , my development env is PHP5.2 , Apache2.2 , MySQL5 and windows XP , taking into considration that i have LDAP auth working with other application i.e: (Knowledge Tree and OTRS)

my LDAP didn't required TSL auth
Allow for any mouse auth

i think the problem is with [ldap_bin();] function as per my tracing to source code ,
when i comment it in LDAPINTERFACE.php , i got the module working but with any password , and when i log in i found all information mapped succsfully from LDAP to Drupal which means that LDAP connect and search function is working without any problems

could some one please highlight what should be the soultion ?

i will try to trace source code , but i am still working in how to trace the code issue

by the way , kpm : do you perfrom any progress with your LDAP integration ?

kpm’s picture

kpm commented

Fireplus,
Yes, I did get LDAP Integration running. I have set it up a couple of times since this issue and everything works like a charm. There is an important security issue I discovered though. You must ensure that the first administrative user's user name is not the same as any distribution list name on the network. In my case, I made the first user's name 'admin' and it just so happened that we had a distribution list on the network with the same name. What happens is that virtually any combination of key strokes will work as the 'admin' user's password since a DL does not have a password.
Aside from that, all I can say is to grab the latest stable build and try again. I am not a coder so can't speak to any code trouble shooting.

johnbarclay’s picture

johnbarclay commented
Title: LDAP Bind failure for user... » Success on Mac OS X 10.4 PHP PHP 5.1.4 on Active Directory 2003 Server

Thanks to all. This thread was very helpful.
A little trial and error with the test script solved it for me. The test script makes trial and error easier and clarifies where the problem is occurring. My problem was the syntax of the DN for non-anonymous search.

LDAP Server: ad.uiuc.edu
LDAP Port: 389
Use Start TLS: true
Store Passwords: false
Base DNs: ou=ouraccountouname,dc=ad,dc=uiuc,dc=edu
Username Attribute: sAMAccountName
Email Attribute: mail
DN for non-anonymous search: cn=machinereadaccount,ou=machineaccounts,dc=ad,dc=uiuc,dc=edu

macgirvin’s picture

macgirvin commented

subscribe