Multiple Base DNs [#238177]

ldapAuth supports multiple base DNs, which I am taking advantage of. However, ldapProvisioning appears to concatenate all of the DNs from ldapAuth when trying to create a new user (see LDIF debug output below). This is probably a bug, but maybe you never intended to support multiple DNs?

I don't imagine using multiple DNs would be a wildly popular feature, so something simple without adding a lot of complication is probably in order. Would it be possible to have an ldapAuth config setting to specify which of the DNs specified in ldapAuth to use? Alternatively you could just default to the first one behind the scenes, which would at least get it working.

I'll take a look at the code myself and see if anything obvious presents itself. I would be happy to help out if desired.

Please note that in the below LDIF the dn should really be something like this:
dn: uid=test.userone,ou=people,dc=domain1.com

*****LDIF Debug Output*****

dn: uid=test.userone,ou=people,dc=domain1.com ou=people,dc=domain2.com ou=people,dc=domain3.com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: test.userone
mail: test.user1@domain1.com
givenName: Test
sn: UserOne
cn: Test UserOne
userPassword: xxxxxxxxxx

Comment	File	Size	Author
#4	quickfix.patch	971 bytes	Volx

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

miglius CreditAttribution: miglius commented 27 March 2008 at 09:13

Frankly, I don't use multiple DNs in my install, so I haven't written a support for it. If you could write a patch which takes care of multiple DNs, I will include it in the ldap provision module.

Comment #2

blair.streit CreditAttribution: blair.streit commented 4 April 2008 at 16:04

Sorry I didn't roll this into CVS, but it's currently more a hack more than a true patch. ldap_integration module currently stores basedn in the DB using newlines to distinguish between multiple DNs.

As a test, I removed lines 2263-2264 and replaced with the below (now 2263-2266)

//CUSTOM -SELECT FIRST BASE DN AS BASE DN FOR CREATING USERS
//$basedn = $_ldapprov_ldap->getOption('basedn');
$possible_base_dns = explode("\r\n", $_ldapprov_ldap->getOption('basedn'));
$basedn = $possible_base_dns[0];

This uses similar logic from ldap_integration to split the Base DNs by Windows newline (\r\n). For simplicity, I just statically set $basedn to the first element in the array ($possible_base_dns[0]).

In my use case, all "external" users are in their own arc of the DIT, so we assume anyone that doesn't already exist in the LDAP should be created under that Base DN. Internal users are added through an HR process so we assume they will already exist in the directory before coming to the site.

I haven't looked too closely, but to make this viable I think some more complex logic might have to be implemented for user deletion. This carries things as far as I need at the moment so I haven't gone any farther yet. I'd be happy to collaborate and/or expand on this myself at some point if there's interest.

Comment #3

rmarins CreditAttribution: rmarins commented 15 February 2010 at 12:25

Version:	5.x-1.x-dev	» 6.x-1.0-beta1
Category:	feature	» bug

This issue was initially started in March 2008 for 5.x-1.x-dev version, but it's still a bug found in version 6.x-1.0-beta1. When using multiple Base DNs the expected behavior was to create new users on the first Base DN entry, and others be used for authentication and automatic account creation purposes.

It seems quite easy but the $_ldapprov_ldap->getOption('basedn'); is used very often in the module code. If anyone knows a best approach to handle that let me know, so I can to create patch.

Comment #4

Volx CreditAttribution: Volx commented 7 May 2010 at 14:50

File	Size
quickfix.patch	971 bytes

There should be an option in the settings. In the LDAP Authentication section one already has to choose an LDAP server to create the accounts in, so adding a list of available base dn's to choose from should be the best solution.

As a quickfix, I set the basedn as #2 , but in the _ldapprov_init method, so all subsequent calls to $_ldapprov_ldap->getOption('basedn') return the correct basedn.