LDAP Profile: Not syncing ldap fields to user profile fields

patches are welcome on this one. I'm working on the 2.0 branch currently where the ldap_profile module is replaced by ldap_user with a may 15 deadline. Its unlikely I will get to this one.

I'm not familiar with the ldap_profile module at all. Sorry.

I encountered this issue as well. I fixed it by checking if the user had authenticated via LDAP with ldap_authentication_ldap_authenticated(), but now I think that is a regression of #1532084: LDAP Profile: Error when ldap_profile enabled without ldap_authentication. It looks like it was expecting ldap_authentication to save some information in $account->data (I have ldap_authorization enabled and it does this). Otherwise I'm not sure how it would know the current user has an entry in LDAP (unless we just try to look up the user if there are LDAP servers?).

Anyway, this is what seems to be working for me in beta10 before I gave it as much thought as I just wrote above. Probably not patch worthy yet since it regresses the other fix and I probably should loop through the servers instead of just grabbing the first one (but I'm not currently setup to test that).

ldap_profile.module (beta10, starting at line 86)

  if (ldap_authentication_ldap_authenticated($account)) {
    $sids = array_keys($servers);
    $sid = $sids[0];
    if (isset($servers[$sid])) {
      $server = $servers[$sid];
      $ldapuser = TRUE;
      $ldap_user = $server->user_lookup($account->name);
      if (array_key_exists('dn', $ldap_user)) {
        $dn = $ldap_user['dn'];
      }
    }
  }

Patch gets field update working.

Summary of changes:
Adds

• a getAttributeValue util method to LdapServer class to simplify grabbing a value from the entry.
• Adds a getSynchMappings util method to LdapUserConf class to simplify fetching mappings for a server id.
• Adds a getRequiredAttributes util method to LdapUserConf for use in ldap_user_ldap_attributes_needed_alter so that appropriate attributes needed for the sync are requested
• Logic to loop over mappings and add them to the $edit user edit values
• Moved logic from hook_user_update and hook_user_insert to hook_user_presave, ensuring field api responds to our changes to $edit and simplifying code (presave is called for both insert and update)
• Some minor coding cleanup - these really belong in a new ticket to keep the diff clean, limited them here for simplicity
• Added hook_ldap_user_edit_user_alter - allows other modules to react to user sync operations with appropriate context
• Included hook signature in the ldap_user.api.php file
• Added final sanity check code to make sure user's config of sync fields did not inadvertently remove mail from user account.

Re-roll against 2.x

Thanks. I applied this and it all looked good to me. When you get a chance, confirm that its working for you. I changed this to a task to make sure simpletest coverage is finished for this at some point.

John
New 2.x dev version tests fine for syncing to fields on the user entity FROM ldap.
Marking back to active for tests.

Thanks
Will try and catch you next week to discuss next steps.

For 7.x-1.x: This will loop through the servers. I'm not sure what to do about the regression of issue #1532084: LDAP Profile: Error when ldap_profile enabled without ldap_authentication, though. Thanks, smsearcy.

  if (ldap_authentication_ldap_authenticated($account)) {
    foreach ($servers as $server) {
      $ldapuser = TRUE;
      $ldap_user = $server->user_lookup($account->name);
      if (isset($ldap_user) && array_key_exists('dn', $ldap_user)) {
        $dn = $ldap_user['dn'];
        break;
      }
    }
  }

From what i can tell fropmt he comments above 2.x is fixed on this issue? switching to 1.x and review if this is the case.

#4 may not be patch worthy but it got the job done for me and i tried migrating to 2.x but wanst able to get things inline. Attached patch for similarly adventurous souls that don't care about the regression i suppose.

Yeah. This is fixed in 2.0, but 2.0 is still unstable.

I would stay away from the 2.0 branch for the short term unless are testing or need features not in 1.0. Here is a thread on the 2.0 branch which has a rewrite of provisioning to and from ldap in the ldap_user module. #1622942: LDAP User: Ldap Provisioning in LDAP 7.x-2.x Branch General Discussion thread

Also there will be a update script for 7.x-1.x to 7.x-2.x but only for the release candidates, not beta to dev.

John note my patch above was not case agnostic, ie user fields on ldap may not match case of fields entered in mapping. Will re-roll fix for case-agnostic attributes.

Patch is for 2.x
Adds case agnostic attribute mapping.

in 7.x-2.x-dev this is dealt with as follows in order to dealt with the [:;] syntax of the tokens.

I think the equivelent change would be:

- $attr_name = $parts[0];
+ $attr_name = ldap_server_massage_text($parts[0], 'attr_name', LDAP_SERVER_MASSAGE_TOKEN_REPLACE) ;

to the following code. Does this make sense?

function ldap_servers_token_extract_attributes(&$attribute_maps,  $text) {
  $tokens = ldap_servers_token_tokens_needed_for_template($text);
//  dpm("ldap_servers_token_extract_attributes,text=$text, tokens needed="); dpm($tokens);
  foreach ($tokens as $token) {
    $token = str_replace(array(LDAP_SERVERS_TOKEN_PRE, LDAP_SERVERS_TOKEN_POST), array('', ''), $token);
    $parts = explode(LDAP_SERVERS_TOKEN_DEL, $token);
    $ordinal = (isset($parts[1]) && $parts[1]) ? $parts[1] : 0;
    $attr_name = $parts[0];
    $source_data_type = NULL;
  
    $parts2 = explode(LDAP_SERVERS_TOKEN_MODIFIER_DEL, $attr_name);
    if (count($parts2) > 1) {
      $attr_name = $parts2[0];
      $source_data_type = $parts2[1];
    }
   // dpm(@$attributes[$attr_name]);
    $attribute_maps[$attr_name] = ldap_servers_set_attribute_map(@$attribute_maps[$attr_name], $source_data_type, NULL, array($ordinal => NULL));
   // dpm($attributes[$attr_name]);
  }
 // dpm('ldap_servers_token_extract_attributes, final:'); dpm($attributes);

}

This patch is more to do with the attribute names entered by the admin in the mapping screen. The field sync code looks for the exact case they enter, but this is not correct. Does the massage text code deal with that too?

yeah. the massage code is just a way of being consistent about case sensitivity. it could just as easily be drupal_strtolower for many cases, but I wanted to have a function that clarified how case sensitivity was being dealt with.

Hi Guys,

how can I make this work with version 7.x-1.0-beta12? I'm not yet confident enough to go dev on a production environment and the code between the 1-dev and 1-beta is quite different.

Best,
Denix

A final patch for the 7.x-1.x-dev version would be helpful, but I don't plan to do any work on 7.x-1.x-dev except applying patches and backporting easy backports.

No feedback, closing.