LDAP Login issues - DSpace v5

881 views
Skip to first unread message

Tim Cullings

unread,
Jul 12, 2017, 4:55:43 PM7/12/17
to DSpace Technical Support
I have been tasked with setting up DSpace in my environment and getting it working with LDAP for user authentication.  

I've gone through every article on the site, tried every combination of settings in the authentication-ldap.cfg file and can't seem to get it to work.  The only error I receive is:

ldap_authentication:type=failed_auth javax.naming.AuthenticationException\colon; [LDAP\colon; error code 49 - 80090308\colon; LdapErr\colon; DSID-0C0903D9, comment\colon; AcceptSecurityContext error, data 52e, v2580 ]

Running DSPACE 5 on Windows Server 2012 R2

Here are my settings:

authentication-ldap.enable = true
authentication-ldap.autoregister = true
authentication-ldap.provider_url = ldap://ldap.domain.com:389
authentication-ldap.id_field = sAMAcoountName
authentication-ldap.object_context = dc=domain,dc=com
authentication-ldap.search_context = dc=domain,dc=com
authentication-ldap.email_field = mail
authentication-ldap.surname_field = sn
authentication-ldap.givenname_field = givenName
authentication-ldap.search_scope = 2
#authentication-ldap.search.anonymous = false
authentication-ldap.search.user = cn=user,ou=someou,dc=domain,dc=com
authentication-ldap.search.password = password

I used an LDAP browsing tool from the server with the service account I am attempting to use for Dspace and was able to run queries with it against our AD server.  I also used ldapsearch on a UNIX box and the specified credentials and that worked as well so I am fairly certain the issue is with Dspace.  Domain users reside in multiple OUs that are one level down from the root for example,  cn=user1,ou=Contractors,dc=domain,dc=com and so on for FTEs, vendors and other types of employees.

Shannon Meisenheimer

unread,
Jul 12, 2017, 5:24:07 PM7/12/17
to Tim Cullings, DSpace Technical Support
What does your authentication.cfg file look like, do you have LDAPAuth added there?  

Mine contains:
plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \
        org.dspace.authenticate.LDAPAuthentication, \
org.dspace.authenticate.PasswordAuthentication


Also the value for your authentication-ldap.id_field key is "sAMAcoountName" and should probably be "sAMAccountName".  I'm using 'cn' for that key.

Shannon
--
Mr. Shannon Meisenheimer
Office of Tech
nology
University of Central Missouri
WDE0608
Work Phone:  (660) 543-8483

--
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscribe@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Tim Cullings

unread,
Jul 12, 2017, 5:38:46 PM7/12/17
to DSpace Technical Support, tim.cu...@gmail.com
I think I just mistyped that id_field, I had tried cn and that didn't work either.

My authentication.cfg file only has LDAP turned on atm so I can test it.  In the username field are you adding any @domainname.com or domain\username?

Through google searches it is telling me that the error indicates that my LDAP service account and/or password might be incorrect but I have succesfully connected to and searched LDAP using those credentials.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.

Shannon Meisenheimer

unread,
Jul 12, 2017, 5:47:52 PM7/12/17
to Tim Cullings, DSpace Technical Support
Just username for the cn value:
search.user = cn=someUser,ou=someOU,ou=anotherOU,dc=ucmo,dc=local

I wouldn't think you would need the domain defined with in CN if you are providing the domain component attribute.

The rest of your key values are pretty similar to mine with a couple of exceptions.
object_context = ou=accounts,dc=ucmo,dc=local
search_context = ou=accounts,dc=ucmo,dc=local
... and the earlier mentioned id_field value.

I'm also using ldaps instead of ldap in the provider_URL.

Shannon

Mr. Shannon Meisenheimer
Office of Tech
nology
University of Central Missouri
WDE0608
Work Phone:  (660) 543-8483

To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscribe@googlegroups.com.

Shannon Meisenheimer

unread,
Jul 12, 2017, 10:22:13 PM7/12/17
to Tim Cullings, DSpace Technical Support
Are you sure the cn and samAccountName match for that user?

Shannon

Sent from my iPhone
--

Tim Cullings

unread,
Jul 13, 2017, 7:19:02 PM7/13/17
to Shannon Meisenheimer, DSpace Technical Support
Yes, I verified that they are the same.

