LDAP Authentication and LDAP User: LDAP not allowing to authenticate to multiple servers

This should work. I'll work on replicating this. Is anyone else succeeding with multiple servers for authentication?

I have the same problem...

I have installed the latest release of the ldap module.

I have these activated:

• LDAP Authentication
• LDAP Authorization
• LDAP Authorization - Drupal Roles
• LDAP User Module

I have 2 Active directories to connect to. I have enabled them both and the test is OK. (In second tab: Servers)
So, they are both working.

In third tab: User.

Basic Provisioning to Drupal Account Settings > LDAP Servers Providing Provisioning Data
--> When I select none: None of the users can login.
--> When I select one of the 2 enabled Active directories: The user of the selcted AD, can login, the other can't

4th Tab: Authentication:
Mixed mode is selected
Both AD's are selected

When a user can't login, this is the message.

Notice: Trying to get property of non-object in _ldap_authentication_user_login_authenticate_validate() (regel 569 van /sites/all/modules/ldap/ldap_authentication/ldap_authentication.inc).
Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (regel 178 van /includes/entity.inc).
Notice: Trying to get property of non-object in user_login_submit() (regel 2252 van /modules/user/user.module).
Notice: Trying to get property of non-object in user_login_finalize() (regel 2227 van /modules/user/user.module).
Notice: Undefined property: stdClass::$uid in user_login_finalize() (regel 2233 van /modules/user/user.module).
Notice: Undefined property: stdClass::$uid in drupal_get_user_timezone() (regel 2211 van /includes/bootstrap.inc).
Notice: Undefined property: stdClass::$uid in ldap_user_user_login() (regel 772 van /sites/all/modules/ldap/ldap_user/ldap_user.module).
Notice: Undefined property: stdClass::$name in ldap_user_user_login() (regel 815 van /sites/all/modules/ldap/ldap_user/ldap_user.module).
Notice: Undefined property: stdClass::$uid in user_access() (regel 798 van /modules/user/user.module).
Notice: Undefined property: stdClass::$uid in user_access() (regel 810 van /modules/user/user.module).
Notice: Undefined property: stdClass::$roles in user_access() (regel 811 van /modules/user/user.module).
Notice: Undefined property: stdClass::$uid in user_access() (regel 817 van /modules/user/user.module).
Notice: Undefined property: stdClass::$uid in user_access() (regel 820 van /modules/user/user.module).
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'name': INSERT INTO {users} (uid, created, login) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 20 [:db_insert_placeholder_1] => 1358956044 [:db_insert_placeholder_2] => 1358956044 ) in drupal_write_record() (regel 7106 van /includes/common.inc).
Notice: Undefined property: stdClass::$roles in user_access() (regel 811 van /user/user.module).

Is there a sollution for this?

There is no solution for this currently. Since the ldap to drupal mapping is for a single server, it simply will not work for mulitple servers. There are 2 ways a patch could be written to fix this:

-----------------
1.
- make "LDAP Servers Providing Provisioning Data" a checkbox so more than one can selected.
- the mappings would have to be the same for each server
- or add a checkbox to the effect of "provision from whatever server user is ldap associated with"
------------------
2.
- make "LDAP Servers Providing Provisioning Data" a checkbox so more than one can selected.
- allow for mulitple servers mappings to be stored.
-----------------

1 is much simpler to implement than 2 and avoids a complex UI. But only 2 accounts for structurally different ldaps. I believe patch 2 would be too disruptive for the beta process and should wait for the 8.x version.

Patch 1 would involve:
- adjusting LdapUserConf.synchToDrupalAccount() to use user associated ldap server, instead of LdapUserConf.drupalAcctProvisionServer
- I don't believe ldap_servers_get_user_ldap_data() or LdapUserConf.entryToUserEdit() functions would need any alteration.

Attached is a start at such a patch. It lacks configuration of which servers are used to provision and just assumes the server that the user is associated with is the one to get the ldap data from. The patch is completely untested, but if we can get it to work and have it tested well, we can work the UI in later.

I don't this configuration for option 1 should be checkboxes. Done that way, the drupalAcctProvisionServer must become an array, and then every place where it is used must be converted to make a choice about the values in that array. For example, the code would have to loop through all servers in the array and then try provisioning from each server, presumably stopping after a success. There would also then be a hidden meaning to the order in which the servers appeared in the array.

I think the configuration should remain radios. There would be an option for each individual server, an option for none, and an option for 'provision from whichever server the user is associated with'. There are a few use cases where this option wouldn't work (n>2 servers, authentication for users handled by some subset, provisioning handled by some other subset), but that case seems quite outlandish. Additionally, we don't have to deal with looping through provisioning attempts and trying to deal with ordering.

I think there may have been a jump here from "I want to allow logging in to different servers" to "I want to pull account information from different servers". This issue is about the former, not the latter.

The LDAP Authentication tab specifically states you can log in via multiple servers:

Check all LDAP server configurations to use in authentication. Each will be tested for authentication until successful or until each is exhausted. In most cases only one server configuration is selected.

And you can select as many servers as you have configured because the form element is a set of checkboxes.

The LDAP Authorization tab is clear about only being usable on a single server, and uses radio options as expected.

If the LDAP module truly cannot handle User A authenticates against Server A, while User B authenticates against Server B then the authentication page is extremely misleading and confusing.

Is it the case that the Authentication functionality is purely authentication, and if you manually create User B they will be able to log in to Server B? That should be explained within that area if so.

