Thanks Kim. Managed to find that second error was occurring for the first logon for new (never seen before) AD accounts. Turns out that the logging level somehow affects the execution flow! (Never seen something like this before.). I had DEBUG enabled (trying to figure out what I needed to fix re LDAP auth). More details in this thread:
https://groups.google.com/g/dspace-tech/c/tZu2C0MbYXM And also in this: https://github.com/DSpace/DSpace/issues/6782 Anyway - after turning the log level down to INFO LDAP auth seems to be working correctly for our test environment. I know that we are on an older DSpace version, but we have a project underway re upgrading to 7.X - that bug looks to be fixed around v6.3+ or so. But just wanted to also get LDAP/AD binding working for where we are at the moment. Thanks to Mark and yourself for replies (and I note that Mark also replied to the EmptyStackException with LDAP+DEBUG logging issue). With Thanks, Patrick On Wednesday, 1 February 2023 at 14:27:57 UTC+13 Kim Shepherd wrote: > 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/03f990db-a7ec-4e95-b7f1-f72c91190957n%40googlegroups.com.