To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscribe@googlegroups.com.

Shannon Meisenheimer

unread,
Jul 13, 2017, 8:00:50 PM7/13/17
to Tim Cullings, DSpace Technical Support
Weird.  That's an auth credential error, but like you said you've tested that user elsewhere.  I'm no LDAP wizard, I had troubleshoot our DSpace/LDAP setup with our team that supports active directory.

Shannon

Sent from my iPhone

Tim Cullings

unread,
Aug 2, 2017, 7:50:28 PM8/2/17
to Shannon Meisenheimer, DSpace Technical Support
Finally solved this through a combination of Wiresark and dspace logs I was able to figure out that it wasn't binding to LDAP at all.  Fixed that by adding \'s to my authentication-ldap.search.user.

So it is now cn=username\,ou=someou\,dc=domain\,dc=com

I then had to add a slash to the end of my ldap server name: ldap://ldap.domain.com/

Had to add a backslash to the search context: ou=domain\,ou=com

I commented out the object context line as well.

After that it started working.

Vusani Mutshinya

unread,
Aug 3, 2017, 9:00:54 AM8/3/17
to DSpace Technical Support, meisen...@ucmo.edu
Hi,

I am facing the same issue, I was so happy you had found a solution only to find it not working for me.
I have configured everything as you have and still no joy. I have ldapsearch which I am able to connect with but DSpace still does not.

The error is a no DN found for user.

Any help will be greatly appreciated.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.

Shannon Meisenheimer

unread,
Aug 3, 2017, 9:08:25 AM8/3/17
to Vusani Mutshinya, DSpace Technical Support
Can you post your ldap configuration settings?

Shannon
--
Mr. Shannon Meisenheimer
Office of Tech
nology
University of Central Missouri
WDE0608
Work Phone:  (660) 543-8483

Vusani Mutshinya

unread,
Aug 3, 2017, 9:11:14 AM8/3/17
to DSpace Technical Support, vmuts...@gmail.com
Here:

authentication-ldap.enable = true
authentication-ldap.autoregister = true
authentication-ldap.provider_url = ldap://domain.gov.za/
authentication-ldap.id_field = sAMAccountName
authentication-ldap.object_context = ou=domain\,dc=domain\,dc=gov\,dc=za
authentication-ldap.search_context = ou=domain\,ou=domain\,ou=gov\,ou=za
authentication-ldap.email_field = mail
authentication-ldap.surname_field = sn
authentication-ldap.givenname_field = givenName
authentication-ldap.search_scope = 2
authentication-ldap.search.anonymous = false
authentication-ldap.search.user = cn=user\,ou=domain\,dc=domain\,dc=gov\,dc=za
authentication-ldap.search.password = passwd

Shannon Meisenheimer

unread,
Aug 3, 2017, 10:12:50 AM8/3/17
to Vusani Mutshinya, DSpace Technical Support
I think you need something other than domain for your OU:
authentication-ldap.object_context = ou=domain\,dc=domain\,dc=gov\,dc=za
authentication-ldap.search_context = ou=domain\,ou=domain\,ou=gov\,ou=za

The error seems to indicate a problem with your base DN.

Talk to your LDAP/Directory admin and find out what your top level OU's are.

Shannon
--
Mr. Shannon Meisenheimer
Office of Technology
University of Central Missouri
WDE0608
Work Phone:  (660) 543-8483

To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscribe@googlegroups.com.

Vusani Mutshinya

unread,
Aug 3, 2017, 10:20:56 AM8/3/17
to DSpace Technical Support, vmuts...@gmail.com
My top level OU is the same name with my domain name, only that the OU's first letter capitalized. 

Vusani Mutshinya

unread,
Aug 14, 2017, 5:14:03 AM8/14/17
to DSpace Technical Support, vmuts...@gmail.com
Ended up with a solution with the following config:

provider_url = ldap://domain.com/
#object_context = ou=someOU\, dc=domain\,dc=com
search_context = dc=domain\,dc=com # No OU required here for my ldap
search_scope = 2
search.user = CN=ldapsync\,CN=ldapsync_group\,dc=domain\,dc=com
search.password = password

Michel Souza

