Subject: Re: HTTP Authentication failing - msg#00030

Previous Message by Date: click to view message preview

Re: Closed sockets result in an "unkown user name or bad password"-ex ception

On Wed, 8 Jun 2005 14:35:16 +0200 "Marro, Donato" <marro@xxxxxxxxxxx> 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

Next Message by Date: click to view message preview

HTTP 500

Hello, I'm using the NTLM HTTP Authentication in a web application. Im running Tomcat on a windows platform. The web application intermittently throws the following error : 2005-05-25 09:04:44 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exceptionjcifs.smb.SmbException: An error occured sending the request.java.net.ConnectException : Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java :171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) at java.net.Socket.connect(Socket.java:452) at java.net.Socket.connect(Socket.java:402) at java.net.Socket.<init>(Socket.java:309) at java.net.Socket.<init>(Socket.java:211) at jcifs.netbios.NbtSocket.<init>(NbtSocket.java:59) at jcifs.smb.SmbTransport.ensureOpen(SmbTransport.java:275) at jcifs.smb.SmbTransport.send(SmbTransport.java :600) at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:854) at jcifs.smb.SmbSession.getChallenge(SmbSession.java:64) at jcifs.smb.SmbSession.getChallenge(SmbSession.java:58) at jcifs.http.NtlmHttpFilter.doFilter (NtlmHttpFilter.java:109) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java :193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext (StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke (StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java :643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext (StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service (CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) at java.lang.Thread.run(Thread.java:534) at jcifs.smb.SmbTransport.send(SmbTransport.java:630) at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:854) at jcifs.smb.SmbSession.getChallenge(SmbSession.java:64) at jcifs.smb.SmbSession.getChallenge(SmbSession.java :58) at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:109) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java :643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java :480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java :171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext (StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java :480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :594) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:619) at java.lang.Thread.run(Thread.java:534) The web.xml file : <filter>     <filter-name>NtlmHttpFilter</filter-name>     <filter-class>jcifs.http.NtlmHttpFilter</filter-class>     <init-param>         <param-name>jcifs.smb.client.domain</param-name>         <param-value>VODACOM</param-value>     </init-param>     <init-param>         <param-name>jcifs.netbios.wins</param-name>         <param-value>10.111.7.68,10.121.7.52</param-value>     </init-param>     </filter> <filter-mapping>     <filter-name>NtlmHttpFilter</filter-name>     <url-pattern>/*</url-pattern> </filter-mapping> PLEASE HELP! Jaco

Previous Message by Thread: click to view message preview

Re: Re: HTTP Authentication failing

On Wed, 8 Jun 2005 07:33:41 +0000 (UTC) Scrumpy Jak <paul.pree@xxxxxxxxxxxxxxxx> wrote: > jCIFS 1.1.11 > Second user gets > jcifs.smb.SmbException: Unverified Signature: 0.0.0.0<00>/192.168.20.101 > (Which is the IP of the domain controller specified in web.xml) > at jcifs.smb.SmbTransport.send(SmbTransport.java:674) With a valid jcifs.smb.client.{domain,username,password} supplied for "preauthentication" you should not get "Unverified Signature" exceptions. Mike

Next Message by Thread: click to view message preview

Re: Re: HTTP Authentication failing

On Thu, 9 Jun 2005 05:58:45 +0000 (UTC) Scrumpy Jak <paul.pree@xxxxxxxxxxxxxxxx> wrote: > By removing jCIFS 1.1.11, replacing it with jCIFS 1.2.0 and changing nothing > else it works fine > By pointing back to the Windows 2003 DC it reverts to letting the first user > in > and failing for the second. After glancing at the code I realize I left the signing code in total disarray in 1.2.0. It will need to be fixed. Use 1.1.11. If you can't get infrastructure to turn on port 139 use a workstation w/ 139 enabled as the "domainController". It will be slightly slower because you're going through a middle man but jCIFS scales very well. I don't even think you'll notice the difference. Then when I fix 1.2 signing code you can point back to the win2k3 DC. Mike