You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Beau Cronin <bc...@MIT.EDU> on 2005/01/30 20:02:38 UTC
NTLM type 2 header issue
I am trying to integrate NTLM authentication into the Heritrix web
crawler (using the httpclient-beta1 codebase). My problem is that the
type 2 message from the NTLM server I am testing against seems to
return a scheme name (i.e., the header of the type 2 message) of
"Negotiate", rather than "NTLM", which is what
NTLMScheme.processChallenge() is expecting. The result is that
processChallenge throws a MalformedChallengeException.
That is, AuthChallengeParser.extractScheme(challenge) returns
"Negotiate" on the type 2 message. It properly returns "NTLM" when run
on the first challenge.
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?
Thanks for your time,
Beau Cronin
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: NTLM type 2 header issue
Posted by Michael Becke <be...@u.washington.edu>.
Sounds like the right thing to do.
Mike
On Jan 31, 2005, at 11:19 PM, Adrian Sutton wrote:
> Hi Beau,
>
>> 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.
>
> I can't see any issue with hard coding Negotiate as a synonym for NTLM
> - after all, NTLM itself is just hard coded. If you could supply a
> patch to do this it would be fantastic.
>
> Anyone else see a problem?
>
> Regards,
>
> Adrian Sutton
>
> ---------------------------------------------------------------------
> 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
Re: NTLM type 2 header issue
Posted by Adrian Sutton <ad...@intencha.com>.
Hi Beau,
> 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.
I can't see any issue with hard coding Negotiate as a synonym for NTLM
- after all, NTLM itself is just hard coded. If you could supply a
patch to do this it would be fantastic.
Anyone else see a problem?
Regards,
Adrian Sutton
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: NTLM type 2 header issue
Posted by Beau Cronin <bc...@MIT.EDU>.
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
Re: NTLM type 2 header issue
Posted by Beau Cronin <bc...@MIT.EDU>.
> 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
Re: NTLM type 2 header issue
Posted by Adrian Sutton <ad...@intencha.com>.
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?
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.
> Thanks for your time,
>
> Beau Cronin
Regards,
Adrian Sutton.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org