SAC Access after 10.0.5 upgrade

[Trevor Benson]

I just upgraded from 10.0.2 (I beleive) to 10.0.5. Afterwords we were having sign in issues to SAC. We had disabled the require domain on authentication, so thought maybe that was acting up and tried with and without domain name and fqdn, nothing seemed to let us in.

After having problems with this previously i started checking the system a bit and found an omldapsearch. Leaving the BindDN set to admin@node.domain.com failed, it was only able to be done with DN=admin. This then returned the omHostFqdn as matching one of the domains mail is accepted for but not the FQDN of the system itself. I remembered the issues Florian helped us solve previously so i ran sxmodfqdn and set it back to the current hostname of the server. I restarted the scalix services, but it seems I still cannot sign into SAC.

Below is the output from the caa.log that says I have Invalid Credentials, even though they are the admin credentials that work with BindDN on the omldapsearch.

Code: Select all

2006-12-18 15:20:16,550 ERROR [LDAPHelperUtils.getTargetHost:362] javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
2006-12-18 15:20:16,722 ERROR [RbacAuthorizationHelper.isScalixUser:240] Exception:
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
        at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
        at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Unknown Source)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(Unknown Source)
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Unknown Source)
        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(Unknown Source)
        at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
        at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
        at javax.naming.InitialContext.init(Unknown Source)
        at javax.naming.InitialContext.<init>(Unknown Source)
        at javax.naming.directory.InitialDirContext.<init>(Unknown Source)
        at com.scalix.sac.ubermgr.ldap.LDAPQuery.initContextWithCN(LDAPQuery.java:88)
        at com.scalix.sac.ubermgr.rbac.RbacAuthorizationHelper.isScalixUser(RbacAuthorizationHelper.java:224)
        at com.scalix.sac.ubermgr.ldap.LDAPServiceHandler.Login(LDAPServiceHandler.java:122)
        at com.scalix.sac.ubermgr.caa.RESService.authenticateAndAuthorizeUser(RESService.java:157)
        at com.scalix.sac.ubermgr.caa.RESService.doRequest(RESService.java:83)
        at com.scalix.caa.soap.SOAPDispatcherServlet.onMessage(SOAPDispatcherServlet.java:267)
        at com.scalix.caa.soap.SAAJServlet.doPost(SAAJServlet.java:123)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
        at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675)
        at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
        at java.lang.Thread.run(Unknown Source)


Thanks in advance for any help.

[chris]

Hi Trevor,

that query should be being run by the sxqueryadmin user.

Can you confirm that that user's password is the same as is set in your psdata file, and retest?

Cheers,

Chris

[ng]

hi,

we do have exactly the same error after upgrade to 10.0.5 from 10.0.2.
password for sxadmin is the same as in psdata.

florian also helped us to correct a similar problem on a sx11rc2 machine by checking all config files if fqdn was used.

do you already know what causes this ?

nikolaus

[chris]

hi,
password for sxadmin is the same as in psdata.

sxqueryadmin as well?

Chris

[lowen]

I had this problem, too.

It seems that when upgrading to 10.0.5 in the installer, if you change the password used by the sxqueryadmin, that the correct password does not get placed in the psdata file.

Note that all the other threads I've seen on this subject have been for Scalix 11; on Scalix 10 the psdata file isn't found where the advice in those other threads say to find it. It is found as

Code: Select all

/etc/opt/scalix/caa/scalix.res/config/psdata

Also, the logs are in a different place:

Code: Select all

/opt/scalix-tomcat/logs

When the upgrade to 10.0.5 occurred, I wasn't careful to enter the same ldap query password that I had originally had used; I used a different one. This newer password did not get propagated to psdata; it had the older ldap query password, still.

I changed the psdata to have the correct (tested with omldapsearch and using sxqueryadmin on that command) password, and SAC started working again.