[jcifs] Please Help Me!

[Eric Glass]

Inside your filter declaration, just add:

<init-param>
    <param-name>jcifs.smb.lmCompatibility</param-name>
    <param-value>3</param-value>
</init-param>

This should work fine.  If you want HTTP basic to be offered as well
as NTLM (to support browsers which don't work with NTLM), you would
also add:

<init-param>
    <param-name>jcifs.http.insecureBasic</param-name>
    <param-value>true</param-value>
</init-param>

So from your previous post, the full setup would be like:

 <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>EAZIX</param-value>
     </init-param>
     <init-param>
         <param-name>jcifs.netbios.wins</param-name>
         <param-value>192.168.63.1</param-value>
     </init-param>
     <init-param>
         <param-name>jcifs.smb.lmCompatibility</param-name>
         <param-value>3</param-value>
     </init-param>
     <init-param>
         <param-name>jcifs.http.insecureBasic</param-name>
         <param-value>true</param-value>
     </init-param>
 </filter>
 <filter-mapping>
     <filter-name>NtlmHttpFilter</filter-name>
     <url-pattern>/*</url-pattern>
 </filter-mapping>


jCIFS should work properly in *all* NTLMv2 scenarios with
lmCompatibility set; the previous patch would just get rid of this
particular error when someone has their clients set up for NTLMv2 but
jCIFS has lmCompatibility < 3.


Eric


On Wed, 1 Sep 2004 14:15:03 +0800, Aris Javier
<aristotle.javier at eazix.com> wrote:
> im sorry.
> i don't understand your reply. im new to authentication stuff.
> all i want is to get request.getRemoteUser() to work...
> 
> do you know any working code, even basic authentication just for
> request.getRemoteUser() to work?
> 
> please help! i got sick yesterday because of this.. really no kidding!
> 
> 
> 
> 
> -----Original Message-----
> From: Eric Glass [mailto:eric.glass at gmail.com]
> Sent: Tuesday, August 31, 2004 6:40 PM
> To: Michael B Allen
> Cc: Aris Javier; jcifs at lists.samba.org
> Subject: Re: [jcifs] Please Help Me!
> 
> This would occur if the client is set up for NTLMv2, but
> jcifs.smb.client.lmCompatibility isn't set correspondingly.  The fix is
> ~line 61 of SmbComSessionSetupAndX; currently it does:
> 
> accountPassword = auth.getAnsiHash(
> session.transport.server.encryptionKey ); unicodePassword =
> auth.getUnicodeHash( session.transport.server.encryptionKey );
> passwordLength = unicodePasswordLength = 24; // fix for win9x clients if
> (unicodePassword.length == 0) unicodePasswordLength = 0;
> 
> This should really just be:
> 
> accountPassword = auth.getAnsiHash(
> session.transport.server.encryptionKey ); passwordLength =
> accountPassword.length; unicodePassword = auth.getUnicodeHash(
> session.transport.server.encryptionKey ); unicodePasswordLength =
> unicodePassword.length; // prohibit HTTP auth attempts for the null
> session if (unicodePasswordLength == 0 && passwordLength == 0) {
>    throw new RuntimeException("Null setup prohibited.");
> }
> 
> i.e. the lengths should actually be the lengths of the fields (rather
> than hardcoded to 24).
> 
> This actually allows full NTLMv2 to work, provided the HTTP server and
> SMB server are the same machine (otherwise the host name won't match the
> target list).  You don't even have to set
> jcifs.smb.client.lmCompatibility in this particular case, as it will
> copy the NTLMv2 response directly into the session setup message.
> 
> Eric
> 
> On Tue, 31 Aug 2004 04:18:23 -0400, Michael B Allen <mba2000 at ioplex.com>
> wrote:
> > On Tue, 31 Aug 2004 15:36:27 +0800
> > "Aris Javier" <aristotle.javier at eazix.com> wrote:
> >
> > >      <filter-name>NtlmHttpFilter</filter-name>
> > >      <url-pattern>/*</url-pattern>
> > >  </filter-mapping>
> > >
> > >
> > > but this error occured;
> > >
> > > java.lang.ArrayIndexOutOfBoundsException
> > > java.lang.System.arraycopy(Native Method)
> > > jcifs.smb.SmbComSessionSetupAndX.writeBytesWireFormat(SmbComSessionS
> > > etup
> > > AndX.java:118)
> >
> > Whooops. That's not supposed to happen. That code is:
> >
> > 116   if( session.transport.server.security == SECURITY_USER &&
> > 117       ( auth.hashesExternal || auth.password.length() > 0 )) {
> > 118    System.arraycopy( accountPassword, 0, dst, dstIndex,
> passwordLength
> > );
> > 119    dstIndex += passwordLength;
> >
> > Since this is the first time we're seing this I have to wonder what it
> 
> > is about your setup that's different. What web broswer are you using?
> > Is there anything special about the server config? What is the host
> > OS? I'm thinking perhaps the client or server outside of jCIFS
> > jurisdiction is modifying the password hashes such that they are not
> > what the above code expects.
> >
> > Mike
> >
> > --
> > Greedo shoots first? Not in my Star Wars.
> >
>