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
