Hi,
I have a bit of conundrum. We have a webapp wich has built-in NTLM support. However this only works with Fiddler running in capture mode. If Fiddler is not running, the NTLM type 1 message that's supposed to be sent back to the server, by Internet Explorer, for some reason never gets sent.
To clarify, from http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication
=============================================================================================================
3. The client resubmits the request with an "Authorization" header containing a Type 1 message parameter.
=============================================================================================================
(3) never happens, unless fiddler is running in capture mode, then the ntlm handshake works like a charm.
Anyone knows what's going here?
cheers,Ritch
I have a bit of conundrum. We have a webapp wich has built-in NTLM support. However this only works with Fiddler running in capture mode. If Fiddler is not running, the NTLM type 1 message that's supposed to be sent back to the server, by Internet Explorer, for some reason never gets sent.
To clarify, from http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication
=============================================================================================================
3. The client resubmits the request with an "Authorization" header containing a Type 1 message parameter.
=============================================================================================================
(3) never happens, unless fiddler is running in capture mode, then the ntlm handshake works like a charm.
Anyone knows what's going here?
cheers,Ritch
8 Answers, 1 is accepted
0
EricLaw
Top achievements
Rank 1
Rank 1
answered on 12 Feb 2014, 04:37 PM
Do you have a NetMon or Wireshark capture of the scenario when Fiddler isn't involved? Are you sure that it's not trying to perform a Kerberos handshake (http://blogs.msdn.com/b/ieinternals/archive/2011/07/06/integrated-windows-authentication-kerberos-ntlm-http-400-error-for-16kb-authorization-header.aspx) in that scenario?
Are you using Internet Explorer as the client app? If so, what security zone is the page running in (right-click the page and choose Properties).
Are you using Internet Explorer as the client app? If so, what security zone is the page running in (right-click the page and choose Properties).
0
Ritch
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2014, 09:58 AM
Hi, thx for replying.
We use IE 10, no (reverse) proxies are used. I've used both wireshark and IE10's built-in network inspector, without fiddler running I only see the first 401 (ntlmssp_challenge) from the server, but the client doesn't respond. The server is in the Intranet zone.
Allthough I don't see any kerberos traffic, I've also tried disabling Integrated Windows Auth. in IE, including a reboot.
Some other stuff, based on the "clutching at straws" approach, I've also tried (all under HKCU):
-Set DisableNTLMPreAuth to 1
-Set KeepaliveTimeout & ServerInfoTimeout to 3 mins
-Different variations of adding the server to the intranet zone (originally the entire domain was included, but I've also tried just adding the fqdn of this particular server)
-Disabled Use http 1.1 through proxy connections
nothing works, unless with Fiddler running in capture mode, and this only works if over http. If I try fiddler with https it doesn't work either.
I suppose the answer might lie somewhere in: http://blogs.telerik.com/fiddler/posts/13-02-28/help!-running-fiddler-fixes-my-app-
but I can't really see where :)
attached are a couple of edited screens of wireshark captures:
withfiddler.png => ntlm ok
without-fiddler.png => first 401 ntlmssp_challenge and then zilch
withoutfiddler01.png => zooms in on the ntlmssp_negotiate
withoutfiddler02.png => zooms in on the ntlmssp_challenge
right up to the point before the ntlmssp_auth response is sent I can't really see any differences between both captures.
cheers,
Ritch
We use IE 10, no (reverse) proxies are used. I've used both wireshark and IE10's built-in network inspector, without fiddler running I only see the first 401 (ntlmssp_challenge) from the server, but the client doesn't respond. The server is in the Intranet zone.
Allthough I don't see any kerberos traffic, I've also tried disabling Integrated Windows Auth. in IE, including a reboot.
Some other stuff, based on the "clutching at straws" approach, I've also tried (all under HKCU):
-Set DisableNTLMPreAuth to 1
-Set KeepaliveTimeout & ServerInfoTimeout to 3 mins
-Different variations of adding the server to the intranet zone (originally the entire domain was included, but I've also tried just adding the fqdn of this particular server)
-Disabled Use http 1.1 through proxy connections
nothing works, unless with Fiddler running in capture mode, and this only works if over http. If I try fiddler with https it doesn't work either.
I suppose the answer might lie somewhere in: http://blogs.telerik.com/fiddler/posts/13-02-28/help!-running-fiddler-fixes-my-app-
but I can't really see where :)
attached are a couple of edited screens of wireshark captures:
withfiddler.png => ntlm ok
without-fiddler.png => first 401 ntlmssp_challenge and then zilch
withoutfiddler01.png => zooms in on the ntlmssp_negotiate
withoutfiddler02.png => zooms in on the ntlmssp_challenge
right up to the point before the ntlmssp_auth response is sent I can't really see any differences between both captures.
cheers,
Ritch
0
Ritch
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2014, 01:26 PM
I've just tried it with firefox (network.automatic-ntlm-auth.trusted-uris) and offcourse this works immediately. Oddly enough ony IE10 doesn't work.
0
EricLaw
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2014, 09:21 PM
Can you email me the SAZ and PCAP files using the Help > Send Feedback link in Fiddler?
0
EricLaw
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2014, 09:25 PM
Incidentally, your 401 response with the challenge appears to have a [Connection: close] header; since NTLM is a connection-oriented protocol, I wouldn't expect this to work.
0
Ritch
Top achievements
Rank 1
Rank 1
answered on 14 Feb 2014, 09:29 AM
I have just sent you the captures.
[quote]Incidentally, your 401 response with the challenge appears to have a [Connection: close] header; since NTLM is a connection-oriented protocol, I wouldn't expect this to work.[/quote]
I'm not sure if this information is correct, but according to the Eric Glass whitepaper:(http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication)
Under (2)
[quote]Typically, the server closes the connection at this time[/quote]
and under (3)
[quote]From this point forward, the connection is kept open; closing the connection requires reauthentication of subsequent requests.[/quote]
I couldn't find anything about this in the MS-NTHT specs (http://msdn.microsoft.com/en-us/library/cc237488.aspx)
when I check the firefox wireshark captures I see the same behaviour in the first 401, but also in the second 401 (again connection close.
[quote]Incidentally, your 401 response with the challenge appears to have a [Connection: close] header; since NTLM is a connection-oriented protocol, I wouldn't expect this to work.[/quote]
I'm not sure if this information is correct, but according to the Eric Glass whitepaper:(http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication)
Under (2)
[quote]Typically, the server closes the connection at this time[/quote]
and under (3)
[quote]From this point forward, the connection is kept open; closing the connection requires reauthentication of subsequent requests.[/quote]
I couldn't find anything about this in the MS-NTHT specs (http://msdn.microsoft.com/en-us/library/cc237488.aspx)
when I check the firefox wireshark captures I see the same behaviour in the first 401, but also in the second 401 (again connection close.
0
EricLaw
Top achievements
Rank 1
Rank 1
answered on 17 Feb 2014, 11:54 PM
The "Firefox-ntlm.pcap" file you've sent contains only traffic with an IE10/Trident6 UA string. There's no mention of Gecko anywhere.
The captures you've sent me show that IE is, in fact, responding to the initial WWW-Authenticate: NTLM message with a Type-1 request message (use the Auth request and response Inspectors in Fiddler to see this). The server then returns a Type-2 response message (TCP/IP FIN) and closes the connection before the client can send the Type-3 request message that completes the NTLM handshake and authorizes the connection.
I'm 95% sure that the problem here is that the server is closing the connection after returning the Type2 NTLM Challenge message. NTLM requires keep-alive connections to function properly; closing the Connection isn't compatible with that. (This is consistent with the http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication documentation that you mentioned; the connection is expected to be reused after the server's Type2 challenge.)
The captures you've sent me show that IE is, in fact, responding to the initial WWW-Authenticate: NTLM message with a Type-1 request message (use the Auth request and response Inspectors in Fiddler to see this). The server then returns a Type-2 response message (TCP/IP FIN) and closes the connection before the client can send the Type-3 request message that completes the NTLM handshake and authorizes the connection.
I'm 95% sure that the problem here is that the server is closing the connection after returning the Type2 NTLM Challenge message. NTLM requires keep-alive connections to function properly; closing the Connection isn't compatible with that. (This is consistent with the http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication documentation that you mentioned; the connection is expected to be reused after the server's Type2 challenge.)
0
Ritch
Top achievements
Rank 1
Rank 1
answered on 18 Feb 2014, 02:55 PM
[quote]EricLaw said:The "Firefox-ntlm.pcap" file you've sent contains only traffic with an IE10/Trident6 UA string. There's no mention of Gecko anywhere.
[/quote]
the webapp does a check for the useragent, so for troubleshooting pruposes I made Firefox pretend it was IE10, but the dump is actual Firefox traffic. Sorry for the confusion.
[quote]
The captures you've sent me show that IE is, in fact, responding to the initial WWW-Authenticate: NTLM message with a Type-1 request message (use the Auth request and response Inspectors in Fiddler to see this). The server then returns a Type-2 response message (TCP/IP FIN) and closes the connection before the client can send the Type-3 request message that completes the NTLM handshake and authorizes the connection.
I'm 95% sure that the problem here is that the server is closing the connection after returning the Type2 NTLM Challenge message. NTLM requires keep-alive connections to function properly; closing the Connection isn't compatible with that. (This is consistent with the http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication documentation that you mentioned; the connection is expected to be reused after the server's Type2 challenge.)
[/quote]
Make that 100%!!!
Turns out that the webapp uses an apache reverse proxy, on the same server, which was misconfigured by our supplier:
http://blogs.msdn.com/b/ieinternals/archive/2011/03/26/https-and-connection-close-is-your-apache-modssl-server-configuration-set-to-slow.aspx?Redirected=true
after commenting out the erroneous entries, ntlm is working as it should
Thanks a lot, your help is really appreciated.
The least I can do is buy your book, but if you have a tip jar I'll gladly donate you some bucks.
[/quote]
the webapp does a check for the useragent, so for troubleshooting pruposes I made Firefox pretend it was IE10, but the dump is actual Firefox traffic. Sorry for the confusion.
[quote]
The captures you've sent me show that IE is, in fact, responding to the initial WWW-Authenticate: NTLM message with a Type-1 request message (use the Auth request and response Inspectors in Fiddler to see this). The server then returns a Type-2 response message (TCP/IP FIN) and closes the connection before the client can send the Type-3 request message that completes the NTLM handshake and authorizes the connection.
I'm 95% sure that the problem here is that the server is closing the connection after returning the Type2 NTLM Challenge message. NTLM requires keep-alive connections to function properly; closing the Connection isn't compatible with that. (This is consistent with the http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication documentation that you mentioned; the connection is expected to be reused after the server's Type2 challenge.)
[/quote]
Make that 100%!!!
Turns out that the webapp uses an apache reverse proxy, on the same server, which was misconfigured by our supplier:
http://blogs.msdn.com/b/ieinternals/archive/2011/03/26/https-and-connection-close-is-your-apache-modssl-server-configuration-set-to-slow.aspx?Redirected=true
after commenting out the erroneous entries, ntlm is working as it should
Thanks a lot, your help is really appreciated.
The least I can do is buy your book, but if you have a tip jar I'll gladly donate you some bucks.