NTLM Auth ony works with Fiddler capturing

9 posts, 0 answers
  1. Ritch
    Ritch avatar
    1 posts
    Member since:
    Feb 2014

    Posted 11 Feb 2014 Link to this post

    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
  2. EricLaw
    EricLaw avatar
    67 posts
    Member since:
    Oct 2012

    Posted 12 Feb 2014 in reply to Ritch Link to this post

    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).
  3. Ritch
    Ritch avatar
    4 posts
    Member since:
    Feb 2014

    Posted 13 Feb 2014 in reply to EricLaw Link to this post

    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
  4. Ritch
    Ritch avatar
    4 posts
    Member since:
    Feb 2014

    Posted 13 Feb 2014 Link to this post

    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.
  5. EricLaw
    EricLaw avatar
    67 posts
    Member since:
    Oct 2012

    Posted 13 Feb 2014 in reply to Ritch Link to this post

    Can you email me the SAZ and PCAP files using the Help > Send Feedback link in Fiddler?
  6. EricLaw
    EricLaw avatar
    67 posts
    Member since:
    Oct 2012

    Posted 13 Feb 2014 in reply to EricLaw Link to this post

    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.
  7. Ritch
    Ritch avatar
    4 posts
    Member since:
    Feb 2014

    Posted 14 Feb 2014 Link to this post

    I have just sent you the captures.

    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.


    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)

    Typically, the server closes the connection at this time


    and under (3)

    From this point forward, the connection is kept open; closing the connection requires reauthentication of subsequent requests.


    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.
  8. EricLaw
    EricLaw avatar
    67 posts
    Member since:
    Oct 2012

    Posted 17 Feb 2014 in reply to Ritch Link to this post

    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.)

  9. Ritch
    Ritch avatar
    4 posts
    Member since:
    Feb 2014

    Posted 18 Feb 2014 in reply to EricLaw Link to this post

    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.


    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.


    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.)


    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.





     
Back to Top