LDAP User: Drupal to LDAP provisionning not working (invalid syntax) because of bad formated attribute array

I can confirm this is the problem

I traced the building of the "attribute" array to the "drupalUserToLdapEntry" method of the 'LdapUserConf' class.

Since this method seems hell bend to put arrays in every position in the "ldap_user_entry" array it returns , checking constantly "is_array" and replacing at times a previous value if it is not an array (

      if ($ldap_user_entry && isset($ldap_user_entry[$ldap_attr_name]) && is_array($ldap_user_entry[$ldap_attr_name]) && isset($ldap_user_entry[$ldap_attr_name][$ordinal]) ) {
        continue; // don't override values passed in;

in the foreach ($mappings as $field_key => $field_detail) loop

or

         if (!isset($ldap_user_entry[$ldap_attr_name]) || !is_array($ldap_user_entry[$ldap_attr_name])) {
            $ldap_user_entry[$ldap_attr_name] = array();

a few lines below, I assumed It was on intend.

Either because some version of ldap or php_ldap behaves like this or because some other places in the code requires this format.
Since I don't have a proper test bed I hacked quickly a nasty function that does some clean up job on the array before returning it and added

$ldap_user_entry = _cleanup_ldap_entry_descriptor($ldap_user_entry);

before the drupal_alter('ldap_entry', $ldap_user_entry, $params); call and it solved the problem.
The function :

/**
    Hack fucntion that clean up the ldap_entry_desc array  to avoid arrays where not needed i.e. when the element is not multi valued.
    see : http://drupal.org/node/1989018
    **/
    function _cleanup_ldap_entry_descriptor($ldap_entry_descs){
      foreach ($ldap_entry_descs as $field_key => $field_detail) {
        if (is_array($field_detail) && count($field_detail)==1) {
            $ldap_entry_descs[$field_key]=$field_detail[0];
        }
      }
      return $ldap_entry_descs;
    }

My final drupalUserToLdapEntry method looks like this

  function drupalUserToLdapEntry($account, $ldap_server, $params, $ldap_user_entry = NULL) {
  //debug('call to drupalUserToLdapEntry, account:'); //debug($account); //debug('ldap_server'); //debug($ldap_server);
  //debug('params'); //debug($params); //debug('ldap_user_entry');//debug($ldap_user_entry);
    $provision = (isset($params['function']) && $params['function'] == 'provisionLdapEntry');
    $result = LDAP_USER_PROV_RESULT_NO_ERROR;
    if (!$ldap_user_entry) {
      $ldap_user_entry = array();
    }

    if (!is_object($account) || !is_object($ldap_server)) {
      return array(NULL, LDAP_USER_PROV_RESULT_BAD_PARAMS);
    }
    $watchdog_tokens = array(
      '%drupal_username' => $account->name,
    );
    $include_count = (isset($params['include_count']) && $params['include_count']);

    $direction = isset($params['direction']) ? $params['direction'] : LDAP_USER_PROV_DIRECTION_ALL;
    $prov_events = empty($params['prov_events']) ? ldap_user_all_events() : $params['prov_events'];

    $mappings = $this->getSynchMappings($direction, $prov_events);
     //debug('prov_events'); //debug(join(",",$prov_events));
  //  debug('mappings'); debug($mappings);
      // Loop over the mappings.
    foreach ($mappings as $field_key => $field_detail) {
      list($ldap_attr_name, $ordinal, $conversion) = ldap_servers_token_extract_parts($field_key, TRUE);  //trim($field_key, '[]');
      $ordinal = (!$ordinal) ? 0 : $ordinal;
      if ($ldap_user_entry && isset($ldap_user_entry[$ldap_attr_name]) && is_array($ldap_user_entry[$ldap_attr_name]) && isset($ldap_user_entry[$ldap_attr_name][$ordinal]) ) {
        continue; // don't override values passed in;
      }

      $synched = $this->isSynched($field_key, $params['prov_events'], LDAP_USER_PROV_DIRECTION_TO_LDAP_ENTRY);
    //  debug("isSynched $field_key: $synched");
      if ($synched) {
        $token = ($field_detail['user_attr'] == 'user_tokens') ? $field_detail['user_tokens'] : $field_detail['user_attr'];
        $value = ldap_servers_token_replace($account, $token, 'user_account');

        if (substr($token, 0, 10) == '[password.' && (!$value || $value == $token)) { // deal with empty/unresolved password
          if (!$provision) {
            continue; //don't overwrite password on synch if no value provided
          }
        }

        if ($ldap_attr_name == 'dn' && $value) {
          $ldap_user_entry['dn'] = $value;
        }
        elseif ($value) {
          if (!isset($ldap_user_entry[$ldap_attr_name]) || !is_array($ldap_user_entry[$ldap_attr_name])) {
            $ldap_user_entry[$ldap_attr_name] = array();
          }
          $ldap_user_entry[$ldap_attr_name][$ordinal] = $value;
          if ($include_count) {
            $ldap_user_entry[$ldap_attr_name]['count'] = count($ldap_user_entry[$ldap_attr_name]);
          }

        }

      }

    }

    $ldap_user_entry = _cleanup_ldap_entry_descriptor($ldap_user_entry);
    /**
     * 4. call drupal_alter() to allow other modules to alter $ldap_user
     */

    drupal_alter('ldap_entry', $ldap_user_entry, $params);

    return array($ldap_user_entry, $result);

  }

This is not a proper solution, but I need some other people input or the maintainer input to understand the why of format the function was returning and the implication of rewriting the drupalUserToLdapEntry method before doing it.

I will try to see if I have side effects in the next few days.

Ok
I can confirm that the proper format for OpenLDAP seems to not have "array" everywhere but only on multivalue attributes.

My hack has ugly sides effects (if you put only one value in a multivalued property like objectClasss, it will remove the sub array, incorrectly that time) and I'll "rewrite" the drupalUserToLdapEntry method to that effect soon.
My fear is that different LDAP server (AD comes to my mind) expect different formats ...

Before doing that, I try to have something working and I am banging my head on understanding the magical first line in the "provisioning from drupal to LDAP mapping" of the user tabs

"cn=[property.name],ou=users,dc=xxx,dc=com"

WHAT is "property.name" the name of WHAT property, this is driving me insane at the moment.

Edit

through trial and errors I figured that "property" was the user object in that case and a way to access its fields, property.name is thus the user.name, property.uuid is the user.uuid if you have the uuid module (and you definitely should), etc ... Not sure what the difference is with the "pre constructed" tokens (like "property : email") though and if "property" can represent some other entity in some other cases.

My current trouble is that each time I rename a user in Drupal a new one is created in the LDAP, I tried to give the "Persistent and Unique User ID Attribute" a value ([employeeNumber] seemed perfect) but this does not seem to be used to fetch the user.

I suspect I must change my directory structure so that the dn contains the userID but honestly this is becoming a crazy chase for sanity ;)

The goal seemed simple : declare an attribute to contains a unique identifier, use it to fetch and check existence of a record under the given branch, retrieve, update or delete in sync with Drupal that record .... but well I can't get it to work ATM.

ok ugly patching is a bad habit.

I made the modifications to not generate arrays on every attributes but only in entries that maps to multivalued attributes has hinted by the fact that they have a :number syntax has in [objectclass:0]

It should by the way be noted that such an attribute must have zero based consecutive index in it or the mapping will not work, i.e . [objectclass:0] and [objectclass:1] but not [objectclass:1] and [objectclass:2] or
[objectclass:0] and [objectclass:3], order of declaration in the mapping does not matter though.

The patch is attached (I am new to this and did not have the drupal_ldap directory under version control since those code modifications where not planned, so I made the diff "manually" with diff utility, not git).
Tell me is it is not correct.

Adding is correct now on OpenLdap, further testing is needed to see if it does not break with other LDAP servers.

I still have troubles with Drupal account renaming, the requested dn is the new one, it fails to find a match (obviously) and fallback into creating a new ldap entry with the new dn ...

The method synchToLdapEntry of the ldap_user_conf class was tweaking the attribute array to account for the old attribute structure (with arrays everywhere) and undo that.
Since the attribute array is now "properly" (as far as tests shows) formatted I removed that code from the method.

I also removed an error message that was logged when trying to read a non existent dn since it is not an error to do so and in fact the only way to know if an entry is present or not. (class LdapServer, read method, case LDAP_SCOPE_BASE).

A new patch is attached.
There are still a few (commented) "dpm" scattered around because I'm still trying to make this to work :

• On user account changes, currently the modules creates a new one first and then update the old entry.
• And I can't sync group membership / make work automatic group creation at the moment either