unread,
Jul 29, 2019, 2:57:53 PM7/29/19
to DSpace Technical Support
Hi guys, I'm having a huge problem trying to make work LDAP Authentication as many of you also did. I've tried also the solutions proposed here but nothing works for me. I'd really appreciate if you can give me some hints that could help me solving this problem:

my 'authentication-ldap.cfg' is as follows:

authentication-ldap.enable = true
authentication-ldap.autoregister = false
authentication-ldap.provider_url = ldap://intranet.mpba.mp.br:389/
authentication-ldap.id_field = sAMAccountName
#authentication-ldap.object_context = ou=Funcionarios
authentication-ldap.search_context = OU=Funcionarios\,DC=intranet\,DC=mp\,DC=ba\,DC=gov\,DC=br
authentication-ldap.email_field = mail
authentication-ldap.surname_field = sn
authentication-ldap.givenname_field = givenName
authentication-ldap.phone_field = telephoneNumber
#authentication-ldap.login.specialgroup = group-name
authentication-ldap.search_scope = 2
#authentication-ldap.search.anonymous = false
authentication-ldap.search.user = CN=sisd.dspace\,OU=Usuarios de sistema\,DC=intranet\,DC=mp\,DC=ba\,DC=gov\,DC=br
authentication-ldap.search.password = password
authentication-ldap.netid_email_domain = @mpba.mp.br
#authentication-ldap.login.groupmap.1 = ou=ldap-dept1:dspace-group1
#authentication-ldap.login.groupmap.2 = ou=ldap-dept2:dspace-groupA
#authentication-ldap.login.groupmap.3 = ou=ldap-dept3:dspace-groupA
#authentication-ldap.login.groupmap.attribute = group
#authentication-ldap.login.groupmap.1 = ldap-dept1:dspace-group1
#authentication-ldap.login.groupmap.2 = ldap-dept2:dspace-groupA
#authentication-ldap.login.groupmap.3 = ldap-dept3:dspace-groupA

# Enables support for StartTLS (default is false). If this flag is true be sure provider_url looks like:
#authentication-ldap.starttls=true 

I have two authentication methods on and my 'authentication.cfg' is as follows:

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \ org.dspace.authenticate.PasswordAuthentication,\ org.dspace.authenticate.LDAPAuthentication

My problem is.. Dspace is saying that my credentials are wrong as you can see here by the attached photo. I know it seems like I'm giving the wrong information (username and password) but I think something else is happening. Something really strange happens too: my 'authentication-ldap.provider_url' attribute inside 'authentication-ldap.cfg' seems to be partially commented (its blue colored). So I don't know if it's really being taking in consideration. (It's because of '//')

Thanks in advance for helping me!!!
dspace-credentials-not-valid.png
authentication-ldap.provider_url.png

Jeffrey Sheldon

unread,
Jul 29, 2019, 3:16:52 PM7/29/19
to DSpace Technical Support
Michael,

Although I'm sure you've verified all the config aspects, does your LDAP server use SSL?

authentication-ldap.provider_url = ldaps://intranet.mpba.mp.br:636/

I don't believe there are any case-specific issues with respect to search_context, but every example I've seen (and used) had lower case. Eg:

authentication-ldap.search_context = ou=Funcionarios,dc=intranet,dc=mp,dc=ba,dc=gov,dc=br

You might want to find an independent LDAP application to see if you can use the exact same credentials and settings to traverse the LDAP tree and possibly search for users to see what's returned. If you can do that independently, that's a good sign.

With auto register, the setting is generally "true" to match credentials and/or create a new account to match the LDAP username. You have autoregister set to "false", which suggests that you're trying to log in to an account which already exists in your DSpace installation. If it doesn't, you'll likely have problems there.

authentication-ldap.autoregister = true

If you're using an installation that you can test configurations out on without disrupting users, you might also want to change the authentication order to choose LDAP first and internal password second so that LDAP is always first and the DSpace local account information is the failover.

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \ org.dspace.authenticate.LDAPAuthentication,\
org.dspace.authenticate.PasswordAuthentication,\

If anyone notices problems with my logic here, please chime in.


-Jeff


