Outlook 2003 error on expires credentials

[seiryu]

Hello,

First off, I tried searching the forums as well as google and couldn't find anything in reference to this. If anyone has some documentation to point me to, that would be great!

We have a couple of MS outlook 2003 users who every so often get the following message when they try to send an email:

Note: File Upload Fault. Please contact your system administrator regarding 
maximum message and attachment sizes.

Looking through the logs, the actual error is:

2009-01-05 10:07:03,866 WARN  [btpool0-12180] [] SoapEngine - unable to construct SOAP context
com.zimbra.common.service.ServiceException: auth credentials have expired
ExceptionId:btpool0-12180:1231178823866:8fc904f778c62a96
Code:service.AUTH_EXPIRED
    at com.zimbra.common.service.ServiceException.AUTH_EXPIRED(ServiceException.java:287)
    at com.zimbra.soap.ZimbraSoapContext.<init>(ZimbraSoapContext.java:191)
    at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:212)
    at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:167)
    at com.zimbra.soap.SoapServlet.doPost(SoapServlet.java:269)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at com.zimbra.cs.servlet.ZimbraServlet.service(ZimbraServlet.java:189)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
    at org.mortbay.servlet.UserAgentFilter.doFilter(UserAgentFilter.java:81)
    at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter.java:132)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
    at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:716)
    at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.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(HandlerWrapper.java:139)
    at org.mortbay.jetty.handler.rewrite.RewriteHandler.handle(RewriteHandler.java:350)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
    at org.mortbay.jetty.Server.handle(Server.java:313)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
    at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
    at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

So I'm assuming their credentials have expired, but the problem is that they have no way of knowing this until they try to send an email and get the failure. Is there any mechanism within the outlook connector that can warn a user that their credentials have expired? Am I looking in the wrong place, would this be a mechanism of the zimbra server rather than the outlook connector? If so I apologize.

They can successfully restart outlook and start receiving emails again, but they just need to know when to do the restart. Any help would be greatly appreciated.

Thanks!

[mikelcu]

I can confirm this error as late a 5.0.11. We've seen it several times, particularly surrounding maintenance windows where mail service gets interrupted for a few minutes. I think the client may fail to connect, then stop trying, leading to expired creds. Luckily for us, it's been an isolated thing but we have not found a fix or workaround.

[sam]

The message reported by the connector and the message you've shown in the server logs may or may not be correlated, and my hunch is they aren't.

The connector is reporting the upload of the message to send failed because it was too large while the server log snippet shows a SOAP request indicating the auth token has expired. The reason I think they aren't correlated is that the send from ZCO uses does a file upload which isn't a SOAP request.

To get the root cause, enable ZCO logging with HTTP tracing (using ZCOLogCtl.exe) on one of the client machines and reproduce the behavior. Inspect the logs and search for the file upload fault. I'm guessing you'll see that the user tried to send a message and the server rejected the upload because the message is too large.

[sam]

Originally Posted by mikelcu

I can confirm this error as late a 5.0.11. We've seen it several times, particularly surrounding maintenance windows where mail service gets interrupted for a few minutes. I think the client may fail to connect, then stop trying, leading to expired creds. Luckily for us, it's been an isolated thing but we have not found a fix or workaround.

It very well might be that the connector is reporting this error when a mailbox is in maintenance mode. This may be a case of a poor error message. Note the connector cannot send the message until the mailbox is out of maintenance mode so it will generate some type of local fault (local NDR) until the mailbox is unlocked.

[mikelcu]

No maintenance mode here, I primarily saw the auth errors when we took the server all the way down for maintenance.

Is the Zimbra internal auth by any chance kerberos-like? i.e. does a client get credentials that are renewable, but after a period of time they need to be completely refreshed? Could a client come online after a period of inactivity with credentials that appeared OK but were considered expired by the server?

Currently, this error is only happening for laptop users who may be disconnected from the server for extended periods of time. However, short sleeps or disconnections on the laptops don't cause this. It only happens afters several days. Given that it does not happen on desktops that are always on and connected, I'm wondering if there is some renew/refresh mechanism for client credentials that these laptops cannot perform because they are disconnected. Then, when they get back online and try to renew creds, they have credentials in some state that cannot be renewed, leading to this exception.

In kerberos-land, this would be equivalent to getting a ticket with a duration of X hours that can be renewed for Y days. A client can renew the ticket repeatedly within Y days, but after Y days are up, a complete re-auth is required. If a client were offline when the time went past Y days, then came back online, the credentials could not be renewed without a complete refresh. If the client was in any way unaware that the creds were expired and tried to use them, it would yield similar errors.

No idea if Zimbra auth works like this at all, but there are some parallels... just brainstorming,

-Mike

[mikelcu]

Oh, I should add that we've seen the "File Upload Fault" as well, and though it does happen with too-large-files, it also *does* pop up when this auth error is happening, even with files way below the size limit.