This is a migrated thread and some comments may be shown as answers.

NTLM Auth ony works with Fiddler capturing

8 Answers 333 Views
Fiddler Classic
This is a migrated thread and some comments may be shown as answers.
Ritch
Top achievements
Rank 1
Ritch asked on 11 Feb 2014, 03:54 PM
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

8 Answers, 1 is accepted

Sort by
0
EricLaw
Top achievements
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).
0
Ritch
Top achievements
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
0
Ritch
Top achievements
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
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
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
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.
0
EricLaw
Top achievements
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.)

0
Ritch
Top achievements
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.





 
Tags
Fiddler Classic
Asked by
Ritch
Top achievements
Rank 1
Answers by
EricLaw
Top achievements
Rank 1
Ritch
Top achievements
Rank 1
Share this question
or