________________________________________
From: dspac...@googlegroups.com <dspac...@googlegroups.com> on behalf of Michel Souza <s.sj...@gmail.com>
Sent: Monday, July 29, 2019 1:57 PM
To: DSpace Technical Support
Subject: [dspace-tech] Re: LDAP Login issues - DSpace v5

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \ org.dspace.authenticate.PasswordAuthentication,\ org.dspace.authenticate.LDAPAuthentication

Here are my settings:

authentication-ldap.provider_url = ldap://ldap.domain.com:389<http://ldap.domain.com:389>


authentication-ldap.id_field = sAMAcoountName
authentication-ldap.object_context = dc=domain,dc=com
authentication-ldap.search_context = dc=domain,dc=com
authentication-ldap.email_field = mail
authentication-ldap.surname_field = sn
authentication-ldap.givenname_field = givenName
authentication-ldap.search_scope = 2
#authentication-ldap.search.anonymous = false
authentication-ldap.search.user = cn=user,ou=someou,dc=domain,dc=com
authentication-ldap.search.password = password

I used an LDAP browsing tool from the server with the service account I am attempting to use for Dspace and was able to run queries with it against our AD server. I also used ldapsearch on a UNIX box and the specified credentials and that worked as well so I am fairly certain the issue is with Dspace. Domain users reside in multiple OUs that are one level down from the root for example, cn=user1,ou=Contractors,dc=domain,dc=com and so on for FTEs, vendors and other types of employees.

--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---


You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com<mailto:dspace-tech...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/34529f48-6452-492d-9f13-65ae9719c9d1%40googlegroups.com<https://groups.google.com/d/msgid/dspace-tech/34529f48-6452-492d-9f13-65ae9719c9d1%40googlegroups.com?utm_medium=email&utm_source=footer>.

Michel Souza

unread,
Jul 30, 2019, 12:35:22 PM7/30/19
to DSpace Technical Support
Jeff, I'd like to thank you for your quick and really good answer. I followed almost everything you suggested and LDAP Authentication works for me. I think the most important of it was the authentication-ldap.autoregister = true attribute that was set to 'false'. I turned it to 'true' and it worked like a charm. 

I have one doubt: this attribute 'xmlui.force.ssl = true'
It's used to PasswordAuthentication? I ask this because when I turned this to 'true' I got an error: "Its not possible to access this site" and the page doesn't load.



Em quarta-feira, 12 de julho de 2017 17:55:43 UTC-3, Tim Cullings escreveu:

Jeffrey Sheldon

unread,
Jul 30, 2019, 12:57:18 PM7/30/19
to DSpace Technical Support
Michael,

Glad to hear that things have improved!

xmlui.force.ssl should only apply to content through the web frontend if you have an SSL cert configured for your webserver software. Setting that attribute to "true" makes it automatically kick in following the independent process of making a successful authentication. In other words, that setting and authentication aren't related other than that one won't work without the other.

In this case, unless I'm missing something magical that xmlui.force.ssl produces, I leave it set as false and rely on Apache with an SSL certificate to enforce HTTPS at all times, authenticated or not. This approach certainly helps with the occasional conflict of session handling where a logged in user might click on a link that has http:// hardcoded and DSpace produces the destination page as if the person isn't logged in (until the person manually changes the URL to https:// and the session is restored). I believe xmlui.force.ssl is simply a very strict way of saying, "don't allow anything to load while logged in and any of the resulting content isn't coming over https://" (such as an image or whatnot and probably only to reduce the risk of an authenticated session being compromised or eavesdropped on). It would be interesting to know if you have an SSL certificate configured for your webserver and, if so, whether the error you land on shows http:// in the URL field instead of https://, something the might require independent configuration in the web server software. If you don't have an SSL certificate, then you definitely don't want xmlui.force.ssl = true.


-Jeff


________________________________________
From: dspac...@googlegroups.com <dspac...@googlegroups.com> on behalf of Michel Souza <s.sj...@gmail.com>

Sent: Tuesday, July 30, 2019 11:35 AM


To: DSpace Technical Support
Subject: [dspace-tech] Re: LDAP Login issues - DSpace v5

Jeff, I'd like to thank you for your quick and really good answer. I followed almost everything you suggested and LDAP Authentication works for me. I think the most important of it was the authentication-ldap.autoregister = true attribute that was set to 'false'. I turned it to 'true' and it worked like a charm.

Reply all
Reply to author
Forward
0 new messages