Multiple LDAP servers for user provisioning & synchronization

The original poster is correct in that this is currently not possible through the existing UI and would need to be updated in all places where the assumption is made that only one server is used for provisioning.

It should not really be that difficult to patch in support for this but I'm hesitant to do this directly because of UI limitations, namely, that one can only create a single list of field mappings and thus these are not tied to the server and would have to apply to all. I presume that this is the primary reason why the module does not already do this.

We have a similar need; namely we're transitioning off one LDAP instance (Active Directory) to a new one; as a result we need to log in with multiple ldap instances, and then sync to the primary.

My current thinking is this could be handled by allowing the configFactory to be injected rather than instantiating via \Drupal::config(), thereby allowing another module to wrap the ldap functionality and auth against multiple providers.

I'm happy to work on a patch to this effect.

Hi acstewart

Patches are generally welcome, though after thinking about this some more I'm hesitant to encourage you to work on such a patch. It's likely not that trivial, especially if you are considering using this for migrating directory services, which is an operation that isn't cleanly supported, judging from the open issues in the orphan processor due to the assignment of server and puid to the user itself. You might best be off starting with a proof of concept for yourself instead of a clean patch to see if this breaks something on your end and is a viable path.

Furthermore, if you go ahead with this change I'd recommend writing down some more details about the desired behavior and effect, to make it easier to test and verify by others. For example, I'm currently unsure how you'd plan to support multiple field configurations across servers (or if you'd just have one), how you'd handle soft and hard errors, with multiple servers, and so on. A test or two due to that complexity wouldn't hurt either.

@acstewart have you stared working on the patch ? Also Its something that I am looking in to. If you have any plans please share with me.

Finally,I found a way to avoid adding multiple servers via Global catalog setup.
Through gc setup you will be able to do Forest-wide searches; however you need to change the port number to 3268 in drupal side and add all different DC s to setting.

Then you don't need to add different servers for each and gc setup will do the work for us.

Hello, I tried creating a patch, this was kind of exhausting, there are still a ton of issues here, the Tests will fail because I have not updated them, the GroupUserUpdateProcessor will probably fail. only updated the DrupalUserProcessor, there still needs a lot of refactoring. Basically, after adding the patch, the task 'Drupal Mapping' will disappear, and instead, a new operation for each server will be created, the patch might not be backward compatible. This still needs a lot of work.

Also, a change in 'User Settings', the "LDAP Servers Providing Provisioning Data" is now a bunch of checkboxes instead of radios

New patch:

• Added a hook update to correctly map 'ldapUserSyncMappings' into each server and convert 'drupalAcctProvisionServer' into an array
• Ran phpcs

Pending Issues:

• Changing the test to accomidate the new changes
• Check and fix the 'GroupUserUpdateProcessor' it still assumes that there is one server
• Change 'ldapEntryProvisionServer' to accept the new mapping
• Make sure previous configurations are compatible
• Maybe some refactoring

Am I correct to assume that the current setup (ldap_sso with kerberos) can work with multiple ldap servers provided that the users are pre-existing?

#3009613: Patch for multiple Servers Authentication
is a duplicate

Reroll of #11.