plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \
org.dspace.authenticate.LDAPAuthentication, \
org.dspace.authenticate.PasswordAuthentication
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscribe@googlegroups.com.
--
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscribe@googlegroups.com.
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>.
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.