Oliver, > I only have answers to a couple of your questions, but perhaps that > helps a little bit... > > First: I have the same situation here. Authentication against LDAP > works, but the data is not collected correctly from the LDAPserver. All > I get is a local entry with the netid, but nothing else (phone number, > email, real name etc. are not taken). > So I would be very interested how you got that part working... I have > created a helper script, which is asking the LDAP for database entries, > which are missing in our DSpace DB. That solves the problem, but its > still only a workaround.
In you LDAP directory, the attributes mail, sn, givenName and telephone Number must be readable by anyone (anonymous bind) and you have to declare search.anonymous=true in authorization-ldap.cfg. OR In you LDAP directory, the attributes mail, sn, givenName and telephone Number can only be seen by some user bound to LDAP and you have to delare this user search.user and search.password. I did not test this second part. Unlink what the coments in authorization=-ldap.cfg may suggest, the 3 search.xx variable do not pertain to hierarchical trees only, but they must be declared for any LDAP directory. >> And this leads me to a more general remark: why creating eperson for a >> user loged in with LDAP? > > I guess thats because every object (for example items) in DSpace needs > to have an eperson, who created it. If this eperson (no matter how it > was authenticated) creates an item, DSpace needs to store the internal > ID of that eperson for reference. Otherwise the "My DSpace" area could > not work. There could be a reccord created with only the LDAP isername and the eperson ID, but not duplicating the rest of the information. > If a user, who was authenticated via LDAP, is removed from the LDAP, I > guess he cannot login into DSpace, because he has no password and though > he shouldn't be authenticated successfully. But, to be honest, I haven't > tried that yet. It does work, I tried it (login as LDAP, use the profile page to update my DSpace password, delete the user in LDAP and still connect through DSpace password authentication). Best regards, Olivier > In the other points I agree with you: it should not be necessary to copy > the personal data into the local database, but read it on demand from > the directory, because this is causing update trouble. I also do not > understand, why the search has to be anonymous. > > Best regards > Oliver > > Am 22.01.2015 um 09:34 schrieb Olivier Nicole: >> 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
