[jcifs] No response to NTLM challenge

[Eric Glass]

What does the server-side environment look like (container, web
server, etc.)?  This would appear to be a client issue (in that it's
dropping the handshake inexplicably), but is likely caused by a
configuration issue.  Is the filter running under an external web
server (i.e., apache with mod_jk rather than via the container's own
web server)?  One thing to check is whether the web server is closing
the HTTP connection when it sends the Type 2 back to the client; it
should be set up for persistent connections (keep-alive).

Your web.xml looks fine; if you have a packet trace between the client
and the web server, you can send it to me directly and I'll take a
look.


Eric


----- Original Message -----
From: steven.durkin at scotland.gsi.gov.uk <steven.durkin at scotland.gsi.gov.uk>
Date: Mon, 26 Jul 2004 13:51:32 +0100
Subject: [jcifs] No response to NTLM challenge
To: jcifs at lists.samba.org

*******************************************************************************************************************************************************
This email and any files transmitted with it are intended solely for
the use of the individual or entity to whom they are addressed.
*******************************************************************************************************************************************************



Hello all,

I am trying to fix a problem that has occurred with NTLM
authentication on one of our Intranet systems, and I need help!

The authentication is failing on every attempt. Looking at the
exchanges between the client and the server, the first thing that
leaps out is that the Client never responds correctly to the server
challenge - I am always seeing the following pattern:

C --> S   GET ... 

C <-- S   401 WWW-Authenticate: NTLM...

C --> S   GET ... NTLM NEGOTIATE (Type 1)

C <-- S   401 WWW-Authenticate: NTLM CHALLENGE (Type 2)

C --> S   GET ... 

C <-- S   401 WWW-Authenticate: NTLM

The last GET from the client is the same as the first - in other
words, no Type 3 response to the server's challenge is ever sent.

The browser was upgraded to IE 6 at the time of the failure, but we
have another system on out intranet that uses an M$ IIS server with 
NTLM authentication that works fine: so I have upgraded the JCIFS
classes and concentrated my efforts on the server-side settings. For
info, here is the filter description from my web.xml.

    <filter> 

        <filter-name>NtlmHttpFilter</filter-name> 

        <filter-class>jcifs.http.NtlmHttpFilter</filter-class> 

        <!-- For production use a real domain controller --> 

        <init-param>

            <param-name>jcifs.smb.client.domain</param-name>

            <param-value>SCOTLAND</param-value>

        </init-param>

        <init-param>

            <param-name>jcifs.http.domainController</param-name> 

            <param-value>10.10.132.98</param-value> 

        </init-param>

        <init-param>

            <param-name>jcifs.smb.lmCompatibility</param-name>

            <param-value>2</param-value>

        </init-param>

    </filter> 

 

    <filter-mapping> 

        <filter-name>NtlmHttpFilter</filter-name> 

        <url-pattern>/*</url-pattern> 

    </filter-mapping> 

I have tried different settings to no avail: for example setting
jcifs.netbios.wins instead of http.domainController; or using my PC as
the domainController. But I have not seen a change either in the
pattern of the exchanged messages, or even in the content.

I would really appreciate any help on what could be causing this! If I
am writing to the wrong list then any suggestions on other sources of
help would also be much appreciated.

Thanks in advance,

Steve D
The original of this email was scanned for viruses by the Government
Secure Intranet (GSi) virus scanning service supplied exclusively by
Energis in partnership with MessageLabs.

On leaving the GSi this email was certified virus-free