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.

Reply via email to