I've been using the LDAP Module for a while now, and just discovered a problem.

The way we want people to login to the Web site is using their LDAP username and password. This has been working like a charm for months.

Today I discovered that a user can also login using their e-mail address, which is based on their LDAP username, and their LDAP password. This generates some LDAP module errors, but it ends with the creation of an "external user" with a username equal to the individuals e-mail address. This account is separate from their regular LDAP-based account (i.e. I end up with two user accounts "jcool" and "jcool@mysite.com").

Based on my tests, what I think is happening is that when the LDAP module is authenticating, it's truncating everything after the "@" symbol, which yields it a valid username, but which eventually causes errors when some other part of the script tries to compare the full e-mail address to the LDAP attributes. It doesn't have to be a valid e-mail address; 'jcool@asdfasdfqawerds' also works.

My login procedure settings are:

* When logging in, Drupal will look up for the user on:
-- Drupal's own database. If it fails, will look on the LDAP directory

* Should Drupal account fields be mapped to LDAP attributes?:*
-- No attribute mapping will be done at all

* System type & user mapping:
-- eDirectory or Active Directory system
-- Base DNs: o=[my base DN]
-- UserName attribute: uid

On my test machine (running Drupal 4.6.5 with the latest version of the 4.6.x LDAP module) I get these messages in watchdog:

* Error: Zero or more than 1 user found with o=[my base DN]
* New external user: jcool@mysite.com using module .
* Session opened for jcool@ mysite.com

On my live site (running Drupal 4.6.6 with the December version of the LDAP module) I get LDAP read errors:

* Error: Zero or more than 1 user found with o=[my base DN]
* ldap_read(): Search: No such object in /home/org/[site]/public_html
* ldap_get_entries(): supplied argument is not a valid ldap result
* New external user: jcool@mysite.com using module .
* Session opened for jcool@mysite.com

Any thoughts on how to fix this?

Ken

CommentFileSizeAuthor
#2 ldap_integration_2.module38.13 KBpablobm

Comments

NukeHavoc’s picture

NukeHavoc commented

In looking through the code this morning, I found this section of the

function _ldap_integration_ldap_login($login_string, $pass) {
global $ldap;
$user = null;
// Strip name and server from ID:
if ($server = strrchr($login_string, '@')) {
$name = substr($login_string, 0, strlen($login_string) - strlen($server));
$at = '@';
$server = substr($server, 1);
}
else {
$name = $login_string;
$at = '';
$server = '';
}

I believe this is my problem child. By disabling the first section, and just using this bit...

$name = $login_string;
$at = '';
$server = '';

... I was able to prevent people form logging in using an e-mail address (since what the initial section was doing was scrapping a valid username from the email address). This solves my immediate problem, but I'd like to see a long term solution.

It seems to me that the flaw lies in whatever logic controls the "system type and user mapping" -- if it's set to "eDirectory or Active Directory system" it shouldn't even try to glean an account name from an e-mail address (or, if some people need that, then that should be a separate option).

IMHO, the _ldap_integration_ldap_login function needs to be checking which system type is in use before it tries the pattern matching approach.

What do you think?

pablobm’s picture

pablobm commented
Assigned: Unassigned » pablobm
StatusFileSize
new ldap_integration_2.module38.13 KB

Hi, first of all, sorry for the delay (as usual).

Second, you almost got it right. Right enough for me not to have to think it over too much, at least ;). Thanks for your effort.

The function that was really calling for some changes was ldap_integration_auth(), which is called just below the code you provided. I provide a new ldap_integration.module file along these lines so you can test it and tell if there's any problem I failed to spot.

NukeHavoc’s picture

NukeHavoc commented

Thanks -- I'll try this out ASAP.

liveoutloud2day’s picture

liveoutloud2day commented

pablobm,

I am trying to the exact same thing in 4.7(RC1) - I tried bring the code changes over and it didn't help - now I can't login at all. Does this feature work with 4.7 already, and I just have something set up wrong? It would be nice using Active Directory that a person could use username or username@domain.tld and it map to the same user account in drupal. If it had worked, I would have uploaded my modified ldap_integration.module, but alas...

Thanks!

liveoutloud2day

NukeHavoc’s picture

NukeHavoc commented

I tried your updated code and it solved this problem beautifully. Users in LDAP can login, but those trying to use their e-mail address can't. Thanks!

NukeHavoc’s picture

NukeHavoc commented

I spoke too soon. If someone tries to login using their e-mail address (e.g. joe@cool.com), it won't work.

However, if they try and login using their username plus an at (@) symbol (e.g. joe@), then they generate the following errors:

warning: ldap_read(): Search: No such object in /home/org/[sitename]/public_html/modules/ldap_integration/LDAPInterface.php on line 173.
warning: ldap_get_entries(): supplied argument is not a valid ldap result resource in /home/[sitename]/public_html/modules/ldap_integration/LDAPInterface.php on line 174.
warning: Cannot modify header information - headers already sent by (output started at /home/[sitename]/public_html/includes/common.inc:384) in /home/[sitename]/public_html/includes/common.inc on line 192.

While all these errors are happening, it also creates an account with the username and an "@" symbol, e.g. jcool@ is now a username.

In watch dog, I get these errors:

Error: Zero or more than 1 user found with o=[dn]
ldap_read(): Search: No such object in /home/[sitename]/public_html
ldap_get_entries(): supplied argument is not a valid ldap result
New external user: itsblog@ using module.

Ouch. I am using the 'eDirectory or Active Directory system' option.

liveoutloud2day’s picture

liveoutloud2day commented

If you are using 4.7, I created a patch to make both username and username@domain.tld map to just username for authentication. Check it out here - http://drupal.org/node/61866 It may not be that tough to back port it into 4.6 if someone wants to do it.

liveoutloud2day

pablobm’s picture

pablobm commented
Priority: Critical » Normal
Status: Active » Reviewed & tested by the community

NukeHavoc: The "jdoe@" case is a very special one, so I just added a check for it.

liveoutloud2day: Regarding the NTLM patch, my problem is I don't have any software for testing it, so it's very difficult for me to include AD-related stuff in the code :( . This really bugs me, but I'll try to see if I can do something with your code.

Big thanks to both of you

NukeHavoc’s picture

NukeHavoc commented

Sorry, I'm not seeing the patch file. Did you add it to the thread?

pablobm’s picture

pablobm commented

Sorry about that NukeHavoc. I just published a new version with that change. Download the full package now and confirm it works, please.

NukeHavoc’s picture

NukeHavoc commented

Where did you post the update to? I just downloaded the 4.6 package, but the most recent file in there (ldap_integration.module) is timestamped 1/13/06.

NukeHavoc’s picture

NukeHavoc commented

nevermind -- I forgot that spot wasn't downloading correctly. I snagged it from the link on the full module page.

pablobm’s picture

pablobm commented
Status: Reviewed & tested by the community » Fixed
  1. CVS is back. Wiki downloads no more.
  2. I just commited the new version to CVS. Within the next 24 hours, this should be downloadable from the project page. This bug should be solved in it.
  3. thanks :)
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)