LdapLoginModule: Unable to connect with bindDn / bindCredentials
Douglas E. Engert
deengert at anl.gov
Tue Jun 4 09:46:09 EDT 2013
On 6/4/2013 7:56 AM, Farrukh Najmi wrote:
> (Resending as the last time the post did not appear in users at shibboleth.net for some reason. Please excuse duplicate post.)
>
>
> After successfully using Shib 2 SSO with my SP using LDAP search via an anonymous BIND I am now trying to do the same by authenticating with a privileged user by specifying bindDn and bindCredentials
> for the JAAS config for my LdapLoginModule as follows:
>
> ShibUserPassAuth {
>
> edu.vt.middleware.ldap.jaas.LdapLoginModule required
> ldapUrl="ldap://wellfleet1.wellfleetsoftware.com:33389/"
> baseDn="dc=springframework,dc=org"
> bindDn="uid=admin,ou=system,dc=springframework,dc=org"
> bindCredentials="secret"
As David said, it is bindCredential not bindCredentials.
> ssl="false"
> userFilter="uid={0}"
> subtreeSearch="true";
> };
Try adding debug="true"
Or since it is not using ssl, a network trace might show what
is being sent.
>
> I have verified that I can connect with my LDAP server using both spring-security as well as using the JExplorer LDAP client GUI <http://jxplorer.org/>.
>
> However, when I try to login during a SAML SSO initiated by my SP I get authentication failure with the following stack trace and debug log:
>
> 18:07:03.365 - DEBUG [edu.vt.middleware.ldap.handler.DefaultConnectionHandler:74] - Bind with the following parameters:
> 18:07:03.365 - DEBUG [edu.vt.middleware.ldap.handler.DefaultConnectionHandler:75] - authtype = simple
> 18:07:03.365 - DEBUG [edu.vt.middleware.ldap.handler.DefaultConnectionHandler:76] - dn = uid=admin,ou=system,dc=springframework,dc=org
> 18:07:03.365 - DEBUG [edu.vt.middleware.ldap.handler.DefaultConnectionHandler:83] - credential = <suppressed>
> 18:07:03.366 - TRACE [edu.vt.middleware.ldap.handler.DefaultConnectionHandler:87] - env = {java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.provider.url=ldap://wellfleet1.wellfleetsoftware.com:33389/, bindCredentials=secret}
Looks like it passed bindCredentials=secret as an environment variable.
http://code.google.com/p/vt-middleware/wiki/vtldapJAAS#LdapLoginModule
says:
"Any options supplied that do not map to a defined property will be passed directly to the JNDI context."
> 18:07:03.382 - DEBUG [edu.vt.middleware.ldap.handler.DefaultConnectionHandler:163] - Error connecting to LDAP URL: ldap://wellfleet1.wellfleetsoftware.com:33389/
> javax.naming.AuthenticationException: [LDAP: error code 49 - Bind failed: null]
> at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3087) ~[na:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033) ~[na:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2835) ~[na:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749) ~[na:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) ~[na:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) ~[na:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) ~[na:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) ~[na:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) ~[na:1.7.0_21]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) ~[na:1.7.0_21]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) ~[na:1.7.0_21]
> at javax.naming.InitialContext.init(InitialContext.java:242) ~[na:1.7.0_21]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) ~[na:1.7.0_21]
> at edu.vt.middleware.ldap.handler.DefaultConnectionHandler.connectInternal(DefaultConnectionHandler.java:134) ~[vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.handler.AbstractConnectionHandler.connect(AbstractConnectionHandler.java:156) ~[vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.AbstractLdap.connect(AbstractLdap.java:1006) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.AbstractLdap.getContext(AbstractLdap.java:1058) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.AbstractLdap.search(AbstractLdap.java:214) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.auth.SearchDnResolver.resolve(SearchDnResolver.java:139) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.auth.Authenticator.getDn(Authenticator.java:106) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.jaas.JaasAuthenticator.authenticate(JaasAuthenticator.java:74) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.auth.Authenticator.authenticate(Authenticator.java:320) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.auth.Authenticator.authenticate(Authenticator.java:277) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.jaas.JaasAuthenticator.authenticate(JaasAuthenticator.java:60) [vt-ldap-3.3.6.jar:na]
> at edu.vt.middleware.ldap.jaas.LdapLoginModule.login(LdapLoginModule.java:103) [vt-ldap-3.3.6.jar:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_21]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_21]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_21]
> at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_21]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [na:1.7.0_21]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [na:1.7.0_21]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [na:1.7.0_21]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [na:1.7.0_21]
> at java.security.AccessController.doPrivileged(Native Method) [na:1.7.0_21]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [na:1.7.0_21]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [na:1.7.0_21]
> at edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet.authenticateUser(UsernamePasswordLoginServlet.java:177) [shibboleth-identityprovider-2.4.0.jar:na]
>
> What could I be doing wrong. Note I have tried specifying bindDn with fully qualified DN as well as DN relative to baseDN ( "uid=admin,ou=system" ) with no luck and same results in either case.
>
> Any advice would be greatly appreciated.
>
> --
> Regards,
> Farrukh Najmi
>
> Web:http://www.wellfleetsoftware.com
>
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the users
mailing list