Olivier, Looking again at the code, it seems like there *may* be a bug here. (Unfortunately, I don't have an LDAP locally to test against myself in order to verify it though.)
However, I do notice something odd in the LDAP Authentication code. It looks as though the various user LDAP fields are only being queried if you *either* have "search.anonymous=true" OR you have "search.user" / "search.password" specified. As you rightly noted though, all of those options are actually more for Hierarchical LDAP setups, and shouldn't be necessary if your LDAP is flat. (My mistake there...I had misread the configs) I've logged a full bug report here: https://jira.duraspace.org/browse/DS-2421 Based on reading the code, it *seems* like you could "workaround" this bug by specifying: search_context = [same value of object_context, as it has no default] AND, EITHER search.anonymous = true OR search.user = [some LDAP user] search.password = [some LDAP user] While all of those "search" settings should not be necessary on a "flat" LDAP scheme, they should still work. It's just obviously annoying that you'd either need to make your LDAP searchable anonymously or create a user to search as ("search.user"). But, it should work, I believe. - Tim On 1/23/2015 1:14 AM, Olivier Nicole wrote: > Thank you Tim, > >> Just skimming your configuration, it looks like, based on the DSpace >> LDAP Documentation you have a slightly odd combination of configs. I'm >> not sure which version of DSpace you are using though, so I'm assuming >> this might be 4.x: > > 4.2 > >> https://wiki.duraspace.org/display/DSDOC4x/Authentication+Plugins#AuthenticationPlugins-LDAPAuthentication >> >> In the docs, you'll see a few important configuration notes: >> >> 1) "search_context" notes that "With autoregister turned on, when a user >> authenticates without an EPerson object we search the LDAP directory to >> get their name and email address so that we can create one for them." >> You seem to have skipped specifying a "search_context" for searching >> LDAP? Not sure if this was on purpose or not. > > That search_context is not very clear. It is also says "Often the > search_context is the same as the object_context parameter." I > understand that by default it will be made similar and I have to give it > a value only in the case it is different. > > And in LDAP cpntext, "So after we have authenticated against > uid=username,ou=people,o=byu.edu we now search in ou=people for > filtering on [uid=username]." makes little sense: the name and mail are > attribute of the LDAP person object that we have just authenticated > against, why looking for them elsewhere? > >> 2) Also you have two options when searching LDAP: >> * You can set "search.anonymous=true" in which case LDAP is >> searched anonymously. >> * OR, you can specify "search.user" and "search.password" to search >> LDAP as a specific Admin account. >> It looks like you've commented out *both* of these settings, which >> just defaults to searching anonymously. > > search.anonymous is not mentionned on the web page you linked to > above :) In DSpace-Manual.pdf, search.anonymous is only mentionned in > the chapter about upgrading from 1.8 to 3.x, it is about hierarchical > LDAP tree. It is also mentionned in authorization-ldap.cfg, under > hierarchical LDAP tree. > > search.user and search.password are both mentionned in the section about > hierarchical LDAP tree: in the web page, in the PDF manual and in the > comments in authorization-ldap.cfg. > > I have a flat tree, with all the users residing in the same branch, so I > did not see the need to use any of the search.something. > >> 3) As for the "email" field problem. There was a known bug regarding >> this in DSpace 3 and 4. It's now been fixed in DSpace 5. Here's the info >> on that problem: https://jira.duraspace.org/browse/DS-1781 > > Thanks, I will patch that. > > Best regards, > > Olivier > >> As for your questions about why DSpace creates an EPerson. DSpace is >> only *aware* of EPerson objects in the system. Therefore, all the DSpace >> authentication plugins create/update a corresponding EPerson object. >> DSpace primarily uses LDAP (or Shibboleth) to ensure you have access to >> the system, but after that, all content you create is associated with >> your *DSpace EPerson*. >> >> Hopefully that gives you a few clues to go on. Good luck! >> >> - Tim >> >> >> On 1/22/2015 2:34 AM, Olivier Nicole wrote: >>> Hi, >>> >>> OK, I have some answers but it raises much more questions. >>> >>>> enable = true >>>> autoregister = true >>>> provider_url = ldaps://ldap.cs.ait.ac.th/ >>>> id_field = uid >>>> object_context = ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th >>>> # search_context = ou=People >>>> email_field = mail >>> >>> It stubornedly refuses to work. >>> >>>> surname_field = sn >>>> givenname_field = givenName >>>> phone_field = telephoneNumber >>>> #login.specialgroup = CSIM_LDAP >>>> search_scope = 2 >>>> #search.anonymous = false >>> >>> This MUST be set to true in order to have autoregister working. >>> >>>> #search.user = cn=admin,ou=people,o=myu.edu >>>> #search.password = password >>>> #netid_email_domain = @example.com >>>> #login.groupmap.1 = ou=ldap-dept1:dspace-group1 >>>> login.groupmap.attribute = csimAccountPermission >>> >>> This attribute can only have *ONE* value. >>> >>>> login.groupmap.1 = dspace:CSIM_LDAP >>>> login.groupmap.2 = dspaceadmin:Administrator >>> >>> - So the autoregister of the email is not working (name, phone are working >>> great). I tried with one or two values for the mail attribute, could not >>> get it to work. I can live with that as users are located in the same >>> domain as DSpace and email can be sent with only the username. >>> >>> - The login.groupmap.attribute cannot have several values, I think I can >>> live with it and manage the group hierarchy some other way if I want a >>> user to belong to 2 groups. >>> >>> - But what is really puzzling me is why the search has to be anonymous? >>> The user has provided a username and password, these have been used to >>> successfully bind to LDAP, then the search should be made as the user, >>> not as anonymous (hopefully the user has more visibility to his own >>> data than anonymous has; if the telephone number should not be made >>> world visible for security readon, when bind as the user, the user >>> should be able to see his own phone number). >>> >>> So the anonymous search should be used only when trying to figure out >>> the DN of the user in a hierarchical LDAP. It should not be used to >>> gather the personnal information once the user has successfully >>> bind. Or there is a case i don't understand where the bind DN is >>> different fro the DN that contains the user detail? >>> >>> And this leads me to a more general remark: why creating eperson for a >>> user loged in with LDAP? >>> >>> - when the LDAP account is removed, the user can still login using is >>> eperson account (provided that he has updated his profile and >>> installed a password); so when a user is leaving the system, he must >>> also be deleted from DSpace; >>> >>> - when the LDAP account is updated, the eperson must be updated in the >>> same way; >>> >>> - there is no major difference between finding the person details in LDAP >>> and in Postgres; one should not take longer than the other. >>> >>> Best regards, >>> >>> Olivier >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> New Year. New Location. New Benefits. New Data Center in Ashburn, VA. >>> GigeNET is offering a free month of service with a new server in Ashburn. >>> Choose from 2 high performing configs, both with 100TB of bandwidth. >>> Higher redundancy.Lower latency.Increased capacity.Completely compliant. >>> http://p.sf.net/sfu/gigenet >>> _______________________________________________ >>> DSpace-tech mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >>> List Etiquette: >>> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >>> >> >> ------------------------------------------------------------------------------ >> New Year. New Location. New Benefits. New Data Center in Ashburn, VA. >> GigeNET is offering a free month of service with a new server in Ashburn. >> Choose from 2 high performing configs, both with 100TB of bandwidth. >> Higher redundancy.Lower latency.Increased capacity.Completely compliant. >> http://p.sf.net/sfu/gigenet >> _______________________________________________ >> DSpace-tech mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> List Etiquette: >> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >> > ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
