locked
[MS-NLMP / MS-NTHT] Determining NTLM v1 or v2 in HTTP authentication RRS feed

  • Question

  • Hi,

    This is a bit of a newbie question - hopefully easy to answer :-)

    The scenario is a web server and web client, communicating over HTTP.

    The web server running IIS (on W2K8 R2), configured to only accept NTLMv2. That, the local security policy is configured as "Network security: LAN Manager authentication level" is "Send NTLMv2 response only. Refuse LM & NTLM".

    The client might or might not be joined to the domain. Assume that is isn't for now.

    How does the client (web browser) know to choose between the NTLM version 1 and NTLM version 2 forms of the AUTHENTICATE_MESSAGE? I've scanned through MS-NLMP and MS-NTHT, but I don't see this explained. I do see how to provide the right response, just not how to decide between them.

    I've looked at the transfer using wireshark, and IE doesn't appear to try both, so I'm sure there is some way to tell. I'm just not sure what it is.

    Brad

    Tuesday, April 20, 2010 12:07 AM

Answers

  • Hello Brad - thank you for the network captures. To recap, here is your question:

    In the absence of some general configuration, how does a Windows client know whether to send an NTLM v1 or NTLM v2 response to a server that returns a 401 Unauthorized, containing:

    WWW-Authenticate: Negotiate

    WWW-Authenticate: NTLM

    That is, does it always try NTLM v2 first? Or does it use some heuristic based on the identity of the web server? Or something else?

    To answer to your question with respect to NTLM authorization across HTTP - as constrained by LmCompatibilityLevel (Windows 7 default = 3), a Windows client will select Negotiate/NTLM (a.k.a. extended session security) if offered, NTLM (Signature: "NTLMSSP") if not, and will in either case offer NTLM v2 on the first and only try.

    The general case is that Windows – like any well behaved operating system – will negotiate the authentication method starting with the most robust, and go ‘down’ from there, according to the available security provider package as constrained by system policy.

    The Windows server is set to LmCompatibilityLevel 5: Refuse NTLM and LM authentication, and accept only NTLM v2 authentication. The Linux clients are behaving in a fashion similar to LmCompatibilityLevel 0: Use LM and NTLM authentication, and never use extended session security. In this case, everything is working as designed; the server MUST reject the authentication attempt.

    It might be worth checking smb.conf for [global] client ntlmv2 auth = Yes 

    /etc/samba/smb.conf:

    ...

    [global]

    ...

    client ntlmv2 auth = Yes

    ...

    For the sake of completeness, here are the client and server configurations (with several educated guesses):

    1.       Web Server

    ·         IIS 7 on Windows 2008 R2 (v6.1.7600)

    ·         Offers both Negotiate and NTLM authentication.

    o   WWWAuthenticate: Negotiate

    o   WWWAuthenticate: NTLM

    ·         LmCompatibilityLevel 5: DCs refuse LM and NTLM responses, and accept only NTLM v2. Clients use NTLM v2 authentication and use extended session security if the server supports it.

    2.       Mozilla client (mozilla.pcap)

    ·         Firefox 3.5.9 on Linux v1.9.1.9

    ·         Client response is authentication using NTLM v1. Like LmCompatibilityLevel 0: Use LM and NTLM authentication, and never use extended session security.

    ·         http://www.useragent.org has no listing for the UserAgent string.

    3.       Demo Qt client (originalqtbrowser.pcap)

    ·         demobrowser 0.1 on Linux v? (Safari /532.4)

    ·         Client response is authentication using NTLM v1. Like LmCompatibilityLevel 0: Use LM and NTLM authentication, and never use extended session security.

    ·         http://www.useragent.org has no listing for the UserAgent string.

    4.       Windows client (ntlmv2fromIE.pcap)

    ·         Internet Explorer 8 on Windows 7 (v6.1)

    ·         Client response is authentication GSS-API/NTLMv2.

    ·         LmCompatibilityLevel (probably) 3 (Windows 7 default if not configured in the registry): Clients use NTLM v2 authentication and use extended session security if the server supports it.

    By the way, this is illustrative of how to remotely determine the NTLM security policy on a given Windows instance - without recourse to remote registry (which would, of course require successful authentication), or knowingly being a target for the same security policy (whether domain or machine local).

    Windows clients will try the most robust authentication method first (e.g. first in the SPNEGO offering, or most secure per policy), per the security settings (LmCompatibilityLevel, NtlmMinServerSec, NtlmMinClientSec and so on) as documented at the following links:

    ·         [MS-NLMP] 2.2 Message Syntax http://msdn.microsoft.com/en-us/library/cc236639(v=PROT.13).aspx

    ·         [MS-NLMP] Appendix B: Product Behavior <66> (NTLM Security Considerations) http://msdn.microsoft.com/en-us/library/a211d894-21bc-4b8b-86ba-b83d0c167b00(v=PROT.13)#id66

    ·         Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments http://support.microsoft.com/kb/823659

    10.   Network security: Lan Manager authentication level

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\"LmCompatibilityLevel"   

    15.   NTLMv2 authentication

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"

    ·         For more information, search for 'LmCompatibilityLevel' here:

    Help and Support (Microsoft Knowledge Base search) http://support.microsoft.com/search/

     

    • Proposed as answer by Bill Wesse Thursday, April 29, 2010 1:13 PM
    • Marked as answer by Brad Hards Saturday, May 1, 2010 4:50 AM
    Thursday, April 29, 2010 1:13 PM
  • Glad to help, Brad! kb823659 just keeps on popping up for me lately (which pleases me, I had several of my hands in the evolution of the text...).

    Bill Wesse

     

    • Marked as answer by Bill Wesse Monday, May 3, 2010 9:23 AM
    Monday, May 3, 2010 9:23 AM
  • I found the root cause of the issue. The root cause was that the server and domain had NoLMHashPolicy configured. This meant that windows would not store the LM hash value of the password. Since the NTLM protocol implementation we computed only the LM hash value and the NT Hash, the authentication failed. 

    The fix involves modifying the protocol implementation to compute the NT Response Hash before sending the Type3 message to the server.

    Thanks for the help.


    Technet Forum Issue
    Wednesday, August 31, 2011 2:02 PM

