[jcifs] Closed sockets result in an "unkown user name or bad password"-ex ception

[Michael B Allen]

On Wed, 8 Jun 2005 14:35:16 +0200 
"Marro, Donato" <marro at e-Spirit.de> wrote:

> Hi,
> 
> i wrote a little servlet for testing authentication issues under
> weak network conditions. The weak network conditions are simulated
> through a delay in the NTLM-authentication part.
> 
<snip>
> public class AuthServlet extends HttpServlet {
> 
> 	// Value for jcifs.smb.client.soTimeout
> 	private static final String  soTimeout = "500";
> 	// Value for the delay between two NTLM-authentication steps
> (simulating weak network conditions)
> 	private static final int authDelay = 500;
>
<snip>
> 
> Now setting the value for jcifs.smb.client.soTimeout to a value near
> or equal to the configured delay will cause the application to throw
> "unknown user name or bad password"-exceptions while calling the exists()-
> method. This increases the "failed-login" counter of this user in the
> Active Directory (what leads to locked user-accounts).
> 
> Excerpt from the log-file:
> 
> [14:18:47 08 Jun 2005]   DEBUG (AuthServlet) - Creating NTLM-Header for
> response...
> [14:18:47 08 Jun 2005]   DEBUG (AuthServlet) - Performing
> NTLM-authentication against server myServer...
> [14:18:48 08 Jun 2005]   DEBUG (AuthServlet) - Performing
> NTLM-authentication against server myServer...
> [14:18:48 08 Jun 2005]   DEBUG (AuthServlet) - User 'E-SPIRIT\marro'
> successfully authenticated via NTLM against Server myServer/192.168.100.10
> [14:18:48 08 Jun 2005]   ERROR (AuthServlet) - Access to file
> smb://myServer/myShare/ failed!
> jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad
> password.
>         at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:425)
>         at jcifs.smb.SmbTransport.send(SmbTransport.java:528)
>         at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:263)
>         at jcifs.smb.SmbSession.send(SmbSession.java:220)
>         at jcifs.smb.SmbTree.treeConnect(SmbTree.java:134)
>         at jcifs.smb.SmbFile.connect(SmbFile.java:790)
>         at jcifs.smb.SmbFile.connect0(SmbFile.java:760)
>         at jcifs.smb.SmbFile.exists(SmbFile.java:1245)
>         at AuthServlet.doGet(AuthServlet.java:79)
> 
> 
> I think this behavior is caused by a socket which is closed while
> performing the NTLM-authentication.

Yes, if the socket closes because soTimeout expired or because of an
error while NTLM authentication is in progress you will get errors. There
is not much I can do about this because there's no way to "restart" the
NTLM authentication process. The way NTLM authentication is triggered
is to send the 403 WWW-Authenticate: NTLM response but if you do that
while negotiating the client (IE) will just think the authentication
failed and pop up the Network Password Dialog.

A slight improvement would be to add some kind of ref counting to the
transport so that it doesn't close due to soTimeout expiring. But that
still doesn't protect against socket exceptions so it would not be all
that useful.

In practice this really shouldn't be an issue. The NTLM HTTP Filter
sets soTimeout to a pretty high value (10 minutes I think it is) and
the transport must be idle for that long before it closes. So IOW the
transport would have to be idle for 10 minutes when at that exact moment
(plus or minus a few seconds depending on how "weak" your network is)
a user initiates NTLM HTTP authentication only to fail because the
soTimeout expired in the middle. With a sufficiently high soTimeout
value it's just not going to happen.

If it does happen frequently then it's probably not the soTimeout but
rather socket errors because the network is messed up (e.g. network card
is half-duplex on full-duplex switch). Do you see socket errors in the
log? Just set soTimeout = 0 (meaning never close the transport). If you
still get errors you know it's something else going on.

Or it's a concurrency flaw but we've talked about this before and I want
to stress again that there has been very little evidence to support this
theory (actually none since the last rev). But a concurrency flaw could
exhibit these symptoms so I have to consider it.

> But why does the NTLM-authentication
> not fail in this case and so prevents the user from accessing a file or
> directory with invalid credentials?

Somehow the half-baked or old credentials are being used. Are you using
the stock NTLM HTTP Filter? If so it's technically a bug albeit sort
of irrelevant.

Mike