[daisy] Organizational units confusing LDAP authentication
Caleb Callaway
caleb at autometrix.com
Fri Jun 29 13:38:20 CDT 2007
Upon further investigation, creating the user manually in Daisy then
setting the authentication scheme to LDAP works. Seems to have something
to do with the autocreate capabilities...
Caleb Callaway wrote:
> Here are two entries my LDAP directory:
>
> dn: cn=test,dc=autometrix,dc=com
> uid: test
> cn: test
> givenName: test
> sn: test
> mail: test at autometrix.com
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: shadowAccount
> loginShell: /bin/bash
> uidNumber: 1020
> gidNumber: 100
> homeDirectory: /home/test
> gecos: test
> shadowLastChange: 13692
> userPassword:: e1NTSEF9NWliT1phdTlxZWYzQU9ydjRCVGJMR25kWlBHNXlLWTA=
>
> dn: cn=temp,ou=People,dc=autometrix,dc=com
> uid: temp
> cn: temp
> givenName: temp
> sn: temp
> mail: temp at autometrix.com
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: shadowAccount
> loginShell: /bin/bash
> uidNumber: 1020
> gidNumber: 100
> homeDirectory: /home/temp
> gecos: temp
> userPassword:: e1NTSEF9RkRSVUJJZXplUFNibGROOXVGYkxyQkQyeVp3OEhubzE=
>
> I've used both accounts to login on a Ubuntu laptop with libnss-ldap.
> The passwords are updatable by ldapasswd, etc. I've temporarily
> assigned read access to '*' in my slapd.conf file, so passwords are
> available to everyone.
>
> Here is the relevant bit of myconfig.xml:
>
> <target path="/daisy/repository/authentication/ldap">
> <configuration>
> <scheme name="ldap1" description="Test LDAP config">
> <environment>
> <property name="java.naming.factory.initial"
> value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <property name="java.naming.provider.url"
> value="ldap://192.168.1.3"/>
> <property name="java.naming.security.authentication"
> value="simple"/>
> <!-- <property name="java.naming.security.protocol"
> value="ssl"/> -->
> <property name="java.naming.security.principal"
> value="cn=$daisyLogin,ou=People,dc=autometrix,dc=com"/>
> </environment>
> <cache enabled="false" maxCacheSize="3000"
> maxCacheDuration="1800000"/>
> <autoCreateUser>
> <roles>
> <role>User</role>
> </roles>
> <defaultRole>User</defaultRole>
> <updateableByUser>true</updateableByUser>
> </autoCreateUser>
> </scheme>
> </configuration>
> </target>
>
> Using the following value doesn't allow EITHER user to authentic:
>
> <property name="java.naming.security.principal"
> value="cn=$daisyLogin,ou=People,dc=autometrix,dc=com"/>
>
> If I change it like so, the 'test' user can authentic without a
> problem (yes, I did restart the repo daemon--and the wiki, just to be
> sure):
>
> <property name="java.naming.security.principal"
> value="cn=$daisyLogin,dc=autometrix,dc=com"/>
>
> The ONLY difference is the removal of the organizational unit 'People'.
>
> The request-error-log has the following when trying to login as temp
> (with either value of java.naming.security.principal):
>
> [ERROR ] <2007-06-29 09:54:03,890>
> (daisy.repository.httpconnector.request-errors): Error authenticating
> user.
> org.outerj.daisy.repository.user.UserNotFoundException: The user with
> login "temp" does not exist
> at
> org.outerj.daisy.repository.serverimpl.user.LocalUserManagementStrategy.getUser(LocalUserManagementStrategy.java:390)
>
> at
> org.outerj.daisy.repository.commonimpl.user.UserCache.getUser(UserCache.java:87)
>
> at
> org.outerj.daisy.repository.commonimpl.user.CommonUserManager.getUser(CommonUserManager.java:80)
>
> at
> org.outerj.daisy.repository.commonimpl.user.UserManagerImpl.getUser(UserManagerImpl.java:73)
>
> at
> org.outerj.daisy.authentication.impl.UserAuthenticatorImpl.authenticate(UserAuthenticatorImpl.java:104)
>
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.avalon.activation.impl.ApplianceInvocationHandler.invoke(ApplianceInvocationHandler.java:129)
>
> at $Proxy7.authenticate(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.avalon.activation.impl.BlockInvocationHandler.invoke(BlockInvocationHandler.java:108)
>
> at $Proxy9.authenticate(Unknown Source)
> at
> org.outerj.daisy.repository.serverimpl.LocalRepositoryManager.getRepository(LocalRepositoryManager.java:159)
>
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.avalon.activation.impl.ApplianceInvocationHandler.invoke(ApplianceInvocationHandler.java:129)
>
> at $Proxy14.getRepository(Unknown Source)
> at
> org.outerj.daisy.httpconnector.HttpConnectorImpl$DaisyUserRealm.authenticate(HttpConnectorImpl.java:360)
>
> at
> org.mortbay.http.BasicAuthenticator.authenticate(BasicAuthenticator.java:64)
>
> at
> org.mortbay.http.SecurityConstraint.check(SecurityConstraint.java:442)
> at
> org.mortbay.http.HttpContext.checkSecurityConstraints(HttpContext.java:1326)
>
> at
> org.mortbay.http.handler.SecurityHandler.handle(SecurityHandler.java:81)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> at
> org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> at
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> at
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
>
> I've tried Bruno's test code from this thread as well:
> http://lists.cocoondev.org/pipermail/daisy/2006-February/003178.html
> Works without a problem.
>
> There's something I'm missing here--what is it?
>
> -Caleb
>
> _______________________________________________
> daisy community mailing list
> Professional Daisy support:
> http://outerthought.org/site/services/daisy/daisysupport.html
> mail to: daisy at lists.cocoondev.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>
More information about the daisy
mailing list