All replies

  • Brad,

    Thank you for your question. One of my colleagues will take ownership of this question and will be in touch with you soon.

    Regards,

    Edgar

    Tuesday, April 20, 2010 3:20 PM
  • Hi Brad,

     

    I'll be helping you with this issue.

    I'll keep you posted of the progress I make.

     

    Thanks and regards,

     


    SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team
    Tuesday, April 20, 2010 6:00 PM
  •  

    Hi Brad,

     

    You can find the detailed information about your question in the MS-NLMP document.

     

    Section 5.1 has a Windows Behavior Note (#66 in the online version of the doc) that explains the way the client and server are to be configured in order to specify what version of the NTLM protocol to use.

     

    This is the text for that WBN:

     

    <66> Section 5.1: NTLM domain considerations are as follows:

    Microsoft DCs determine the minimum security requirements for NTLM authentication between a Windows client and the local Windows domain. Based on the minimum security settings in place, the DC can either allow or refuse the use of LM, NTLM, or NTLM v2 authentication, and servers can force the use of extended session security on all messages between the client and server. In a Windows domain, the DC controls domain level security settings through the use of Windows Group Policy, which replicates security policies to clients and servers throughout the local domain.

    Domain-level security policies dictated by Windows Group Policy must be supported on the local system for authentication to take place. During NTLM authentication, clients and servers exchange NTLM capability flags that specify what levels of security they are able to support. If either the client or server's level of security support is less than the security policies of the domain, the authentication attempt is refused by the computer with the higher level of minimum security requirements. This is important for interdomain authentication where differing security policies may be enforced on either domain, and the client or server may not be able to support the security policies of the other's domain.

    NTLM security levels are as follows:

    The security policies exchanged by the server and client can be set independently of the DC minimum security requirements dictated by Windows Group Policy. Higher local security policies can be exchanged by a client and server in a domain with low minimum security requirements in connection-oriented authentication during the capability flags exchange. However, during connectionless (datagram-oriented) authentication, it is not possible to exchange higher local security policies because they are strictly enforced by Windows Group Policy. Local security policies that are set independently of the DC are subordinate to domain-level security policies for clients authenticating to a server on the local domain; therefore, it is not possible to use local-system policies that are less secure than domain-level policies.

    Stand-alone servers that do not have a DC to authenticate clients set their own minimum security requirements.

    NTLM security levels determine the minimum security settings allowed on a client, server, or DC to authenticate in an NTLM domain. The security levels cannot be modified in Windows NT 4.0 SP3 by setting this registry key to one of the following security level values.

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\

    LMCompatibilityLevel

    Security-level descriptions:

    0: Server sends LM and NTLM response and never uses extended session security. Clients use LM and NTLM authentication, and never use extended session security. DCs accept LM, NTLM, and NTLM v2 authentication.

    1: Servers use NTLM v2 session security if it is negotiated. Clients use LM and NTLM authentication and use extended session security if the server supports it. DCs accept LM, NTLM, and NTLM v2 authentication.

    2: Server sends NTLM response only. Clients use only NTLM authentication and use extended session security if the server supports it. DCs accept LM, NTLM, and NTLM v2 authentication.

    3: Server sends NTLM v2 response only. Clients use NTLM v2 authentication and use extended session security if the server supports it. DCs accept LM, NTLM, and NTLM v2 authentication.

    4:DCs refuse LM responses. Clients use NTLM authentication and use extended session security if the server supports it. DCs refuse LM authentication but accept NTLM and NTLM v2 authentication.

    5:DCs refuse LM and NTLM responses, and accept only NTLM v2. Clients use NTLM v2 authentication and use extended session security if the server supports it. DCs refuse NTLM and LM authentication, and accept only NTLM v2 authentication.

     

     

     

    Also, section  3.3 explains the process in good detail and section 3.3.2 NTLM v2 Authentication, has the following note in line with what I’ve explained above:

     

    Note  The NTLM authentication version is not negotiated by the protocol. It MUST be configured on both the client and the server prior to authentication. The NTOWF v2 and LMOWF v2 functions defined in this section are NTLM version-dependent and are used only by NTLM v2.

     

     

    Please let me know if you need further assistance with this case.

     

    Thanks and regards,


    SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team
    Wednesday, April 21, 2010 10:37 PM
  • Sebastian,

    Thanks for this information, however that doesn't address my situation and the observed behaviour on Windows machines.

    Let me try again.

    The server isn't part of a domain (So we're dealing with the part that says "Stand-alone servers that do not have a DC to authenticate clients set their own minimum security requirements.") and the Security Level is set to the configuration "5".

    Windows clients (Internet Explorer) can authenticate to this server. Other clients (Firefox, or the demo browser from Qt) cannot authenticate to this server.

    I would like to resolve this lack of interoperability.

    In the absence of some general configuration, how does a Windows client know whether to send an NTLM v1 or NTLM v2 response to a server that returns a 401 Unauthortized, containing:

    WWW-Authenticate: Negotiate

    WWW-Authenticate: NTLM

    That is, does it always try NTLM v2 first? Or does it use some heuristic based on the identity of the web server? Or something else?

    Brad

    Friday, April 23, 2010 12:31 AM
  • Hi Brad - Bill Wesse here, standing in for Sebastian, who is out of the office. I apologize for the delay in our response, and am beginning my investigation concerning your question immediately.

    ==============================================================================
    Your question:
    ==============================================================================
    In the absence of some general configuration, how does a Windows client know whether to send an NTLM v1 or NTLM v2 response to a server that returns a 401 Unauthorized, containing:

    WWW-Authenticate: Negotiate
    WWW-Authenticate: NTLM

    That is, does it always try NTLM v2 first? Or does it use some heuristic based on the identity of the web server? Or something else?
    ==============================================================================

    In advance of any verification, I expect that Windows clients will behave normally - that is, try the most robust (e.g. newest supported / most secure) authentication method first: in this case, NTLMv2.

    However, this assumes the following zone specific IE Security Setting:

    Tools (menu) -> Internet Options (menu item) -> Security tab -> (Selected zone) -> [Custom Level]:
    User AUthentication
     Logon
      o Anonymous Logon
      o Automatic logon only in Intranet Zone
      * Automatic logon with current user name and password
      o Prompt for user name and password

    I will update you on my findings as soon as possible, and will advise you of my progress by late afternoon / early evening today (GMT-5: EST).

    Regards,
    Bill Wesse

    Wednesday, April 28, 2010 9:25 AM
  • Brad - could you email the capture you mentioned in your original post to dochelp@microsoft.com (subject: [MS-NLMP / MS-NTHT] Determining NTLM v1 or v2 in HTTP authentication)?

    Thanks!
    Bill Wesse

     

     

    Wednesday, April 28, 2010 9:42 AM
  • Bill.

    I'll have to recapture it - might be a little while.

    Brad

     

    Wednesday, April 28, 2010 10:05 AM
  • Brad - no problem; at your convenience!

    Bill

     

    Thursday, April 29, 2010 9:05 AM
  • Hello Brad - thank you for the network captures. To recap, here is your question:

    In the absence of some general configuration, how does a Windows client know whether to send an NTLM v1 or NTLM v2 response to a server that returns a 401 Unauthorized, containing:

    WWW-Authenticate: Negotiate

    WWW-Authenticate: NTLM

    That is, does it always try NTLM v2 first? Or does it use some heuristic based on the identity of the web server? Or something else?

    To answer to your question with respect to NTLM authorization across HTTP - as constrained by LmCompatibilityLevel (Windows 7 default = 3), a Windows client will select Negotiate/NTLM (a.k.a. extended session security) if offered, NTLM (Signature: "NTLMSSP") if not, and will in either case offer NTLM v2 on the first and only try.

    The general case is that Windows – like any well behaved operating system – will negotiate the authentication method starting with the most robust, and go ‘down’ from there, according to the available security provider package as constrained by system policy.

    The Windows server is set to LmCompatibilityLevel 5: Refuse NTLM and LM authentication, and accept only NTLM v2 authentication. The Linux clients are behaving in a fashion similar to LmCompatibilityLevel 0: Use LM and NTLM authentication, and never use extended session security. In this case, everything is working as designed; the server MUST reject the authentication attempt.

    It might be worth checking smb.conf for [global] client ntlmv2 auth = Yes 

    /etc/samba/smb.conf:

    ...

    [global]

    ...

    client ntlmv2 auth = Yes

    ...

    For the sake of completeness, here are the client and server configurations (with several educated guesses):

    1.       Web Server

    ·         IIS 7 on Windows 2008 R2 (v6.1.7600)

    ·         Offers both Negotiate and NTLM authentication.

    o   WWWAuthenticate: Negotiate

    o   WWWAuthenticate: NTLM

    ·         LmCompatibilityLevel 5: DCs refuse LM and NTLM responses, and accept only NTLM v2. Clients use NTLM v2 authentication and use extended session security if the server supports it.

    2.       Mozilla client (mozilla.pcap)

    ·         Firefox 3.5.9 on Linux v1.9.1.9

    ·         Client response is authentication using NTLM v1. Like LmCompatibilityLevel 0: Use LM and NTLM authentication, and never use extended session security.

    ·         http://www.useragent.org has no listing for the UserAgent string.

    3.       Demo Qt client (originalqtbrowser.pcap)

    ·         demobrowser 0.1 on Linux v? (Safari /532.4)

    ·         Client response is authentication using NTLM v1. Like LmCompatibilityLevel 0: Use LM and NTLM authentication, and never use extended session security.

    ·         http://www.useragent.org has no listing for the UserAgent string.

    4.       Windows client (ntlmv2fromIE.pcap)

    ·         Internet Explorer 8 on Windows 7 (v6.1)

    ·         Client response is authentication GSS-API/NTLMv2.

    ·         LmCompatibilityLevel (probably) 3 (Windows 7 default if not configured in the registry): Clients use NTLM v2 authentication and use extended session security if the server supports it.

    By the way, this is illustrative of how to remotely determine the NTLM security policy on a given Windows instance - without recourse to remote registry (which would, of course require successful authentication), or knowingly being a target for the same security policy (whether domain or machine local).

    Windows clients will try the most robust authentication method first (e.g. first in the SPNEGO offering, or most secure per policy), per the security settings (LmCompatibilityLevel, NtlmMinServerSec, NtlmMinClientSec and so on) as documented at the following links:

    ·         [MS-NLMP] 2.2 Message Syntax http://msdn.microsoft.com/en-us/library/cc236639(v=PROT.13).aspx

    ·         [MS-NLMP] Appendix B: Product Behavior <66> (NTLM Security Considerations) http://msdn.microsoft.com/en-us/library/a211d894-21bc-4b8b-86ba-b83d0c167b00(v=PROT.13)#id66

    ·         Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments http://support.microsoft.com/kb/823659

    10.   Network security: Lan Manager authentication level

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\"LmCompatibilityLevel"   

    15.   NTLMv2 authentication

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"

    ·         For more information, search for 'LmCompatibilityLevel' here:

    Help and Support (Microsoft Knowledge Base search) http://support.microsoft.com/search/

     

    • Proposed as answer by Bill Wesse Thursday, April 29, 2010 1:13 PM
    • Marked as answer by Brad Hards Saturday, May 1, 2010 4:50 AM
    Thursday, April 29, 2010 1:13 PM
  • Bill,

    Thanks for the detailed analysis and response. I think I'll do a little more implementation and a lot more testing, and come back with any follow up questions after that.

    Brad

    Saturday, May 1, 2010 4:50 AM
  • Glad to help, Brad! kb823659 just keeps on popping up for me lately (which pleases me, I had several of my hands in the evolution of the text...).

    Bill Wesse

     

    • Marked as answer by Bill Wesse Monday, May 3, 2010 9:23 AM
    Monday, May 3, 2010 9:23 AM
  • I am facing an authentication error on one of the windows machine when using a domain account. Since this discussion is on the same lines of the issue which I am facing I thought it would be good to open it again to get some opinions or suggestions.

    This error appears only on this particular machine. We use a java implementation of the NTLM protocol for authentication. On analyzing the packets captured using Wireshark, I found that the authentication error occurs when java implementation sets the NT Response Length to 0 while sending the Type 3 message to the server. Since this implementation works everywhere else I am wondering if there are specific settings which control this behavior (i.e. fail the authentication if the NT response is empty). 

    The LmCompatibilityLevel registry key value on the server is 2 and that on the domain controller is 1. It would be great if someone could throw some light on this.

    Thank you.


    Technet Forum Issue
    • Edited by Hi_i_am_Amit Sunday, August 28, 2011 5:58 AM minor changes
    Sunday, August 28, 2011 5:57 AM
  • Hi,

      One of our team members will take a look at your question and respond soon.

    Thanks!

     

     


    Hongwei Sun -MSFT
    Sunday, August 28, 2011 4:40 PM
  • I found the root cause of the issue. The root cause was that the server and domain had NoLMHashPolicy configured. This meant that windows would not store the LM hash value of the password. Since the NTLM protocol implementation we computed only the LM hash value and the NT Hash, the authentication failed. 

    The fix involves modifying the protocol implementation to compute the NT Response Hash before sending the Type3 message to the server.

    Thanks for the help.


    Technet Forum Issue
    Wednesday, August 31, 2011 2:02 PM