[jcifs] NtlmHttpFilter breaks file upload UI component : SOLVED

Michael B Allen ioplex at gmail.com
Wed Mar 4 18:20:55 GMT 2009


Note: For posterity, I am CC-ing this back JCIFS list again minus
sensitive information. I will respond to the non-JCIFS related part of
your question privately from another address.

On Wed, Mar 4, 2009 at 8:12 AM, Ivan Stefanov
<ivan.stefanov at clever-soft.com> wrote:
> Hello Mike,
>
> thank you very much for your interest!
>
> All the time I have been developing and testing (with Firefox) in the same
> Windows Vista environment. I have also tested with a WindowsXP machine where
> I encounterd the same behaviour, therefore I would conclude that the problem
> has something to do with the browsers. I attach to this e-mail the Wireshark
> captures of the communication on Firefox, Opera and IE7. During this
> exchange 192.168.1.72 is the local network IP of the server on which the web
> application implementing Ntlm runs (which also happens to be my PC - I am
> just running JBoss on my local IP address), and 192.168.1.10 is the server,
> against which I verify the username and password. The username is
> "cleversoft", which shows in the packets. What I find very interesting is
> that in the IE7 and Opera communication there is a Unicode password, which
> is completely different from the ANSI password, while with Firefox both
> passwords are the same. And I personally do not understand at all why there
> are two passwords in the packet. Also noticeable is that IE7 automatically
> adds as Primary Domain in the SMB packet the name of my computer, while
> Opera and Firefox do not use this information at all.

Your observation is correct that the "Unicode Password" is indeed the
problem. As stated in the JCIFS HTTP Filter documentation cannot
support NTLMv2. IE7 and Opera are using NTLMv2 so it fails with
"Access denied" whereas FF is using NTLMv1 so it succeeds.

I did not immediately identify NTLMv2 as the issue because you did not
report an "Access denied" error, you did not mention Vista and as you
describe below, the "Invalid parameter" issue was caused by a
completely unrelated issue.

You could try setting jcifs.smb.client.useExtendedSecurity=false and
jcifs.smb.lmCompatibility=0 but I don't think that will help as
clients like Vista require NTLMv2. Again, see the "IMPORTANT" blue
message at the top of the NTLM Filter documentation for details.

