none
HTTP 400 when using [MS-WSMV] WSMan/WinRM Message Encryption with Negotiate (NTLM token) RRS feed

  • Question

  • There have been a few posts on implementing WSMan/WinRM Message Encryption, but these have focused on kerberos. According to [MS-WSMV] Section 2.2.9.1.1 the 'Negotiate' method is supported. The document mentions SPNEGO and using GSS-API to encrypt and decrypt. However, when using Negotiate a base64 encoded NTLM token can be supplied instead of wrapping it in an SPNEGO token.
    This appears to be a supported scenario, since the Windows 'winrs' tool uses it - but I dont seem to be able to get the incantation quite right in my implementation. For example, during the NTLM negotiation the client and a Windows Server agree on NTLM2 extended Session security with key exchange and a 128bit key. In my final response I send the Type 3 (Authenticate token) in the header and sign and concatenate the encrypted SOAP request in the appropriate mime part (prepended with the length of the NTLM signature, 0x10 as a 32bit unsigned value). I believe I am using the appropriate algorithm for NTLM key derivation and signing and sealing based on the Negotiation flags in [MS-NLMP].  I also set the 'OriginalContent' header to the plaintext length. The Windows Server always reposonds with a HTTP 400 Bad Request and closes the connection.

    I ran and formatted the output of:  logman.exe start winrmtrace -p Microsoft-Windows-Winrm -o winrmtrace.etl -ets

    ... [Microsoft-Windows-WinRM]Sending HTTP 401 response to the client and disconnect the connection after sending the response 
    ... [Microsoft-Windows-WinRM]User SERVER2012\Administrator authenticated successfully using NTLM authentication 
    ... [Microsoft-Windows-WinRM]Authorizing the user 
    ... [Microsoft-Windows-WinRM]The authorization of the user was done successfully 
    ... [Microsoft-Windows-WinRM]Sending HTTP error back to the client due to a transport failure.  The HTTP status code is 400  The error code is 13

    What is error code 13?

    I have captured ETW and WPP traces and would like a engineer to take a look and help determine the cause of the HTTP 400 failure. Unfortunately I cannot attach them to the post so I will mail them to you at dochelp@microsoft.com and keep the forum updated on the finding so other implementers may benefit.

    Thanks
    Ian


    • Edited by Ian.Clegg Monday, February 2, 2015 10:13 AM Adding ETW information
    Monday, February 2, 2015 10:02 AM

Answers

  • UPDATE:

    At first we thought there was a problem with the NTLM signature checksum (MAC) which precedes the encrypted message bytes, so we doubled checked this was correct.

    While Obaid was looking at the issue and some same code I sent, I went through everything again. After a couple of hours I found the problem. I had a padding white space (0x20) and not a Horizontal Tab (0x09) within the first encrypted boundary before Content-Type and before OriginalContent

    This is a snippit of what I was sending, note the SPACE (0x20):

    --Encrypted Boundary
    (0x20)Content-Type: application/HTTP-SPNEGO-session-encrypted
    (0x20)OriginalContent: type=application/soap+xml;charset=UTF-8;Length=1638
    --Encrypted Boundary
    Content-Type: application/octet-stream

    This is a snippit of what I should have been sending (note the TAB, 0x09):

    --Encrypted Boundary
    (0x09)Content-Type: application/HTTP-SPNEGO-session-encrypted
    (0x09)OriginalContent: type=application/soap+xml;charset=UTF-8;Length=1638
    --Encrypted Boundary
    Content-Type: application/octet-stream

    I copied and pasted this from a packet capture UI so I guess the tab whitespace was replaced by a real space. I found when reading [MS-WSMV] again 2.2.9.1.1.2.1 Metadata Fields

    OriginalContent: Contains information about the original message before encryption.
    OriginalContent=HT"OriginalContent"":
    "1#(contenttype";""charset""="charsetvalue";
    ""Length""="lengthvalue)
    HT: The horizontal tab character. It MUST precede the literal "OriginalContent".

    The error message 'Failed to decrypt packet' was obviously misleading

    Once more I want to thank Obaid for getting stuck in and looking at this from a number of angles.

    • Marked as answer by Ian.Clegg Wednesday, February 11, 2015 10:43 PM
    Wednesday, February 11, 2015 3:06 PM

