2

I am beginning user of Windows Containers, and am novice at Windows management, so I've been digging at this for a couple days with only not-quite-there success.

My dockerfile;

FROM mcr.microsoft.com/windows/servercore:10.0.14393.3866
# expose WinRM port
EXPOSE 5985
# create a local user
RUN net user user1 Pa55w0rd! /ADD
RUN net localgroup "Administrators" user1 /ADD
RUN net localgroup "Remote Management Users" user1 /ADD
RUN winrm set winrm/config/client @{TrustedHosts="*"}

As docker build runs, I see the winrm client config echoed as;

Step 6/6 : RUN winrm set winrm/config/client @{TrustedHosts="*"}
 ---> Running in a38ce9015919
Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = false
    Auth
        Basic = true
        Digest = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = *

When I start the container in interactive mode, I can use winrs locally on the container;

C:\>winrs -u:172.18.106.64\user1 -p:Pa55w0rd! dir c:\
winrs -u:172.18.106.64\user1 -p:Pa55w0rd! dir c:\
 Volume in drive C has no label.
 Volume Serial Number is D4B7-E02B

 Directory of c:\

11/22/2016  06:45 PM             1,894 License.txt
08/08/2020  03:24 PM    <DIR>          PerfLogs
08/08/2020  03:35 PM    <DIR>          Program Files
07/16/2016  09:18 AM    <DIR>          Program Files (x86)
08/26/2020  10:27 AM    <DIR>          Users
08/24/2020  03:20 PM    <DIR>          Windows
               1 File(s)          1,894 bytes

From the host computer I can telnet to the WinRm port on the container, and when I type 'HELP' get;

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Wed, 26 Aug 2020 14:43:23 GMT
Connection: close
Content-Length: 326

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Verb</h2>
<hr><p>HTTP Error 400. The request verb is invalid.</p>
</BODY></HTML>

However, when I use winrs from the host computer, I get this error;

PS C:\Users\xxxxx> winrs -r:http://172.18.106.64 -u:172.18.106.64\user1 -p:Pa55w0rd! dir c:\


Winrs error:The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.

Keying on "If the authentication scheme is different from Kerberos..." I'm thinking I need to disable all other Auth mechanisms except Kerberos in the container's WinRM client config, which I will try next.

Note, I do not have administrator privilege on the host computer, so I cannot add the destination machine to the TrustedHosts configuration setting on the host computer. Besides, the IP of the container will change every time it is launched, anyway. Asking admins to set trust to '<local>' probably isn't going to be accepted, unless I can provide a whitepaper explaining how this does not present a security risk to my host PC.

Is there a simple approach I'm overlooking here?

EDIT: I tried disabling everything except Kerberos - didn't work;

Auth
    Basic = false
    Digest = false
    Kerberos = true
    Negotiate = true
    Certificate = false
    CredSSP = false
1
  • Please consider marking the answer as the solution.
    – Dennis
    Commented Jan 17 at 20:59

1 Answer 1

3

After struggling with this I realized that WinRM must be running on both the client (container host) and the server (container). I also found that WinRM was not running on my host. After some other digging, I found the reason WinRM was not running on my host was that my primary network connection was set to 'Public' mode. The solution to this was to open Network and Internet settings, change the adapter to 'Private' mode, and reboot.

Then I ran into this problem;

The WinRM client cannot process the request. If the authentication scheme is
different from Kerberos, or if the client computer is not joined to a domain,
then HTTPS transport must be used or the destination machine must be added to 
the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts.
Note that computers in the TrustedHosts list might not be authenticated. You can
get more information about that by running the following command: winrm help
config.

This is a problem on the client (container host) side, and was easily fixed by this command;

winrm set winrm/config/client @{TrustedHosts="*"}

Now I can verify connectivity from the container host to the container with

PS> winrm id -r:172.19.6.97 -u:172.19.6.97\user1 -p:Pa55w0rd!
IdentifyResponse
    ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
    ProductVendor = Microsoft Corporation
    ProductVersion = OS: 10.0.14393 SP: 0.0 Stack: 3.0
    SecurityProfiles
        SecurityProfileName = http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/http/spnego-kerberos

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .