Also, here is the log output from OpenLDAP that shows a little better
the query:
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 fd=13 ACCEPT from
IP=7.7.7.7:30696 (IP=0.0.0.0:636)
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 fd=13 TLS established
tls_ssf=128 ssf=128
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 op=0 BIND
dn="cn=Manager,dc=mydomain,dc=com" method=128
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 op=0 BIND
dn="cn=Manager,dc=mydomain,dc=com" mech=SIMPLE ssf=0
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 op=0 RESULT tag=97
err=0 text=
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 op=1 SRCH
base="ou=people,dc=mydomain,dc=com" scope=2 deref=3
filter="(uid=test)"
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 op=1 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 op=2 UNBIND
Feb 20 11:29:44 mydomain slapd[1912]: conn=4184 fd=13 closed
Feb 20 11:29:44 mydomain slapd[1912]: conn=4185 fd=13 ACCEPT from
IP=7.7.7.7:32872 (IP=0.0.0.0:636)
Feb 20 11:29:44 mydomain slapd[1912]: conn=4185 fd=13 TLS established
tls_ssf=128 ssf=128
Feb 20 11:29:44 mydomain slapd[1912]: conn=4185 op=0 do_bind: invalid
dn ("cn=Test User+gidNumber=1000+homeDirectory=/home/test+loginShell=/
bin/bash+shadowLastChange=15337+shadowMax=99999+shadowMin=
+shadowWarning=7+uid=test
+uidNumber=1003",ou=people,dc=mydomain,dc=com)
Feb 20 11:29:44 mydomain slapd[1912]: conn=4185 op=0 RESULT tag=97
err=34 text=invalid DN
Feb 20 11:29:44 mydomain slapd[1912]: conn=4185 fd=13 closed
(connection lost)
On Feb 20, 1:37 pm, Chad <c...@pur-logic.com> wrote:
> Hello:
>
> I have an OpenLDAP server running ldaps. It's a very simple and basic
> configuration that I use for identity management for linux boxes. My
> structure is as follows:
>
> Root DSE
> dc=mydomain,dc=com
> ou=group
> <entry>
> objectClass: posixGroup
> cn: admins
> gidNumber: 1001
> memberUid: test
>
> ou=people
> objectClass: account
> objectClass: posixAccount
> objectClass: shadowAccont
> cn: Test User
> gidNumber: 1000
> uid: test
> homeDirectory: /home/test
> uidNumber: 1003
> loginShell: /bin/bash
> userPassword: {SSHA} hashed password
>
> I'm able to correctly configure the settings and connect to the server
> in the configuration screen using the following parameters:
>
> Server: ldaps://mydomain.com:636
> root DN: dc=mydomain,dc=com
> User search base: ou=people
> User search filter: uid={0}
> Group search base: ou=group
> Manager DN: cn=Manager,dc=purlogic,dc=biz
> Manager Password: <the correct password>
>
> I know I'm correctly connecting this way as I don't see any red error
> messages and I can see the connection happen in my JBoss logs.
>
> I check the "Logged in users can do anything" radio button and click
> "Save". However, when I try and login with the test user, it says
> login failed. My JBoss log outputs the following error message:
>
> -----------------------------------------------------------
>
> 09:32:55,258 INFO [hudson.security.AuthenticationProcessingFilter2]
> Login attempt failed:
> org.acegisecurity.AuthenticationServiceException: Failed to obtain
> InitialDirContext due to unexpected exception; nested exception is
> javax.naming.InvalidNameException: [LDAP: error code 34 - invalid DN];
> nested exception is org.acegisecurity.ldap.LdapDataAccessException:
> Failed to obtain InitialDirContext due to unexpected exception; nested
> exception is javax.naming.InvalidNameException: [LDAP: error code 34 -
> invalid DN]
> at
> org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(Ld
> apAuthenticationProvider.java:
> 238) [:]
> at
> org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.a
> uthenticate(AbstractUserDetailsAuthenticationProvider.java:
> 119) [:]
> at
> org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManage
> r.java:
> 195) [:]
> at
> org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthen
> ticationManager.java:
> 45) [:]
> at
> org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentic
> ation(AuthenticationProcessingFilter.java:
> 71) [:]
> at
> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFi
> lter.java:
> 252) [:]
> at hudson.security.ChainedServletFilter
> $1.doFilter(ChainedServletFilter.java:87) [:]
> at
> org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessi
> ngFilter.java:
> 173) [:]
> at hudson.security.ChainedServletFilter
> $1.doFilter(ChainedServletFilter.java:87) [:]
> at
> jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:61) [:]
> at hudson.security.ChainedServletFilter
> $1.doFilter(ChainedServletFilter.java:87) [:]
> at
> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(Http
> SessionContextIntegrationFilter.java:
> 249) [:]
> at
> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionCo
> ntextIntegrationFilter2.java:
> 66) [:]
> at hudson.security.ChainedServletFilter
> $1.doFilter(ChainedServletFilter.java:87) [:]
> at
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:
> 76) [:]
> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:
> 164) [:]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
> nFilterChain.java:
> 274) [:6.0.0.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
> hain.java:
> 242) [:6.0.0.Final]
> at
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:
> 81) [:]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
> nFilterChain.java:
> 274) [:6.0.0.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
> hain.java:
> 242) [:6.0.0.Final]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j
> ava:
> 275) [:6.0.0.Final]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j
> ava:
> 191) [:6.0.0.Final]
> at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssoc
> iationValve.java:
> 181) [:6.0.0.Final]
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBas
> e.java:
> 501) [:6.0.0.Final]
> at org.jboss.modcluster.catalina.CatalinaContext
> $RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
> at org.jboss.modcluster.catalina.CatalinaContext
> $RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
> at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java :
> 88) [:6.0.0.Final]
> at
> org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(Secu
> rityContextEstablishmentValve.java:
> 100) [:6.0.0.Final]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
> 127) [:6.0.0.Final]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
> 102) [:6.0.0.Final]
> at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnect
> ionValve.java:
> 158) [:6.0.0.Final]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav a:
> 109) [:6.0.0.Final]
> at
> org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke
> (ActiveRequestResponseCacheValve.java:
> 53) [:6.0.0.Final]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> 362) [:6.0.0.Final]
> at
> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:504) [:
> 6.0.0.Final]
> at org.apache.coyote.ajp.AjpProtocol
> $AjpConnectionHandler.process(AjpProtocol.java:437) [:6.0.0.Final]
> at org.apache.tomcat.util.net.JIoEndpoint
> $Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: org.acegisecurity.ldap.LdapDataAccessException: Failed to
> obtain InitialDirContext due to unexpected exception; nested exception
> is javax.naming.InvalidNameException: [LDAP: error code 34 - invalid
> DN]
> at
> org.acegisecurity.ldap.DefaultInitialDirContextFactory.connect(DefaultIniti
> alDirContextFactory.java:
> 193) [:]
> at
> org.acegisecurity.ldap.DefaultInitialDirContextFactory.newInitialDirContext
> (DefaultInitialDirContextFactory.java:
> 261) [:]
> at
> org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:123) [:]
> at
> org.acegisecurity.ldap.LdapTemplate.retrieveEntry(LdapTemplate.java:
> 165) [:]
> at
> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator.bindWithDn
> (BindAuthenticator.java:
> 87) [:]
> at
> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator.authentica
> te(BindAuthenticator.java:
> 72) [:]
> at
> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2.authentic
> ate(BindAuthenticator2.java:
> 49) [:]
> at
> org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(Ld
> apAuthenticationProvider.java:
> 233) [:]
> ... 38 more
> Caused by: javax.naming.InvalidNameException: [LDAP: error code 34 -
> invalid DN]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:
> 2982) [:1.6.0_26]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:
> 2789) [:1.6.0_26]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703) [:
> 1.6.0_26]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293) [:
> 1.6.0_26]
> at
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
> [:1.6.0_26]
> at
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
> [:1.6.0_26]
> at
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:
> 136) [:1.6.0_26]
> at
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:
> 66) [:1.6.0_26]
> at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:
> 667) [:1.6.0_26]
> at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
> [:1.6.0_26]
> at javax.naming.InitialContext.init(InitialContext.java:223) [:
> 1.6.0_26]
> at javax.naming.InitialContext.<init>(InitialContext.java:197)
> [:1.6.0_26]
> at
> javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:
> 82) [:1.6.0_26]
> at
> org.acegisecurity.ldap.DefaultInitialDirContextFactory.connect(DefaultIniti
> alDirContextFactory.java:
> 180) [:]
> ... 45 more
>
> ---------------------------------------------
>
> I really do believe that I have a valid DN setting, as the JBoss logs
> will show the unencrypted response from the LDAP server, which
> contains all of the information from that user. I'm really stumped on
> what could be the issue. Any insight would be greatly appreciated,
> thanks!