After some debugging it seems that ldap_authentication does go through and validate against each server you have configured until it succeeds (or all fail), but it does not use the correct sid when trying to create new users.

Here is a patch that changes the drupalAcctProvisionServer to the sid of the server that the user was authenticated on.

I have not noticed any functional change other than users from all servers being able to login. There may be a better way to update the sid of the ldapUser object that is being used. Maybe the wrong ldapUser object is being used. I am not familiar with the ldap module codebase so please review this.

Anyway, if the module authentication can authenticate against multiple servers, then I think this issue should be closed.

As Steven correctly point out the issue is:
"I want to allow logging in to different servers"

that seems to be ok at the moment (I have to do another couple of tests)

thanks for the great work,
Denis

This still does not work. I have two servers that I need to authenticate against. I can do one or the other, but not both. If both are selected, only the first one in the list will be used for authentication. I am using the latest development release of the module.

The patch from comment #9 didn't quite work for me. The script wouldn't loop through the array of servers I had set up, so I found where the loop was being broken off with a break; statement and replaced with a continue; in addition to what what done in comment #9's patch.
This patch was done on version 7.x-2.0-beta5.

The patch in #13 needs to be re-rolled from the correct folder (and shouldn't leave the old code commented in).

Here's a patch that will allow you to use the ldap user test form to pull in and create users from other servers. The module still won't pull info from the second server for your users, but I've used this to at least get these users in the site.

Just a note that there seems to be multiple related issues in the queue. While these issues aren't exact duplicates I wanted to list them for reference purposes in hopes that the solution to one of these could address all of them.

The related issues are:

• #1740978: LDAP Authentication and LDAP User: LDAP not allowing to authenticate to multiple servers (this issue)
• #1923516: LDAP User: Unable to configure multiple LDAP server for Drupal account provisioning
• #987324: LDAP Auth, multiple domains, same usernames

#9 is a reasonable quick fix. Coupled with a configuration option checkbox "provision from whatever server user is ldap associated with" would take care of many use cases.

I was thinking the same thing johnbarclay.

I also have a client that needs this. I'll be working on a patch today/tomorrow based off the work in #9. I'll submit it for review as soon as possible.

My basic plan of attack on this is:

• Use the patch in #9/#13 as the starting point to store the id of the server providing the authentication.
• Add an option to the User configuration tab to specify that it should use the same server that provided authentication for the user.
• Look through the code for the Authorization tab to identify any places that need to be updated to use the server that provided authentication.

I'll also try to incorporate the work from #15 to update the test screen to work with these updates.

As a bonus, if I have time, I'd like to look at the code that handles selecting the server to authenticate against and see if we can add some configuration options to pre-select the correct server to authenticate against based on the user's login info. For example, add a configuration box to the server settings which allow specifying that all user accounts using the form of "mydomain1\myusername" or "myusername@mydomain1.com" get routed to server1 first and logins as "mydomain2\myusername" or "myusername@mydomain2.com" get routed to server 2 first.

Here is an updated patch. This patch does the following:

• Adds a new configuration option to the "User" tab labeled "Use server which performed the authentication. Useful for multi-domain environments.".
  • Selecting this option causes the LDAP module to always use the server that last provided a successful authentication for all provisioning, user account sync, and permission assignments.
• Added logic to the ldap_authentication.inc and ldap_user.module to dynamically change the provisioning server as needed.

I've tested the following funcationality on our clients network with 2 separate AD domains without issue:

• Creating new Drupal user accounts and syncing profile files with AD during initial login.
• Synching Drupal profile fields with AD during subsequent logins.
• Synching Drupal profile fields with AD during profile/account edit operations.

I have not tested the Group/Role permission assignment functionality yet though since we're not using that functionality.

Slight update to the previous patch to resolve an error when users log in via the SSO module when they do not have the $account->data['ldap_user'] info in their Drupal user account object.

Thanks. This is committed, but testing is in order. This along with some nested group issues in authorization are the only remaining bugs that I believe needed substantive code. Appreciate you following through on this.

I wanted to drop in a quick status update on our internal testing of this update.

Our client has a fairly rigorous review workflow for regulatory compliance reasons. So as things stand right now, the committed patch has completed the internal review process by the client's IT team and has been moved into a QA environment for UAT by a small group of users. We expect to roll this update out to production within the next week or so.

So far, no issues have been identified other than an intermittent issue with logins taking a few seconds longer than normal. Though we think we've narrowed that down to routing/network latency issues on the corporate WAN.

Just adding an error that I'm getting in testing beta6.

Please bear with me, I am four months in to drupal. I don't have any network/ldap/etc background to speak of.

I have 2 LDAP servers. On each I can successfully bind and can test drupal user names to pull data from AD - so I know I'm connecting.

Both servers are checked for authentication and "use server that performed authentication" is checked as well.

I can't create an account for a user on either platform. If I turn one or the other on, I can (as I could in beta5).

Watchdog logging turns up this error: Failed to load server object ldap_last_authserv in _ldap_servers_get_user_ldap_data

Any advice?

Should I add new instances of the servers with my same settings and disable the other ones?

Thanks for all the work on this module - and getting this patch in place - it's going to save me once I get it to work!

I should add that the error I receive upon creating a user account is

User johndoe does not have a corresponding LDAP Entry (dn). Under LDAP options, you may NOT select "Make this an LDAP Associated Account"

Are you able to authenticate users against the first server in the ldap server list (who have ldap entries in that server) when both are turned on?

No, I'm not.

It will only work if I select a specific server, not when I choose -- Use server which performed the authentication. Useful for multi-domain environments. --