• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • ec2-plugin
    • None

      I am trying to set up a Jenkins with Windows on-demand slaves.

      The Windows EC2-Instances are started by the plugin, but the WinRM connection cannot be established. The logs are stuck in a "Waiting for WinRM to come up"-loop.

      But I can create a WinRM-connection to the instances manually using a python library. When I compare both (the connection attempt by the EC2-Plugin and the connection by the lython tool) I observe the following:

      • the POST-request to /wsman is answered with a 401 by the Windows instance
      • this seems to be the case because the Authorization header is completely missing in the request

      Is this a bug in the plugin or am I doing something wrong?

          [JENKINS-58856] No Authorization Header for WinRM connection

          If you are using the generated admin password from AWS, it is supported only from the 1.45, pay attention that you have to update the IAM role. If the password is pre define in the ami, I need to debug

          FABRIZIO MANFREDI added a comment - If you are using the generated admin password from AWS, it is supported only from the 1.45, pay attention that you have to update the IAM role. If the password is pre define in the ami, I need to debug

          Hi thoulen, thanks for your help!

          I am using a custom Windows-Server-2012-AMI that I created using packer.  In this I set a custom admin password using `net user Administrator <password>` in the userdata.  For packer (which is using pywinrm) there is no problem to open a WinRM connection to the instance.

          I am using the plugin version 1.44.1.

          Is there any other information that you need?

           

          All the best

          Christoph

          Christoph Niehoff added a comment - Hi thoulen , thanks for your help! I am using a custom Windows-Server-2012-AMI that I created using packer.  In this I set a custom admin password using `net user Administrator <password>` in the userdata.  For packer (which is using pywinrm) there is no problem to open a WinRM connection to the instance. I am using the plugin version 1.44.1. Is there any other information that you need?   All the best Christoph

          Do you have basic authentication enabled?

          Raihaan Shouhell added a comment - Do you have basic authentication enabled?

          Under Configure System > Cloud > Amazon EC2  I entered the Windows Admin Password. I assume that is what you mean by "basic authentication enabled"? 

          Christoph Niehoff added a comment - Under Configure System > Cloud > Amazon EC2  I entered the Windows Admin Password. I assume that is what you mean by "basic authentication enabled"? 

          The agent's winrm settings

          Raihaan Shouhell added a comment - The agent's winrm settings

          As said above, winrm is generally working for the AMI. For Example, using pywinrm I can connect to a running instance with username/password.

          But it appears that the winrm connection that the EC2 plugin tries to initiate does not work as there is no Authorization Header in the request that goes to the instance.

          Christoph Niehoff added a comment - As said above, winrm is generally working for the AMI. For Example, using pywinrm I can connect to a running instance with username/password. But it appears that the winrm connection that the EC2 plugin tries to initiate does not work as there is no Authorization Header in the request that goes to the instance.

          My question is mostly on how it is configured on the agent as depending on authorization schemes it may not work.

          AFAIK Basic Scheme works with the built in Administrator. I have never tried it with a domain user either so I am unsure if it works.

          Raihaan Shouhell added a comment - My question is mostly on how it is configured on the agent as depending on authorization schemes it may not work. AFAIK Basic Scheme works with the built in Administrator. I have never tried it with a domain user either so I am unsure if it works.

          Christoph Niehoff added a comment - - edited

          Yes, I use the Administrator as I read that domain users do not work.

          Using the packer the following powershell script is given to the Instances user_data:

           <powershell>

          write-output "Running User Data Script"
          write-host "(host) Running User Data Script"

          Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force -ErrorAction Ignore

          net user Administrator {{ user `administrator_password` }}

          $ErrorActionPreference = "stop"

          Remove-Item -Path WSMan:\\Localhost
          listener
          listener* -Recurse

          $Cert = New-SelfSignedCertificate -CertstoreLocation Cert:
          LocalMachine
          My -DnsName "packer"
          New-Item -Path WSMan:\\LocalHost
          Listener -Transport HTTPS -Address * -CertificateThumbPrint $Cert.Thumbprint -Force

          write-output "Setting up WinRM"
          write-host "(host) setting up WinRM"

          cmd.exe /c winrm quickconfig -q
          cmd.exe /c winrm set "winrm/config" '@{MaxTimeoutms="1800000"}'
          cmd.exe /c winrm set "winrm/config/winrs" '@{MaxMemoryPerShellMB="1024"}'
          cmd.exe /c winrm set "winrm/config/service" '@{AllowUnencrypted="true"}'
          cmd.exe /c winrm set "winrm/config/client" '@{AllowUnencrypted="true"}'
          cmd.exe /c winrm set "winrm/config/service/auth" '@{Basic="true"}'
          cmd.exe /c winrm set "winrm/config/client/auth" '@{Basic="true"}'
          cmd.exe /c winrm set "winrm/config/service/auth" '@{CredSSP="true"}'
          cmd.exe /c winrm set "winrm/config/listener?Address=*+Transport=HTTPS" "@{Port=`"5986`";Hostname=`"packer`";CertificateThumbprint=`"$($Cert.Thumbprint)`"}"
          cmd.exe /c netsh advfirewall firewall set rule group="remote administration" new enable=yes
          cmd.exe /c netsh firewall add portopening TCP 5986 "Port 5986"
          cmd.exe /c net stop winrm
          cmd.exe /c sc config winrm start= auto
          cmd.exe /c net start winrm

          </powershell>

          Christoph Niehoff added a comment - - edited Yes, I use the Administrator as I read that domain users do not work. Using the packer the following powershell script is given to the Instances user_data:  <powershell> write-output "Running User Data Script" write-host "(host) Running User Data Script" Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force -ErrorAction Ignore net user Administrator {{ user `administrator_password` }} $ErrorActionPreference = "stop" Remove-Item -Path WSMan:\\Localhost listener listener* -Recurse $Cert = New-SelfSignedCertificate -CertstoreLocation Cert: LocalMachine My -DnsName "packer" New-Item -Path WSMan:\\LocalHost Listener -Transport HTTPS -Address * -CertificateThumbPrint $Cert.Thumbprint -Force write-output "Setting up WinRM" write-host "(host) setting up WinRM" cmd.exe /c winrm quickconfig -q cmd.exe /c winrm set "winrm/config" '@{MaxTimeoutms="1800000"}' cmd.exe /c winrm set "winrm/config/winrs" '@{MaxMemoryPerShellMB="1024"}' cmd.exe /c winrm set "winrm/config/service" '@{AllowUnencrypted="true"}' cmd.exe /c winrm set "winrm/config/client" '@{AllowUnencrypted="true"}' cmd.exe /c winrm set "winrm/config/service/auth" '@{Basic="true"}' cmd.exe /c winrm set "winrm/config/client/auth" '@{Basic="true"}' cmd.exe /c winrm set "winrm/config/service/auth" '@{CredSSP="true"}' cmd.exe /c winrm set "winrm/config/listener?Address=*+Transport=HTTPS" "@{Port=`"5986`";Hostname=`"packer`";CertificateThumbprint=`"$($Cert.Thumbprint)`"}" cmd.exe /c netsh advfirewall firewall set rule group="remote administration" new enable=yes cmd.exe /c netsh firewall add portopening TCP 5986 "Port 5986" cmd.exe /c net stop winrm cmd.exe /c sc config winrm start= auto cmd.exe /c net start winrm </powershell>

          For my own I do not have credssp enabled but our user data scripts look identical. My setup does work with that script.

          Note group policies override anything you attempt to set on the command line.

          Raihaan Shouhell added a comment - For my own I do not have credssp enabled but our user data scripts look identical. My setup does work with that script. Note group policies override anything you attempt to set on the command line.

          bruce szalwinski added a comment - - edited

          For me, the ec2 cloud configuration had a previous value for the hard coded password.  I used tcpdump on the jenkins server to capture traffic between the server and the agent.  Then used wireshark to analyze the results, looking at the host headers to see what the Authorization values looked like.  I used base64 to decode the auth header, and there is was, PEBCAK!

          I updated the hard coded password and now have a windows ec2 agent!

          I'm using jenkins-server 2.235.5, ec2-plugin 1.55.

          bruce szalwinski added a comment - - edited For me, the ec2 cloud configuration had a previous value for the hard coded password.  I used tcpdump on the jenkins server to capture traffic between the server and the agent.  Then used wireshark to analyze the results, looking at the host headers to see what the Authorization values looked like.  I used base64 to decode the auth header, and there is was, PEBCAK! I updated the hard coded password and now have a windows ec2 agent! I'm using jenkins-server 2.235.5, ec2-plugin 1.55.

            thoulen FABRIZIO MANFREDI
            christophniehoff Christoph Niehoff
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: