none
Why does win 8 send "spnego extended nego" when linux server does not support spnego ex nego mechanism RRS feed

  • Question

  • For one of a customer Win 8 is trying to authenticate using "spnego extended nego" even though Linux server has not sent "spnego extended nego" as supported mechanism in "smb2 negotiate protocol response'.

    This issue happens from win8 when customer tries to access using run  server command. After several attempts Win8 client uses "spnego ntlmssp " method and authentication succeeds.

    Is it mandatory for Linux server to implement "spnego extended nego" ?

    Thursday, November 19, 2015 3:12 PM

Answers

  • Hi Sridhara:
    As stated in MS-AUTHSOD section "2.9 Security" (https://msdn.microsoft.com/en-us/library/gg604731.aspx) :

    "
    Implementers should be aware that Kerberos Protocol Extensions [MS-KILE] and public key-based
    authentication ([MS-PKCA] and [MS-TLSP]) offer stronger security guarantees in terms of initial
    authentication and in subsequent confidentiality and integrity of client-server traffic and server-server
    traffic. Digest authentication or NTLM authentication can be used in environments in which these
    stronger mechanisms are not available.
    "

    The client will try to use the strongest authentication mechanism that it supports. In this case the authentication
    mechanism that is client is trying to use is PKU2U (this is the only protocol supported by NEGOX currently). Since your client is configured to support it. PKU2U is based on public key cryptography and therefore offers stronger security guarantee than NTLM. Therefore client tries it first and ignores what server sends in the negotiate response.
    If your server does not support it, please send the mechanisms server supports in negTokenResp and client will use the the one from that list that it supports. Based on your description, it appears that your server is already doing that. Your Linux server is not required to implement NEGOEX. Client tries it since it offers a stronger security guarantee.

    For more information on negox and PKU2U, please consult:
    [NEGOEX-DRAFT] Short, M., Zhu, L., Damour, K., and McPherson, D., "The Extended GSS-API Negotiation Mechanism (NEGOEX)", December 2010, http://tools.ietf.org/id/draft-zhu-negoex-02.txt

    [PKU2U-DRAFT] Zhu, L., Altman, J., and Williams, N., "Public Key Cryptography Based User-to-User Authentication (PKU2U)", November 2008, http://tools.ietf.org/id/draft-zhu-pku2u-09.txt

    A quick look at the new negotiation mechanism (NegoEx) used with SPNEGO in Windows 7 (http://blogs.msdn.com/b/openspecification/archive/2011/07/01/a-quick-look-at-the-new-negotiation-mechanism-negoex-used-with-spnego-in-windows-7.aspx)

    Please let me know if this does not answer your question.


    Regards, Obaid Farooqi


    Thursday, December 3, 2015 11:50 PM
    Owner

All replies

  • Sridhara,

    Thank you for your question.  An engineer from the protocols team will contact you soon.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, November 19, 2015 8:03 PM
    Moderator
  • Hi Sridhara:

    I'll help you with this issue.

    Can you please send me a network trace showing this behavior? you can send it to my attention to dochelp at Microsoft dot com.

    In case it is not possible to attach the trace to the email message, just send me an email at the above address. I'll reply to that email with info about how to upload the trace to a file transfer workspace.


    Regards, Obaid Farooqi

    Friday, November 20, 2015 6:09 PM
    Owner
  • Hi Sridhara:
    As stated in MS-AUTHSOD section "2.9 Security" (https://msdn.microsoft.com/en-us/library/gg604731.aspx) :

    "
    Implementers should be aware that Kerberos Protocol Extensions [MS-KILE] and public key-based
    authentication ([MS-PKCA] and [MS-TLSP]) offer stronger security guarantees in terms of initial
    authentication and in subsequent confidentiality and integrity of client-server traffic and server-server
    traffic. Digest authentication or NTLM authentication can be used in environments in which these
    stronger mechanisms are not available.
    "

    The client will try to use the strongest authentication mechanism that it supports. In this case the authentication
    mechanism that is client is trying to use is PKU2U (this is the only protocol supported by NEGOX currently). Since your client is configured to support it. PKU2U is based on public key cryptography and therefore offers stronger security guarantee than NTLM. Therefore client tries it first and ignores what server sends in the negotiate response.
    If your server does not support it, please send the mechanisms server supports in negTokenResp and client will use the the one from that list that it supports. Based on your description, it appears that your server is already doing that. Your Linux server is not required to implement NEGOEX. Client tries it since it offers a stronger security guarantee.

    For more information on negox and PKU2U, please consult:
    [NEGOEX-DRAFT] Short, M., Zhu, L., Damour, K., and McPherson, D., "The Extended GSS-API Negotiation Mechanism (NEGOEX)", December 2010, http://tools.ietf.org/id/draft-zhu-negoex-02.txt

    [PKU2U-DRAFT] Zhu, L., Altman, J., and Williams, N., "Public Key Cryptography Based User-to-User Authentication (PKU2U)", November 2008, http://tools.ietf.org/id/draft-zhu-pku2u-09.txt

    A quick look at the new negotiation mechanism (NegoEx) used with SPNEGO in Windows 7 (http://blogs.msdn.com/b/openspecification/archive/2011/07/01/a-quick-look-at-the-new-negotiation-mechanism-negoex-used-with-spnego-in-windows-7.aspx)

    Please let me know if this does not answer your question.


    Regards, Obaid Farooqi


    Thursday, December 3, 2015 11:50 PM
    Owner