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
