[jcifs] 0.7.3 -- ArrayIndexOutOfBoundsException with tomcat 4 .1.18 via is api_redirect.dll

[eglass1 at comcast.net]

> The problem is I the following when I access Tomcat directly:
> 
> NTLM HTTP Authentication Example
> DOMAIN\TC00H successfully logged in <===== All OK here. Logged on OK.
> Please submit some form data using POST
>   
> field1 = null 
> 
> but when I access it via the ISAPI redirector DLL I get the following:
> 
> NTLM HTTP Authentication Example
> successfully logged in <===== Errr... someone has logged in but I don't see who.
> Please submit some form data using POST
>   
> field1 = null 
> 

If you're only seeing the problem under the connector, it's probably not the
web.xml.  I'm currently between working IIS-Tomcat connectors right now (I'm
having non-jCIFS-related issues), but try looking at the following:

1)  Ensure that anonymous access is allowed from the IIS side to the Tomcat
connector, and NTLM ("Integrated Windows authentication") is disabled.

Under access control on the directory security tab for the tomcat virtual
directory, make sure "Anonymous access" is enabled and "Integrated Windows
authentication" is disabled.  Otherwise, strange interactions can take place
between the filter and IIS.  Are you accessing the server from the local box
(i.e., client and server are the same box)?  This could possibly explain the
behavior; if IIS is "intercepting" the NTLM messages, it will negotiate local
authentication with a client on the same box.  The Type 3 message in such a
case will contain zero-length fields for the username, domain, etc. which
could explain the empty username string you are seeing (incidentally, this
would also cause the aforementioned error; even with a zero-length password,
the LM hash should be 24 bytes in a normal scenario).


2)  Make sure the filter is getting invoked.

Attached is a test jsp file which you should be able to drop in to your web
app.  This will give you a few indications as to whether the filter is even
getting tapped during the request.


3)  Try playing with the "tomcatAuthentication" parameter.

This controls whether the webserver or Tomcat is authenticating users.  If you
are using the AJP13 connector, you would do this in server.xml, something like:

<Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
        tomcatAuthentication="false" port="8009" minProcessors="5"
        maxProcessors="75" acceptCount="10" debug="0"/>

The "tomcatAuthentication" is the relevant bit here.  If you are using the
Coyote JK2 connector, you would edit jk2.properties and add:

request.tomcatAuthentication="false"

This is kind of a long shot though; I think this will cause tomcat to use the
webserver's authentication, which is sort of the opposite of what you are
going for.  This would normally be an option -- enabling "Integrated Windows
authentication", disabling "Anonymous access", and removing the filter
completely.  This would use IIS to do the NTLM authentication instead of
jCIFS.  However, you indicated previously that you are looking to move away
from IIS, so this probably wouldn't be applicable in your case.  Of course,
you could just use jCIFS on your non-IIS boxes, and use the native NTLM
authentication provided by IIS on those servers.  The only modification needed
for your web apps is to slip the filter into the web.xml.  You probably won't
see any of these issues on non-IIS servers.

If all of this fails, a packet trace would probably be needed for some deeper
digging.


Eric

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 531 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20030728/efca276d/attachment.obj