In case it helps, when using a search/service account like this, here is what happens during authentication:
1. Search user binds to the LDAP server using credentials in the config 2. Search user performs a search for the uid / netid / whatever (as per config) entered into the "login" field, using the search scope and object context in the configuration 3. If all goes well, this search returns a single result which is then used to retrieve the user's DN 4. Now, a new connection is made, this time binding as the user DN using the password that was entered in the "password" field 5. WIth this new connection, another search is made, this time for the user's own record (note: sometimes the user can see more attributes in a self-search than the search / service account could) 6. If auth succeeds and the search succeeds, the resulting data here can be used to create / update the EPerson profile after login, set special groups and so on. This last part (update profile) includes setting 'netid' which is the username by default for LDAP rather than email address. You could be onto something with the local account clash - after a successful login their netid should be populated... 0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC On Wed, 1 Feb 2023 at 09:54, Patrick Rynhart <[email protected]> wrote: > Very odd. Spying on the LDAP traffic, the result returned seem to be > fine. What I'm observing is that the first time an LDAP login is attempted > for a particular user, you get this Stacktrace. But if you try again > immediately afterwards (with the same user) the login is successful (and > also any subsequent logons for the same user). > > I wonder if it's because our installation previously had local accounts > (for users which are now suddenly AD users), and DSpace doesn't handle this > scenario nicely. > > Perhaps I need to find an AD account of a user who has never logged into > DSpace previously - and see whether this Stacktrace happens for the initial > login or not. > > On Wednesday, 1 February 2023 at 09:32:02 UTC+13 Patrick Rynhart wrote: > >> Thank you very much for the help :). I didn't realise that was a >> compulsory / required property, because the commented stub for >> authentication-ldap.cfg has: >> >> # This is the *optional* search scope value for the LDAP search during >> # autoregistering. >> >> However, you're absolutely correct. After defining it to search_scope = >> 2 I'm getting a bit further. >> >> Where things are at currently, if I enter invalid LDAP credentials then >> I'm getting a friendly (DSpace branded) error back: >> >> "The user name and/or password supplied were not valid." >> >> However, if I enter valid credentials then I get this traceback :-( >> >> java.util.EmptyStackException at java.util.Stack.peek(Stack.java:102) >> at java.util.Stack.pop(Stack.java:84) at >> org.dspace.core.Context.restoreAuthSystemState(Context.java:250) at >> org.dspace.authenticate.LDAPAuthentication.authenticate(LDAPAuthentication.java:357) >> at >> org.dspace.authenticate.AuthenticationManager.authenticateInternal(AuthenticationManager.java:162) >> at >> org.dspace.authenticate.AuthenticationManager.authenticate(AuthenticationManager.java:99) >> at >> org.dspace.app.xmlui.utils.AuthenticationUtil.authenticate(AuthenticationUtil.java:107) >> at >> org.dspace.app.xmlui.aspect.eperson.LDAPAuthenticateAction.act(LDAPAuthenticateAction.java:71) >> at >> org.apache.cocoon.sitemap.impl.DefaultExecutor.invokeAction(DefaultExecutor.java:55) >> at >> org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:105) >> ..... >> >> I guess my LDAP Filters and/or search scope must be incorrect somehow. >> I'll try to spy on the LDAP traffic (I'm in clear text for debug) to see >> what might be being returned when DSpace attempts a login. >> >> With Thanks, >> >> Patrick >> >> >> On Wednesday, 1 February 2023 at 03:15:16 UTC+13 [email protected] >> wrote: >> >>> On Mon, Jan 30, 2023 at 05:06:08PM -0800, Patrick Rynhart wrote: >>> > We are on DSpace 5.8 and have always used internal (i.e >>> > PasswordAuthentication) until now. I've tried enabling LDAP based auth >>> as >>> > follows: >>> > >>> > 1. In /opt/dspace/config/modules/authentication.cfg set: >>> > >>> > plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \ >>> > org.dspace.authenticate.LDAPAuthentication >>> > >>> > 2. Configured /opt/dspace/config/modules/authentication-ldap.cfg as >>> follows: >>> > >>> > enable = true >>> > autoregister = true >>> > provider_url = ldap://130.123.96.53:389/ >>> > id_field = cn >>> > object_context = ou=clients,dc=massey,dc=ac,dc=nz >>> > search_context = ou=clients,dc=massey,dc=ac,dc=nz >>> > email_field = mail >>> > surname_field = sn >>> > givenname_field = givenName >>> > search.anonymous = false >>> > search.user = cn=ITS LDAP read-only >>> > agent,ou=System,ou=Clients,dc=massey,dc=ac,dc=nz >>> > search.password = <<REDACTED>> >>> > >>> > When I log onto our Dspace site with URL /ldap-login then I get the >>> branded >>> > LDAP page, but as soon as I submit I get the traceback provided below. >>> > >>> > Using Wireshark, I can see that the DSpace server isn't trying to >>> connect >>> > to our LDAP server. However if (on the same server) I make use of the >>> OS >>> > command line utility "ldapsearch" then an LDAP bind and query is >>> > successful, i.e. >>> > >>> > ldapsearch -x -h tur-ldap.massey.ac.nz -b dc=massey,dc=ac,dc=nz will >>> > succeed. >>> >>> A good test. >>> >>> > Can someone help me to narrow down the fault ? Am I possibly missing a >>> JAR >>> > ? >>> > >>> > java.lang.NullPointerException at >>> > >>> org.dspace.authenticate.LDAPAuthentication$SpeakerToLDAP.getDNOfUser(LDAPAuthentication.java:405) >>> >>> >>> The line appears to be: >>> >>> ldap_search_scope_value = Integer.parseInt(ldap_search_scope.trim()); >>> >>> and I see no value for 'search.scope' above. I can't find any place >>> where this property is given a default value, so that would explain >>> the NPE. >>> >>> -- >>> Mark H. Wood >>> Lead Technology Analyst >>> >>> University Library >>> Indiana University - Purdue University Indianapolis >>> 755 W. Michigan Street >>> Indianapolis, IN 46202 >>> 317-274-0749 <(317)%20274-0749> >>> www.ulib.iupui.edu >>> >> -- > All messages to this mailing list should adhere to the Code of Conduct: > https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx > --- > You received this message because you are subscribed to the Google Groups > "DSpace Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dspace-community/9c5a2a3b-876f-4c91-add6-9baee5d6a596n%40googlegroups.com > <https://groups.google.com/d/msgid/dspace-community/9c5a2a3b-876f-4c91-add6-9baee5d6a596n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/CAKZKfqpaUL%3DbdW3Eq-BZh58sJtkwszyZS%2B%2BW8h4mx_BVkbNV3A%40mail.gmail.com.
