One of the features I'm most looking forward to utilizing in DSpace 1.5.2 is the LDAPHierarchicalAuthentication option, which I think is designed to help institutions like Rhodes, which have separate LDAP containers for different groups of users.
Faculty and Staff are in: cn=Users,dc=rhodes,dc=edu Students are in: ou=Students,dc=rhodes,dc=edu Temporary Staff are in: ou=Temp Accounts,dc=rhodes,dc=edu In DSpace 1.4.x, we used LDAP auth for our faculty and staff and just created local ePerson accounts manually for students and them use their local DSpace password and email address to log in (i.e. not LDAP). With 1.5.2, we would like to use the LDAPHierarchicalAuthentication auth method to allow all users with ePerson accounts in DSpace to log in. (In other words, we would like the ability to control who can log into DSpace by creating the ePerson accounts for those folks manually but letting the authentication for that ePerson account to happen via LDAP rather than students having to use a local DSpace password.) Our LDAP server is Microsoft Active Directory, which doesn't allow anonymous logins. We do have a generic ldap search login account that we use for other services to provide a authenticated account to bind and search Active Directory. I tried to turn on LDAPHierarchicalAuthentication by making the following changes in dspace.cfg: plugin.sequence.org.dspace.authenticate.AuthenticationMethod = org.dspace.authenticate.LDAPHierarchicalAuthentication,org.dspace.authenticate.PasswordAuthentication ldap.search_scope = 2 ldap.search.user = cn=ourldapuser,cn=Users,dc=rhodes,dc=edu ldap.search.password = ourpassword ldap.netid_email_domain = @rhodes.edu With these settings, no one was able to log in via LDAP. It wasn't clear if I needed to keep the main LDAP auth method (org.dspace.authenticate.LDAPAuthentication) in the AuthenticationMethod config statement (in the middle) or not. Does LDAPHierarchicalAuthentication use the other LDAP auth settings in dspace.cfg? What is the search_scope? The number of levels down from the top level that the search user will browse? Does the search LDAP user identify which container the particular user that is trying to authenticate is located and then try a connection as that user with their password, not that it knows the full login string for that user? Is that how it is supposed to work? It could be that something else is going on. Here is the output from the log file at this time of my failed logins under LDAPHierarchicalAuthentication: 2009-10-14 13:42:32,276 INFO org.dspace.authenticate.LDAPHierarchicalAuthentication @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:auth:attempting trivial auth of user=penning...@rhodes.edu 2009-10-14 13:42:32,280 WARN org.dspace.authenticate.LDAPHierarchicalAuthentication @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:ldap_attribute_lookup:type=failed_search javax.naming.CommunicationException\colon; dc1.rhodes.educn=Users,dc=rhodes,dc=edu\colon;389 [Root exception is java.net.UnknownHostException\colon; dc1.rhodes.educn=Users,dc=rhodes,dc=edu] 2009-10-14 13:42:32,281 INFO org.dspace.authenticate.LDAPHierarchicalAuthentication @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:failed_login:no DN found for user penning...@rhodes.edu 2009-10-14 13:42:32,281 INFO org.dspace.authenticate.PasswordAuthentication @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:authenticate:attempting password auth of user=penning...@rhodes.edu 2009-10-14 13:42:32,282 INFO org.dspace.app.webui.servlet.PasswordServlet @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:failed_login:email=penning...@rhodes.edu, result=2 2009-10-14 13:43:07,042 INFO org.dspace.authenticate.LDAPHierarchicalAuthentication @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:auth:attempting trivial auth of user=pennington 2009-10-14 13:43:07,046 WARN org.dspace.authenticate.LDAPHierarchicalAuthentication @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:ldap_attribute_lookup:type=failed_search javax.naming.CommunicationException\colon; dc1.rhodes.educn=Users,dc=rhodes,dc=edu\colon;389 [Root exception is java.net.UnknownHostException\colon; dc1.rhodes.educn=Users,dc=rhodes,dc=edu] 2009-10-14 13:43:07,046 INFO org.dspace.authenticate.LDAPHierarchicalAuthentication @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:failed_login:no DN found for user pennington 2009-10-14 13:43:07,047 INFO org.dspace.authenticate.PasswordAuthentication @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:authenticate:attempting password auth of user=pennington 2009-10-14 13:43:07,047 INFO org.dspace.app.webui.servlet.LDAPServlet @ anonymous:session_id=0A2B06CC56BA82232BA32209C6B2F463:ip_addr=10.10.2.29:failed_login:netid=pennington, result=2 >From this, it looks like the our service LDAP account is having trouble >binding to our LDAP server, and it is at least using the LDAP server host + >domain name to know what server to attempt to log into, so some of the main >LDAP settings from dspace.cfg to appear to be used. But what is this >"java.net.UnknownHostException\colon;" stuff? Can anyone that has gotten LDAPHierarchicalAuthentication working provide any pointers? Do I even have the right idea about how this is supposed to work? Thanks in advance for the help... -- Stacy Pennington Rhodes College penning...@rhodes.edu (901) 843-3968 ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
