Mailing-List: contact httpclient-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of bcronin@mit.edu designates
 18.7.7.80 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <cb095b0329475e6325644117e579fb01@mit.edu>
References: <f48ad7ca6a5b86d4c7f672d75f2036c2@mit.edu>
 <02FD9154-BDCF-4DD7-A641-42171484B6AB@intencha.com>
 <cb095b0329475e6325644117e579fb01@mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <eea951f7c63764f0a815bf850cba471e@mit.edu>
Content-Transfer-Encoding: 7bit
From: Beau Cronin <bcronin@MIT.EDU>
Subject: Re: NTLM type 2 header issue
Date: Mon, 31 Jan 2005 22:05:16 -0500
To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>

I've found the following in the davenport NTLM documentation, which 
seems to be the relevant situation here:

---------
With Windows 2000, Microsoft introduced the "Negotiate" HTTP 
authentication mechanism. While primarily aimed at providing a means of 
authenticating the user against Active Directory via Kerberos, it is 
backward-compatible with the NTLM scheme. When the Negotiate mechanism 
is used in "legacy" mode, the headers passed between the client and 
server are identical, except "Negotiate" (rather than "NTLM") is 
indicated as the mechanism name.
---------

This behavior breaks NTLMScheme.processChallenge(), which does a simple 
comparison between the the scheme name ("ntlm") and the header of the 
message ("negotiate").  It seems that this needs to be changed in order 
to correctly handle this case.

It would be simple to hardcode this case (since, as the above excerpt 
states, all of the other message contents remains the same), and I can 
certainly do this and submit a patch.

The question is whether this is a bad idea, or would break anything.

Any input appreciated,

Beau Cronin

On Jan 30, 2005, at 9:01 PM, Beau Cronin wrote:

>> On 31/01/2005, at 5:02 AM, Beau Cronin wrote:
>>> As far as I can tell, all NTLM messages should have "NTLM" as the
>>> header.  Is anyone familiar with the source of this behavior?  Is 
>>> this
>>> within the NTLM "spec", or is there something weird going on here?
>>
>> As far as I know you're right.  NTLM servers generally respond with:
>>
>> WWW-Authenticate: Negotiate
>> WWW-Authenticate: NTLM
>>
>> (often there's a Kerberos in the middle)
>>
>> What is the server you're having trouble with?
>
> The server is just an internal IIS server we're using for testing for 
> this issue.  I'm not sure exactly how it's configured, 
> unfortunately--but as far as I know, it's a vanilla configuration.
>
> I'm a little surprised by this "Negotiate" header, since the NTLM 
> reverse-engineering documents I've seen don't mention it.  Is there 
> somewhere I can look which discusses it?
>
>> I would tend to think that it's reasonable to continue down the NTLM 
>> authentication path once we've started if we get a Negotiate header 
>> with no following NTLM header.  I'd like to know more about what 
>> Negotiate means though as I suspect it is an authentication scheme in 
>> itself or at least a scheme for negotiating the scheme to use.  I 
>> don't recall seeing the Negotiate scheme in any standards or 
>> documentation I've read though.
>
> I interpret this to mean you think this is a legitimate NTLM response 
> then?  In that case, I suppose this requires a modification to the 
> http-client NTLMScheme code to appropriately handle it.  Is that a 
> reasonable supposition?  If so, maybe I can take a look at what's 
> involved.  I'm rather new to this area, though, so I wanted to check 
> with the experts here before making any assumptions about where any 
> changes need to be made.
>
> Any further input greatly appreciated,
>
> Beau Cronin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org