SOLVED! RE: [jcifs] Please Help Me!

[Aris Javier]

I found it!

Thanks to Akash Kava.. 

to get User: request.getHeader("IIS-REMOTE-USER");
to get Host: request.getHeader("IIS-REMOTE-ADDR");

if you're using Tomcat+IIS thru jspisapi filter.. 
it make use of NTLM authentication...

no need to change server.xml or web.xml or jk2.properties...

Thanks Akash!!!

Also watch out for JWEBEX (JWX)... it will replace JSP...
It has features of .NET!
Fast coding, auto login, auto integration with IIS, it will replace jsp,

it can be used with existing tomcat without any new changes

yes! go JAVA!

-----Original Message-----
From: Eric Glass [mailto:eric.glass at gmail.com] 
Sent: Wednesday, September 01, 2004 8:07 PM
To: Aris Javier
Cc: Michael B Allen; jcifs at lists.samba.org
Subject: Re: [jcifs] Please Help Me!


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(SmbComSessio
> > > nS
> > > 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.
> >
>