The system worked at first and would pull down User DN and set it up to authenticate via LDAP. Now any new user, though they are allowed in (they weren't when I set the read/write password wrong) are not set up to authenticate via LDAP, have no user DN and of course don't have the right profile information because of this. It worked with one user at first but then stopped. I have it set up to use LDAP only. I then completely uninstalled the module and copied settings from another intranet Drupal site here at my company that has it working (i copied the settings via MySQL) and then asked another user to login. Again, his account was created but no LDAP info.

What could be the cause here? What other information do you need?

Comments

cridenour’s picture

cridenour commented

I wouldn't normally *bump* anything but this is plaguing me. I have the exact settings as another site using ldap_integration here in the company and one will create new users fine - the other will not. I have disabled, uninstalled, reinstalled and copied the settings over using SQL statements. They are quite literally the same.

Why would one site fill in the User DN and the other not?

cridenour’s picture

cridenour commented

Some more information - I was getting errors on the user.module because the external authentication was not passing along a role to user_access but a patch found here fixed those errors. So now with no errors (again) I cannot download LDAP settings. If I manually set them - still works. I can't log in without proper LDAP user/pass combo.

Please any acknowledgment of this issue would be appreciated. I don't know what else I can do.

cridenour’s picture

cridenour commented
Status: Active » Closed (fixed)

For some reason, 1.3 is incompatible with Securesite, causing errors in the user creation and stopping the whole process. May investigate later - for now, closing issue.

scafmac’s picture

scafmac commented
Category: support » bug
Status: Closed (fixed) » Active

Sorry for not responding sooner. It's not a big surprise considering what securesite does that there is a conflict. But if there is an easy fix, it would be worth addressing - I'm reopening & changing to bug report.

Thanks for pointing out the problem.

thierry.beeckmans’s picture

thierry.beeckmans commented

I noticed the same with new users BUT ALSO when they log in the second time I see that their profile fields gets filled.
My authentication system is both LDAP and Drupal though.

I tracked down the problem and noticed that the password, used to bind the user, gets hashed somewhere during the creation process and is stored in the session.
The second time the user logs in, the password doesn't get hashed and is stored, as written, in the session.

a quick fix is to change the following function in ldapdata.module: 

 function _ldapdata_edition(&$user) {  
  $ldap_config_name = $user->ldap_config;
  $ret[] = array('','');
  
  $result = db_fetch_array(db_query("SELECT ldapdata_binddn, ldapdata_bindpw FROM {ldapauth} WHERE name = '%s'", $ldap_config_name));
  $dn = $result['ldapdata_binddn'];
  $pass = $result['ldapdata_bindpw'];
    
  if ($dn) {
    $ret[0] = $dn;
  }
  else {
    $ret[0] = isset($_SESSION['ldap_login']['dn']) ? $_SESSION['ldap_login']['dn'] : '';
  }

  if ($pass) {
    $ret[1] = $pass;
  }
  else {
    $ret[1] = isset($_SESSION['ldap_login']['pass']) ? $_SESSION['ldap_login']['pass'] : '';  
    if (isset($_POST['form_id']) && isset($_POST['pass'])) {
      if ($_POST['form_id'] == ( 'user_login_block' || 'user_login' )) {
        $ret[1] = $_POST['pass'];
      }
    }
  }

  return $ret;  
  
}
cridenour’s picture

cridenour commented

I will test thierry's fix early this week and post my results.

Thierry, Was this only fixing your second problem or did this address all issues?

andytrek’s picture

andytrek commented

Hi,

I'm not sure this is related to this fix or a different one, but I downloaded version 5.x-1.3 and found a bug in the ldapdata.module.
The select statement in the _ldapdata_edition(&$user) function references columns that don't exist in the current table schema for ldapauth. The statement references ldapdata_binddn, ldapdata_bindpw but the table definition only contains binddn, bindpw.

I fixed the code on my side, but wasn't sure of the process to push it back to the community. Here's my code fix:

function _ldapdata_edition(&$user) {  
  $ldap_config_name = $user->ldap_config;
  $ret[] = array('','');
  //AZChange 2008-06-04 - select column names do not match table schema column names
  //$result = db_fetch_array(db_query("SELECT ldapdata_binddn, ldapdata_bindpw FROM {ldapauth} WHERE name = '%s'", $ldap_config_name));
  //$dn = $result['ldapdata_binddn'];
  //$pass = $result['ldapdata_bindpw'];
  $result = db_fetch_array(db_query("SELECT binddn, bindpw FROM {ldapauth} WHERE name = '%s'", $ldap_config_name));
  $dn = $result['binddn'];
  $pass = $result['bindpw'];
    
  if ($dn) {
    $ret[0] = $dn;
  }
  else {
    $ret[0] = isset($_SESSION['ldap_login']['dn']) ? $_SESSION['ldap_login']['dn'] : '';
  }

  if ($pass) {
    $ret[1] = $pass;
  }
  else {
    $ret[1] = isset($_SESSION['ldap_login']['pass']) ? $_SESSION['ldap_login']['pass'] : '';  
  }
   
  return $ret;  
  
}

Please let me know if there is a different location you would like me to post this info.

Cheers,
Andy

zetxek’s picture

zetxek commented
Assigned: Unassigned » zetxek
Status: Active » Needs review

I have had the same problem when retrieving the user info from the LDAP, using the same from that atrek used solves the problem.

johnbarclay’s picture

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