LDAP User: Not obeying configuration of user authenticating ldap server for provisioning and synching.

The problem seems to be that the synchMapping array has no key 'prov_events' excepting for for the manually mapped attributes, so in every other case $result is FALSE.

  public function isSynched($attr_token, $prov_events, $direction) {

    $result = (boolean)(
      isset($this->synchMapping[$direction][$attr_token]['prov_events']) &&
      count(array_intersect($prov_events, $this->synchMapping[$direction][$attr_token]['prov_events']))
    );

I can't claim to really understand the complexities of this module but I'll just keep on digging.

I'm not a programmer so I've struggled really hard to get my head around the module, but so far I haven't cracked this one. In fact I realise that this may not even be a bug, but an intended behaviour.

However at the end of the setSynchMapping() function $this->syncMapping looks as per the attached debug. And the properties with 'prov_events' elements such as field_given_name sync fine, whilst all the basic ldap properties such as ldap_user_current_dn don't. This is because the isSynched() function always returns FALSE for the basic ldap properties as they don't have the prov_events elements.

However I have failed to unravel why they don't - and if they are meant to .... despite my best efforts.

Any pointers appreciated.

I've just put some debug code into function ldap_servers_ldap_user_attrs_list_alter() and then attempted logon using a user account unkown to Drupal but within LDAP. All the invocations of the function have $params['ldap_server'] set to FALSE. As the function starts :

if (isset($params['ldap_server']) && $params['ldap_server']) {
    $ldap_server = $params['ldap_server'];
  }
  else {
    return; // without a server id, ldap_servers module has nothing to offer
  }

none of the subsequent code ever gets to execute.

Hope this helps.

John

Looking forward to having something to test.

Thanks and good luck

I successfully managed to apply the patch. I have 2 enabled LDAP servers, and provisioning is set to 'Use server which performed the authentication'. Unfortunately it results in the following message when I try to logon to the second domain I added :

"Server Error: Failed to create Drupal user account for ucvtest"

There is also a watchdog error generated saying :

"Failed to find or create ucvtest on logon."

Logging on with a user via the first domain still works.

If I swap all the code back to the beta8 version the login for exactly the same user is successful ( although the provisioning is not of course ).

Thanks John. I'll try it out tomorrow.

The patch applied successfully but with a strange result. Now when I click on the log in button having entered creds for a user that does not yet have a Drupal account the browser thinks it is downloading a file and a download dialog opens ( attached ).

I then reversed the patch and can immediately log in using the non-existent account.

Happy to try again.

Thanks

Sorry, but another side effect of the patch is that when I run Cron I get the following 2 errors :

Notice: Object of class LdapServer could not be converted to int in LdapUserConf->drupalAcctProvisionServerSid() (line 30 of C:\www\our-people-dev.falmouth.ac.uk\sites\all\modules\ldap\ldap_user\LdapUserConf.class.php).

Recoverable fatal error: Object of class LdapServer could not be converted to string in LdapUserConf->drupalAcctProvisionServerSid() (line 31 of C:\www\our-people-dev.falmouth.ac.uk\sites\all\modules\ldap\ldap_user\LdapUserConf.class.php).

Thanks John. I've successfully installed the patch and created a setup that authenticates against 2 separate LDAP domains. The Drupal user accounts are successfully created whichever of the 2 domains the authentication occurs against. The manually mapped attributes specified at 'admin/config/people/ldap/user' are successfully provisoned into the Drupal account whichever the source domain. However the hidden fields such as 'ldap_user_current_dn' remain empty in the case of both domains.

Does this help you ?

Actually I'm wrong. The patch didn't apply totally successfully. Hidden ( from me anyway ! ) in the patch output :

Patching file `ldap_servers/ldap_servers.functions.inc' using Plan A...
Hunk #1 FAILED at 380.
1 out of 1 hunk FAILED -- saving rejects to ldap_servers/ldap_servers.functions.inc.rej

Looks like the if statement doesn't exist in the 7.x-2.0-beta8 version of the code :

    function ldap_pear_hex2asc($string) {
        $string = preg_replace_callback(
          "/\\\([0-9A-Fa-f]{2})/",
          function ($m){
            return chr(hexdec($m[1]));
          },
          $string);

        return $string;
    }

Reject file renamed and attached.

I have now run the patch from #17 against ldap-7.x-2.x-dev and it applied successfully. However when logging on a string of errors ( undefined variable m ) were generated by the following statement in ldap_servers.functions.inc.

$f = create_function('$m', "return chr(hexdec($m[1]));");

I reverted function ldap_pear_hex2asc() to the version in ldap-7.x-2.x-dev and it stopped the undefined variable errors ( I'm running PHP 5.3.14 ).

More importantly although logon was succesful none of the ldap fields ( ldap_user_puid_sid, ldap_user_puid, ldap_user_current_dn etc. ) were populated. I tried again specifying the correct and specific server for 'LDAP Servers Providing Provisioning Data' and still none of the ldap fields were populated.

Happy to try and further suggestions, tests, patches.