NullPointerException enabling LDAP Auth on DSpace 5.8

[Patrick Rynhart]

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.

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)    at org.dspace.authenticate.LDAPAuthentication.authenticate(LDAPAuthentication.java:202)    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)

....

Happy to provide any further info.

With Thanks,

Patrick

[Mark H. Wood]

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
www.ulib.iupui.edu

[Patrick Rynhart]

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

[Patrick Rynhart]

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.

[Kim Shepherd]

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

--
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 dspace-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/9c5a2a3b-876f-4c91-add6-9baee5d6a596n%40googlegroups.com.

[Patrick Rynhart]

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