Hi Olivier,

On 07/05/15 20:09, Olivier Nicole wrote:
Our DPSACE 4.2 users are authenticating againts LDAP, all is working
fine so far.

But recently, one of the administrators changed his email address in
LDAP. The next time he loged in DSpace, he was assigned a new eperson
despite the fact that the username (and even the password) were the
same.

I think this is just a matter of how your LDAP authentication is configured and what data comes through from LDAP. Have a look at the configuration reference: https://wiki.duraspace.org/display/DSDOC4x/Authentication+Plugins#AuthenticationPlugins-ConfiguringLDAPAuthentication

I believe DSpace uses this property as the DSpace username:

Property:

email_field

Example Value:

email_field = mail

Informational Note:

This is the LDAP object field where the user's email address is stored. "mail" is the default and the most common for LDAP servers. If the mail field is not found the username will be used as the email address when creating the eperson object.


To me it looks like you have set this to the e-mail field.

This is perhaps a little counter-intuitive, but what (I think) happens is this:
  • person goes to login screen, enters username (not e-mail address) and password
  • DSpace talks to LDAP and verifies that the password is correct for the username
  • DSpace gets the e-mail address for this username from LDAP
  • DSpace looks up that e-mail address in its eperson table to find the corresponding DSpace account; creates a new one if none is found

So when the person changed his address, DSpace could not match the new address to an existing account, so it set up a new account with the new e-mail address.

To get the behaviour you're after, you could change this property and point it to whichever field the username comes through from LDAP. However, that would mean you'd have to change the eperson table in DSpace to hold the username rather than the e-mail address, which in turn would mean that DSpace can no longer send e-mails to people (unless you're using hierarchical LDAP and username@institution is a valid e-mail address for everyone, in which case you could use the netid_email_domain property described in the documentation to construct the e-mail address). It's been a while since I last set up LDAP authentication, but I believe we're using the netid mechanism.

Someone with more LDAP experience may have a better solution for you.

cheers,
Andrea
-- 
Dr Andrea Schweer
IRR Technical Specialist, ITS Information Systems
The University of Waikato, Hamilton, New Zealand
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Reply via email to