Olivier, 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:
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. 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. 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 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