> As for the "Parameter incorrect" exception, I have found out that it has
> been caused by "Public folder sharing" being ON and "Password protected
> sharing" - OFF in the Windows Vista network settings (I assume this is
> analogical to the Simple File Sharing being allowed in WinXP). Now the only
> problem which I get is the authentication not running on Opera & IE7.
>
<snip stuff not about jcifs>
>
> Michael B Allen wrote:
>
> On Tue, Mar 3, 2009 at 12:01 PM, Ivan Stefanov
> <ivan.stefanov at clever-soft.com> wrote:
>
>
> Hello everybody,
>
> The previous issue has been solved by installing the newest (3.3.0) version
> of richfaces. Perhaps it would be nice to add somewhere in the documentation
> that newer richfaces is recommended, or that older than the 3.3.0 version is
> known to have issues NtlmHttpFilter?"
>
> However, a new problem has come up. While developing, I have been
> exclusively testing on Firefox 3.0.6. When one tries to log in with this
> browser the default identification window springs up, the user enters
> username/password, the authentication goes smoothly and basically SSO works.
> However, when I have tested this on IE7 and on Opera 9.64, the
> authentication simply refuses to function anymore. The possible scenarios
> are two: either the username/password credenticals are not recognised and I
> get prompted for them again, or the browser shows the "Cannot display the
> webpage" page without asking for username/password and in my JBoss console I
> get the following stacktrace:
>
> 17:42:00,429 ERROR [ExceptionFilter] handling uncaught exception
> jcifs.smb.SmbException: The parameter is incorrect.
>     at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:542)
>     at jcifs.smb.SmbTransport.send(SmbTransport.java:644)
>     at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:307)
>     at jcifs.smb.SmbSession.send(SmbSession.java:235)
>
>
> I doubt this error has much to do with what browser was used. Have you
> been testing successfully with a a Linux or OSX client but then found
> that it failed in a Windows environment? Meaning is the pattern the OS
> and not the browser?
>
> If you send me a packet capture I can tell you more definitively what
> the error is about. The "parameter is incorrect" error is a very
> generic issue that can occur under a wide range of conditions.
>
> Of course, as stated in the NTLM HTTP Authentication Filter
> documentation and FAQ, you do know that the NtlmHttpFilter is not
> supported and is being removed? The only reason I'm interested in
> seeing a capture about this is because in theory this error should not
> occur and it just might affect the CIFS or DCERPC code.
>
> Mike
>
>
>
>     at jcifs.smb.SmbTree.treeConnect(SmbTree.java:161)
>     at jcifs.smb.SmbSession.logon(SmbSession.java:171)
>     at jcifs.smb.SmbSession.logon(SmbSession.java:164)
>     at
> eu.cleversoft.infonds3.session.helper.InfondsNtlmHttpFilter.negotiate(InfondsNtlmHttpFilter.java:152)
>     at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:121)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>     at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>     at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>     at
> org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>     at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>     at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at
> org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     at
> eu.cleversoft.infonds3.support.CharsetFilter.doFilter(CharsetFilter.java:32)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>     at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>     at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>     at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
>     at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>     at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>     at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>     at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>     at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>     at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
>     at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>     at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>     at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
>     at java.lang.Thread.run(Unknown Source)
> 17:42:00,429 ERROR [ExceptionFilter] exception root cause
>
> The line
> eu.cleversoft.infonds3.session.helper.InfondsNtlmHttpFilter.negotiate(InfondsNtlmHttpFilter.java:
> 152),
> from where supposedly the exception gets thrown, points to the
> SmbSession.logon( dc, ntlm ); call in my modified negotiate() method, which
> does nothing different than the original NtlmHttpFilter.negotiate(), but
> take jcifs.http.domainController from our local database and not from
> web.xml.
>
> I am running Windows Vista SP1. Are there any additional system settings,
> which one has to configure in order to get IE and Opera to work? What could
> be the cause for the filter to fail with those two browsers, but to function
> correctly with Firefox?
>
> Thank you very much in advance!
>
> Best regards,
> Ivan Stefanov
>
> Ivan Stefanov wrote:
>
> Hello all,
>
> Currently I am building a JBoss Seam application, which needs to implement
> Windows SSO and I have tried the approach proposed here. I have written an
> own FilterClass, which inherits the jcifs.http.NtlmHttpFilter class and most
> of its functionality, only modifying the init() and negotiate() methods so
> that the default_domain_controller and domain_name are pulled out from our
> database and not from the web.xml file. After some tweaking, it worked, but
> a very unexpected bug appeared.
>
> For the web front-end of out application I am extensively using richfaces
> components. After deploying the Ntlm filter, the rich:fileUpload component
> does not function anymore. I've tried to troubleshoot the problem and it
> appears that, although the POST carries the whole content of the file (PDF
> in our case), and the input HttpServletRequest parameter in
> NtlmHttpFilter.doFilter() contains, it seems, the correct information, no
> uploadEvent ever gets fired, since the upload listener method never gets
> called. When I turn off the filter (by removing its entry from web.xml and
> also the autoLogin method from components.xml), everything works fine.
>
> After some googling, it seems to me that this is an obscure, though
> relatively known issue, but apart from most people declaring that the
> NtlmFilter breaks the request and it appears empty, I have found no proposed
> adequte solution.
>
> As a part of my attempts to troubleshoot the problem, I have tried
> completely overriding the NtlmHttpFilter.doFilter method (that is, without a
> super.doFilter() call) in order to call my modified negotiate() method in
> the
> if ((ntlm = negotiate( req, resp, false )) == null) {
>             return;
> }
> statement, but then I found out that I can't call the NtlmHttpServletRequest
> constructor from the inheriting, as the NtlmHttpServletRequest class is not
> declared as public in the jCIFS package. Do the jCIFS developers propose any
> other approach to accessing this class, or is it deliberately designed not
> to be accessed by classes outside of the jcifs.http package?
>
> Any information on how I could better troubleshoot the problem with the
> broken file upload, or any workaround, or at least a suggestion how could I
> access the NtlmHttpServletRequest from my inheriting class, are very
> welcome!
>
> Thank you in advance!
>
> Ivan Stefanov
>
> --
> Mit freundlichen GrьЯen
> Ivan Stefanov
>
> Software Entwickler
> CleverSoft GmbH
>
> Personalisierte Factsheets mit FactsheetsLIVE(tm):
> Geben Sie Ihren Vertriebsmitarbeitern und Beratern die Mцglichkeit ein mit
> Ihren jeweiligen Kontaktdaten
> samt Logo und Foto personalisiertes Factsheet zu erstellen. Erfahren Sie
> mehr auf www.FactsheetsLIVE.de!
>
> www.clever-soft.com | Paul-Heyse-Str.6 | 80336 Mьnchen | Germany
> Tel. +49 89/99 16 91 17 | Mobil +49 172/77 43 714 | Fax +49 89/30 76 41-29
>
> Die CleverSoft ist ein Unternehmen der Clever Holding GmbH |
> www.clever-holding.de
>
> Bei Fragen zu unseren Produkten bitten wir Sie
> um eine E-Mail an: support at clever-soft.com
>
> ---
> CleverSoft GmbH | www.clever-soft.com
>  | Zasiusstr. 45 | 79102 Freiburg |
> Deutschland
> Sitz und Registergericht: Freiburg i.Br. | HRB 7358 | Geschдftsfьhrer:
> Florian Clever
> Steuernummer 06415/41889 | USt-IdNr. DE237074688
>
> Diese E-Mail kann vertrauliche und/oder geheime Informationen enthalten.
> Wenn Sie nicht der richtige Adressat sind und diese E-Mail irrtьmlich
> erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie
> diese E-Mail. Das unerlaubte Vervielfдltigen und die unbefugte Weitergabe
> dieser E-Mail sind nicht gestattet. Wir haben alle verkehrsьblichen
> MaЯnahmen unternommen, um das Risiko der Verbreitung virenbefallener
> Software oder E-Mails zu minimieren. Dennoch raten wir Ihnen, Ihre eigenen
> Virenkontrollen fьr alle Anhдnge an dieser Nachricht durchzufьhren. Sollten
> Sie die verschlьsselte Ьbermittlung von E-Mails wьnschen, so setzen Sie sich
> bitte mit uns in Verbindung.
>
>
>



-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/


More information about the jcifs mailing list