I stated in Drupal that I only wanted LDAP authentication.
The issue is that at the first try it acts as expected, but when I retry with a user that shouldn't login, it does.
I tried to put some debug code in the scripts and ir runs fine at the first try, but at the second try it isn't invoked.
Thks

Comments

scafmac’s picture

scafmac commented

I believe I've encountered this bug in 5. I'm working on a patch for it.

Could you provide a little more info please.

When it "acts as expected", you mean an ldap user, with no prior drupal account, logs in and is automatically registered? Can that user logout and in again successfully?

When you try "a user that shouldn't login", do you mean a non-ldap user? Is the non-ldap test user a pre-existing Drupal account? If it wasn't pre-exisiting, did the admin user create the drupal account or did the non-ldap test user create their own account? If you edit the non-ldap user account as admin in drupal, are both the ldap authentication check box and dn empty?

Could you paste an example of some of the debug statements?

scafmac’s picture

scafmac commented
Assigned: Unassigned » scafmac

I believe I've encountered this bug in 5. I'm working on a patch for it.

Could you provide a little more info please.

When it "acts as expected", you mean an ldap user, with no prior drupal account, logs in and is automatically registered? Can that user logout and in again successfully?

When you try "a user that shouldn't login", do you mean a non-ldap user? Is the non-ldap test user a pre-existing Drupal account? If it wasn't pre-exisiting, did the admin user create the drupal account or did the non-ldap test user create their own account? If you edit the non-ldap user account as admin in drupal, are both the ldap authentication check box and dn empty?

Could you paste an example of some of the debug statements?

PedroA’s picture

PedroA commented

In my organizations this is what happens:

Users always exist in LDAP the first time.

There are 2 thinks that can happen:

- The user is authorized to access due to the 'memberOf' Attribute or is not authorized.
- When the user is authorized there is no problem, but when in spite of user is found in LDAP, the memberOf attributed is not in the 'allow list' do it shoud fail, and does. The problem is in this last case, when it fails, if you try to submit the user/pass, it logins but I think it doesn't uses the LDAP module, because I putted some debug msg and they are not printed.

Hope it helps,

aclight’s picture

aclight commented

I'm not sure if this is PedroA's problem, but one thing I've run into regarding using LDAP authentication in the past is that if a user logs into Drupal for the first time and the account is created via the LDAP module, the MD5 hash of the user's LDAP password (which is now also their Drupal password) is stored in the Drupal users table. If the user is then removed from the LDAP system, or their LDAP password changes, the user can still log in to the Drupal system because their username and password hash are stored in the Drupal system.

I created a patch to provide an additional option to the administrator to not store the password hash in the drupal database, thus fixing this problem. It was never committed, as far as I am aware. I believe that someone more recently created a similar patch for the 5.0 version, but I'm not sure if it was committed.

In any case, I think adding this option is important for those who want their LDAP database to always control who can log into a drupal system and with what password but who ALSO want the capability to create separate drupal-only accounts that are independent of any LDAP account.

AC

scafmac’s picture

scafmac commented

I've seen a couple of posts that address this in different ways, but you are right, I do not believe any were committed. I can't find the reference now, but the big question was whether to store no password locally, a random one, or have a setting that would specify whether an ldap user can login against drupal at all without effecting drupal accounts - sort of the converse of the default login order. It is the latter that I'm focusing, so it shouldn't matter whether drupal has an md5 of the real password or a bogus one, the user will not be able to authenticate against the drupal DB.

The login process choices would then be:

  • Drupal first, then LDAP
  • LDAP or Drupal
  • LDAP Only

I agree with you. Where we're using it here we need to control LDAP users quite differently than Drupal users. The patch I'm working on addresses that and provides other UI changes to both LDAP & Drupal. Hopefully I'll have it posted by early next week. Oh the bad news is it is a 5.0 patch and some of the functionality is not possible in 4.7 (AFAIK).

PedroA’s picture

PedroA commented

I found the following pattern:

If I always logon with invalid credentials (username or password), it works as expected.
If I logon with a valid username/password it gives me an error, but if I immediately after use the same username (it's enough the username), the user is logged.

There are a test I make to validate if the user belongs to a group using the 'memberOf' attribute after the line:
$user = _ldapauth_user_authenticate($form_values['name'], trim($form_values['pass']));
in ldapauth.module, after which I use the form_set_error function to handle this exception.
Might that be the problem?

Can you provide me the code of your patch, even in version 5?

Thanks,

PedroA’s picture

PedroA commented

Solved part of the problem by destroying the Global var user, in order to clear all persistence of previous logins.

deep’s picture

deep commented
Version: 4.7.x-1.0 » 5.x-1.3

I have the same issue with 5.x-1.3 version.

johnbarclay’s picture

johnbarclay commented
Status: Active » Closed (won't fix)

Closing 5.x issues to clean out issue queue.