AW: [jcifs] Weird behaviour with NTLMHttpFilter

[Stefan Müller]

Hi Swapnil,

I managed to reproduce the behavior that I ran into last year. The exception code is "0xC0000022: jcifs.smb.SmbAuthException: Access is denied.". I slightly modified the NtlmHttpFilter class so it references the additional static logoff method of the SmbSession and covers some issues mentioned below. I attached a patch file, that contains code changes for the 1.2.25 release. Keep in mind it's a set of quick and dirty changes, provided without any kind of warranty. Before you mod and re-compile the library I would suggest that you change log level setting (jcifs.util.loglevel) to at least 3 and reproduce the steps that lead to the error. Check the "stdout"-log of tomcat, you should find the exception code "0xC0000022" somewhere at the end of the file otherwise the root cause is likely to be different compared to my case. BTW, I found out that if you confirm the login dialogue three times within Internet explorer then this does not quite mean that authentication of the user has been successful. IE 7.0 on my XP SP2 box simply stops trying after the third unsuccessful logon approach unless the page is being refreshed manually.

Remarks: as my records tell me I did spend some time on getting rid of the issue by using pre-authentication and by parametrizing jcifs.smb.client.ssnLimit to 1 but without considerable success. DC is WinServer 2003, x64. Tomcat 5.5 is hosted on XP SP2 32-BIT (not member of the domain), JRE 6 as VM. I extended my code patch because the productive environment showed up some further problems that I consider to be related with race conditions. So the users hit one of the following exceptions:

0xC0000005: jcifs.smb.SmbAuthException: Invalid access to memory location
jcifs.smb.SmbException / TransportException ... Connection timeout
java.net.SocketException: socket closed / SmbTransport::peekKey() / Transport::readn()

I got rid of the first two exceptions by putting the NTLM handshake into a synchronized block on a local synchronization object. I put a redundant condition check within the catch-block of Transport::loop(). The exception still occurs, gets caught but a further call on Transport::disconnect() is omitted. On stressing the server using a multi-threaded DoS routine (or if two users pass the authentication routine concurrently) - I still get this one:

NtlmHttpFilter: ...\Administrator: 0xC000006D: jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password.
Sometimes followed by:

java.net.SocketException: Connection reset
        at java.net.SocketInputStream.read(Unknown Source)
        at jcifs.util.transport.Transport.readn(Transport.java:29)
        at jcifs.smb.SmbTransport.peekKey(SmbTransport.java:364)
        at jcifs.util.transport.Transport.loop(Transport.java:100)
        at jcifs.util.transport.Transport.run(Transport.java:277)
        at java.lang.Thread.run(Unknown Source)

Good luck.

Regards
Stefan

-----Ursprüngliche Nachricht-----
Von: Swapnil Patil [mailto:swapnil123patil at gmail.com]
Gesendet: Donnerstag, 01. Jänner 2009 12:36
An: Stefan Müller
Cc: jcifs at lists.samba.org
Betreff: Re: [jcifs] Weird behaviour with NTLMHttpFilter

Hi Stefan ,

Thank you for you answere. Its nice to see solution to my problem.

>>>"to mod the SmbSession in that way that it forcefully called the disconnect method of the underlying transport as soon as the logoff >>>method was being called."
Can you give more inputs on it ? I am newbie , I want do these changes for me.

"Allowing multiple domains without trusts" This is my next target but
first I have to get over current problem.

I am using jcifs-1.2.25a . Is this issue resolved in version 1.4 ?


On Wed, Dec 31, 2008 at 9:54 PM, Stefan Müller <stefan.mueller at issp.cc> wrote:
> Hi,
>
> I experienced similar issues at the end of 2007 with jCIFS build 1.2.17. The first user went fine, the second user (different user account, different host) received a 403 HTTP error. After a certain time period (I think it was suspiciously close to the SO_TIMEOUT value I had defined) or when restarting Tomcat (5.5) it started working again for the next "first user" that had been the second one in the initial call.
>
> When implementing the NTLM handshake directly (without the filter class and with the motivation to cover multiple domains without trusts in this effort) I eventually ended up with the "solution" to mod the SmbSession in that way that it forcefully called the disconnect method of the underlying transport as soon as the logoff method was being called. So I gave up the benefit of impersonation but it did work that way. Without the modification the handshake apparently failed at the logon method of the SmbSession class. Unfortunately, I did not backup the exception.
>
> Regards
>
> ---------------------------------------------------------------------------
> Stefan Müller
> CTO
>
> ISSP Software und Service GmbH
> Eichenweg 6
> A-4048 Puchenau/Linz
> Mob.: +43 664 39 59 518
> Fax.: +43 732 221705-28
> Mail: stefan.mueller at issp.cc
> -------------------------------------------------
> Firmenbuchgericht: LG Linz
> Firmenbuchnummer: 218098 h
>
>
> -----Ursprüngliche Nachricht-----
> Von: jcifs-bounces+stefan.mueller=issp.cc at lists.samba.org [mailto:jcifs-bounces+stefan.mueller=issp.cc at lists.samba.org] Im Auftrag von Swapnil Patil
> Gesendet: Mittwoch, 31. Dezember 2008 16:07
> An: jcifs at lists.samba.org
> Betreff: [jcifs] Weird behaviour with NTLMHttpFilter
>
> Hi,
> I am using NTLMHttpFilter.
> Server : Tomcat 5.0. On machine 192.168.2.79.
> After starting tomcat if test my application from  192.168.5.120.(its
> in same domain where my apllication is deployed) NTLM works fine.
> After this if I test my application from server itself i.e
> 192.168.2.79 it ask for user name password to connect 192.168.2.79. !
> I can login if click url 3 times !.  vice-versa of this is true i.e.
> afteer server restart if strat testing from 192.168.2.79 then I
> encounter problem at 192.168.5.120
> web.xml is as follows
> <filter>
>    <filter-name>NtlmHttpFilter</filter-name>
>     <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
>     <init-param>
>          <param-name>jcifs.netbios.wins</param-name>
>          <param-value>192.168.5.124,192.168.5.126</param-value>
>     </init-param>
>     <init-param>
>          <param-name>jcifs.smb.client.domain</param-name>
>          <param-value>techo</param-value>
>     </init-param>
> </filter>
> <filter-mapping>
>   <filter-name>NtlmHttpFilter</filter-name>
>   <url-pattern>/index.jsp</url-pattern>
> </filter-mapping>
>
> --- index.jsp
> I am getting user name from session.getAttribute("NtlmHttpAuth");. And
> then puting that user in request. and then I am submiting page to
> login.jsp
> I am hiting index.jsp to test my application.
> I am newbie in NTLM so this may be as per design behaviour.
> Does any know about such behavior ?
> --
> Thanks & Regards
> Swapnil Patil.
>



--
Thanks & Regards
Swapnil Patil.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ExperimentalNTLMFilterMod.patch
Type: application/octet-stream
Size: 4668 bytes
Desc: ExperimentalNTLMFilterMod.patch
Url : http://lists.samba.org/archive/jcifs/attachments/20090102/134c2e8a/ExperimentalNTLMFilterMod.obj