FW: [jcifs] 0.7.11 ISAPI redirector problem

[eglass1 at comcast.net]

> I downloaded ethereal and was going to get a packet trace going except it 
> looks like you can't packet trace anything loaded as localhost on a Windows 
> machine.
> ie. With Tomcat and IIS loaded on the PC you cannot packet trace what is
> going on between them. (any ideas anyone? :-)
> 

Attached is a little utility you can use to dump all the HTTP traffic.  You
would run:

java Trace nnnn localhost 8080 log

And point your browser at port "nnnn" instead of port 8080.  This will just
act as a man-in-the-middle, and log each connection to log1.txt, log2.txt, etc.
Zip the log*.txt files up and send them to me directly (as the NTLM responses
can contain potentially sensitive information) and I will take a look.

My guess is that IIS is still intercepting the NTLM tokens and performing
local authentication; looking at the tokens (as described above) would give
an indication, as IIS's flags are different from the ones we use.  I would
think that you would receive an error when the jCIFS filter finally receives
the Type 3 message (since it will attempt to authenticate the client using the
username and LM/NTLM responses, which would be completely empty under local
authentication); it may be successfully authenticating as "guest".

You should be able to use IIS to do the NTLM authentication natively, without
jCIFS; you would basically do the following:

1.  Open the properties for the "jakarta" virtual directory.
2.  On the Access Control portion of the "Directory Security" tab, clear out
"Anonymous Access" and select "Integrated Windows Authentication".
3.  Remove the NtlmHttpFilter from the web.xml deployment descriptor.

You will probably also have to set tomcatAuthentication to false (I
touched on this previously, but for the benefit of those just joining us):

If you are using the AJP14 connector, you would edit server.xml:

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

The important part is the "tomcatAuthentication" attribute, which tells
tomcat to use the authentication provided by the web server (otherwise, the
request object won't be populated with the remote user from IIS).  If you are
using the Coyote JK2 connector, the equivalent setting would be added to the
jk2.properties file:

    request.tomcatAuthentication="false"

You will probably have to restart both Tomcat and IIS.  At this point, IIS
should enforce NTLM authentication before forwarding the request to your
web application; the authenticated username is available via
request.getRemoteUser(), just like with jCIFS.  If you only need authentication,
this should suffice.  If you need to access SmbFiles on the web server
(i.e., you need an NtlmPasswordAuthentication object like the filter provides),
you can use the attached filter to extract this from the Type 3 message.
You would only be able to use this object when accessing SMB resources on the
web server, but this is true of the NtlmHttpFilter as well (accessing
resources on other servers involves reauthentication trickery ala
Davenport/NetworkExplorer).  Also, this won't work properly if local
authentication has been negotiated (since the domain/username and LM/NTLM
responses are all empty in the Type 3 message).


Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 3357 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20030730/d2d18ea5/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 3689 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20030730/d2d18ea5/attachment-0001.obj