Zimbra offers Open Source email server software and shared calendar for Linux and the Mac
Go Back   Zimbra :: Forums > Zimbra Collaboration Suite > Administrators

Welcome to the Zimbra :: Forums!
Welcome, if you would like to post a comment please register. We also encourage you to explore all things Zimbra with our team and members of the community.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 10-22-2008, 04:09 AM
Senior Member
 
Posts: 50
Default [SOLVED] error in ldap auth

Hi to all,

i try to migrate the auth of zimbra user from internal to External LDAP, my ldap server run openLdap, and

ldapsearch -xLLL -H ldap://<myserver> -b "<my basename>"

works great...

but when i try to bind zimbra to ldap i get this error (even if the credential are correct):

javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.jav a:2985)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCt x.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCt x.java:2732)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:264 6)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:283)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapC txFactory.java:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(Ldap CtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstanc e(LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext (LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(N amingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(Init ialContext.java:247)
at javax.naming.InitialContext.init(InitialContext.ja va:223)
at javax.naming.ldap.InitialLdapContext.<init>(Initia lLdapContext.java:134)
at com.zimbra.cs.account.ldap.ZimbraLdapContext.ldapA uthenticate(ZimbraLdapContext.java:441)
at com.zimbra.cs.account.ldap.LdapUtil.ldapAuthentica te(LdapUtil.java:117)
at com.zimbra.cs.account.ldap.LdapUtil.ldapAuthentica te(LdapUtil.java:154)
at com.zimbra.cs.account.ldap.Check.checkAuthConfig(C heck.java:170)
at com.zimbra.cs.service.admin.CheckAuthConfig.handle (CheckAuthConfig.java:46)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:411)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:268)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:160)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.jav a:269)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:727)
at com.zimbra.cs.servlet.ZimbraServlet.service(Zimbra Servlet.java:189)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(Ser vletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedCha in.doFilter(ServletHandler.java:1093)
at org.mortbay.servlet.UserAgentFilter.doFilter(UserA gentFilter.java:81)
at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter .java:132)
at org.mortbay.jetty.servlet.ServletHandler$CachedCha in.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(Se rvletHandler.java:360)
at org.mortbay.jetty.security.SecurityHandler.handle( SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(Se ssionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(Co ntextHandler.java:716)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebA ppContext.java:406)
at org.mortbay.jetty.handler.ContextHandlerCollection .handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle (HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:139)
at org.mortbay.jetty.handler.rewrite.RewriteHandler.h andle(RewriteHandler.java:350)
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(Htt pConnection.java:506)
at org.mortbay.jetty.HttpConnection$RequestHandler.co ntent(HttpConnection.java:844)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser. java:644)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpPa rser.java:205)
at org.mortbay.jetty.HttpConnection.handle(HttpConnec tion.java:381)
at org.mortbay.io.nio.SelectChannelEndPoint.run(Selec tChannelEndPoint.java:396)
at org.mortbay.thread.BoundedThreadPool$PoolThread.ru n(BoundedThreadPool.java:442)



any ideas?


thanks, L.
Reply With Quote
  #2 (permalink)  
Old 10-22-2008, 04:48 AM
Moderator
 
Posts: 1,554
Default

is your ldap server setup for anonymous binding, and is zimbra set for that as well? Usually that error isn't reflecting a failed login of a user account, but rather the error in the user you're trying to bind to the ldap server with in order to facilitate the authentication.
Reply With Quote
  #3 (permalink)  
Old 10-22-2008, 05:32 AM
Senior Member
 
Posts: 50
Default

Quote:
Originally Posted by bdial View Post
is your ldap server setup for anonymous binding, and is zimbra set for that as well? Usually that error isn't reflecting a failed login of a user account, but rather the error in the user you're trying to bind to the ldap server with in order to facilitate the authentication.
when i try to manually "ldapsearch" i did not bind any user, so "i think" that my ldap support anonymous binding...
Reply With Quote
  #4 (permalink)  
Old 10-22-2008, 06:08 AM
Moderator
 
Posts: 1,554
Default

yeah i woudl guess it does. Under the zimbra ldap authentication configuration do you have the setting Use DN/Password to bind to external server: on like the 3rd page on or off?
Reply With Quote
  #5 (permalink)  
Old 10-22-2008, 06:38 AM
Senior Member
 
Posts: 50
Default

Quote:
Originally Posted by bdial View Post
yeah i woudl guess it does. Under the zimbra ldap authentication configuration do you have the setting Use DN/Password to bind to external server: on like the 3rd page on or off?
off

but in the last page if a do not put user/pass the error become "empty password"
Reply With Quote
  #6 (permalink)  
Old 10-22-2008, 06:49 AM
Moderator
 
Posts: 1,554
Default

it should work because like you say using ldapsearch is doing an anonymous bind. Maybe as a test try turning bind dn/password on and binding as the admin user for your openldap server.

turning on debug on your openldap and looking at the syslog messages on there could help track down the problem too.
Reply With Quote
  #7 (permalink)  
Old 10-22-2008, 07:45 AM
Senior Member
 
Posts: 50
Default

i find the solution.. i have put a wrong filter for users
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads

Why Join?

Registering let's you ask questions, makes it easier to search, displays any files attached to posts, and notifies you about replies.

blog.zimbra.com




 

SEO by vBSEO ©2011, Crawlability, Inc.