All replies

  • UPDATE:
    I ran a WPP trace:

    Import-Module psdiagnostics
    Enable-WSManTrace
    <Reproduce issue>
    Disable-wsmantrace

    Then examined the trace file in windir%\system32\wsmtraces.log. Although this is binary trace file it does contain some trace messages I noticed:

    'Failed to decrypt packet'

    The trace file referenced my OS build (9600.17031.amd64fre.winblue_gdr.140221-1952) and a PDB (WsmSvc.pdb). I took a look at wsmsvc.dll in Windbg and downloaded the PDB from Microsofts Symbol Server.
    The 'Failed to decrypt packet' message originates in: WSManHttpListenerRequest::DecryptCurrentPacket. This occurs after authentication.
    Also, 'Error Code 13' should be interpreted as a Win32 Error Code, in this case 'Invalid Data'

    The actual processing of the encrypted mime part is performed in wsmsvc!EncryptDecryptHelper::DoPartDecryption. This method processes the content-type headers, along with the length and locates the encrypted buffer. It then calls EncryptDecryptHelper::DoDecryptionInternalNego which makes the call to the publically documented Win32 SSPI DecryptMessage function along with the established negotiate security context - this seems relatively straight forward.

    However, somewhere in this process my request is failing. The next step would be to place appropriate breakpoints in the svchost.exe process which hosts the WinRM service... but..

    I hope an engineer will be able to look at the WPP trace and determine exactly where it goes wrong.


    Monday, February 2, 2015 11:05 AM
  • Hello Ian - We have created a case for the similar mail you sent us to dochelp and an engineer will assist you through email. Kindly post your findings here once the issue is resolved.

    Thanks.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Monday, February 2, 2015 4:09 PM
  • forum update:

    I am working with Ian offline through email. Once a resolution is reached, I'll update this thread.


    Regards, Obaid Farooqi

    Monday, February 2, 2015 11:11 PM
    Owner
  • UPDATE:

    At first we thought there was a problem with the NTLM signature checksum (MAC) which precedes the encrypted message bytes, so we doubled checked this was correct.

    While Obaid was looking at the issue and some same code I sent, I went through everything again. After a couple of hours I found the problem. I had a padding white space (0x20) and not a Horizontal Tab (0x09) within the first encrypted boundary before Content-Type and before OriginalContent

    This is a snippit of what I was sending, note the SPACE (0x20):

    --Encrypted Boundary
    (0x20)Content-Type: application/HTTP-SPNEGO-session-encrypted
    (0x20)OriginalContent: type=application/soap+xml;charset=UTF-8;Length=1638
    --Encrypted Boundary
    Content-Type: application/octet-stream

    This is a snippit of what I should have been sending (note the TAB, 0x09):

    --Encrypted Boundary
    (0x09)Content-Type: application/HTTP-SPNEGO-session-encrypted
    (0x09)OriginalContent: type=application/soap+xml;charset=UTF-8;Length=1638
    --Encrypted Boundary
    Content-Type: application/octet-stream

    I copied and pasted this from a packet capture UI so I guess the tab whitespace was replaced by a real space. I found when reading [MS-WSMV] again 2.2.9.1.1.2.1 Metadata Fields

    OriginalContent: Contains information about the original message before encryption.
    OriginalContent=HT"OriginalContent"":
    "1#(contenttype";""charset""="charsetvalue";
    ""Length""="lengthvalue)
    HT: The horizontal tab character. It MUST precede the literal "OriginalContent".

    The error message 'Failed to decrypt packet' was obviously misleading

    Once more I want to thank Obaid for getting stuck in and looking at this from a number of angles.

    • Marked as answer by Ian.Clegg Wednesday, February 11, 2015 10:43 PM
    Wednesday, February 11, 2015 3:06 PM