Using Packer with Windows 2012 CIS Benchmark (Hardened) AMIs

[Andres Urrutia]

Hi,

I am trying to use Packer to build new AMIs using the Windows 2012 CIS Benchmark (Hardened) image as the Source AMI:

https://aws.amazon.com/marketplace/pp/B00UVT62LG

The problem I am facing is that Packer is not able to connect to the EC2 instance via WinRM once the server is up. The following is the error I get in the 'packer.log' file that is generated:

2018/05/07 18:04:20 packer: 2018/05/07 18:04:20 [ERROR] connection error: http response error: 401 - invalid content type

2018/05/07 18:04:20 packer: 2018/05/07 18:04:20 [ERROR] WinRM connection err: http response error: 401 - invalid content type

After troubleshooting for many days, I found out that the following GPO that is automatically enabled by this Hardened AMI is what's causing Packer to timeout and fail:

HKLM\Software\Policies\Microsoft\Windows\WinRM\Service!AllowBasic

The GPO restricts the use of Basic Authentication. If I manually RDP into the instance and enable that from the Policy Editor, Packer successfully connects to the instance.

I read the Packer documentation and there is a way to change the Authentication mechanism by setting the field "winrm_use_ntlm" to True. I tried doing that but Packer is still timing out when it tries to connect to the instance via WinRM.

Has anybody seen this issue in the past? Is there a way to configure Packer to connect to this instance using "Non-Basic Authentication" and without having to manually edit the GPO?

Thanks for the support!

Andres

[Alvaro Miranda Aguilera]

if you need to run an script, you can use user_data

https://www.packer.io/docs/builders/amazon-ebs.html#user_data

that should help to make the VM packer friendly

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/04422e65-4c39-47bc-b9e0-f067f5c95e67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alvaro

[Andres Urrutia]

Thank you Alvaro,

I have used "User Data" to send the WinRM Configuration script, etc. However, the script fails because the GPO that is configured in this Hardened version of Windows does not allow "Basic Authentication" in WinRM to be enabled.

If I use the regular version of Windows 2012, the script works and Packer can connect to the instance. But I have not been able to make it work with this "Hardened" version.

I read in the Packer documentation site that it supports Basic Authentication and NTLM Authentication.

Have you used NTLM Authentication in the past with Packer?  

Thanks again.

Andres

[Alvaro Miranda Aguilera]

Hello

I haven't but its on the documentartion, so is safe to assume it works.

documentation

https://www.packer.io/docs/templates/communicator.html#winrm-communicator

winrm_use_ntlm (boolean) - If true, NTLM authentication will be used for WinRM, rather than default (basic authentication), removing the requirement for basic authentication to be enabled within the target guest. Further reading for remote connection authentication can be found here.

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/908eefb0-b0fb-4dc2-87d3-34b4afa231c9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alvaro

[Jordan Borean]

I believe the other issue is that Packer (or whatever libraries Packer uses for WinRM) does not encrypt the WinRM data so anything over http is in plaintext. You can disable the encryption check by running

Set-Item -Path WSMan:\localhost\Server\AllowUnencrypted -Value $true

This means that Windows will allow connections that do not encrypt the data but I doubt a hardened AMI would allow this change as it is quite insecure. What you really want to do is use a https listener which uses TLS to encrypt the data. This requires further steps as part of your bootstrapping process ot create the self-signed cert and https listener but it can be done. In Ansible land we use https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1 but you will probably need to modify it to work on your AMI.

Thanks

Jordan

[Rickard von Essen]

Just to clearify Packer does speak WinRM over HTTPS. See https://www.packer.io/docs/templates/communicator.html#winrm_use_ssl

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.

To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/b72debbe-86b4-4cad-b6e3-ea82883b4b70%40googlegroups.com.

[Serge Nikalaichyk]

Hello all!

I'm having the same problem with the hardened Windows Server 2016 AMI that has Basic authentication explicitly disabled by the Group Policy.
The use of NTLM authentication is the solution and it works fine from PowerShell and Ansible.

The Packer's winrm_use_ntlm option just doesn't seem to work. The issue is reproducible over both HTTPS and HTTP.
Wireshark log shows that NTLM packet is malformed.

There is a similar issue on GitHub: winrm hyperv 401 error #6205

[Andres Urrutia]

Thanks Serge.

I am glad to know I am not the only one experiencing that issue. As you mentioned above, this issue is reproducible over HTTP and HTTPS. I have been able to setup an encrypted connection using HTTPS and a self-signed certificate. However, my issue is with the authentication piece. The hardened AMI does not allow "basic" authentication for WinRM and when I try to use Packer's NTLM option it just doesn't work. 

Do you know of a way to contact Packer developers to let them know about the NTLM malformed packet that you found?

Thanks again.

Andres

[Megan Marsh]

The best way to contact us (Packer developers, that is) regarding bugs is through Packer's github issues. Serge has shared some of his details in the above ticket; we just haven't had a chance to do the investigation yet.  I've commented in said ticket asking for more details there; ultimately it's just a matter of finding time to dig into this.

[Andres Urrutia]

Excellent - thank you Megan.

Let me know know if you need my help doing any testing/troubleshooting on my side.

Appreciate the support.

Andres

[Megan Marsh]

No problem; any testing, logs, troubleshooting, repro cases etc that you can share make it much easier for us once we get started on an investigation, so if you've got anything please let us know. Otherwise, I'll update that ticket when I start looking at it.

[Jordan Borean]

Hi Andres

I was curious as to what was happening here and did a bit of investigating, I've posted my results here https://github.com/hashicorp/packer/issues/6205#issuecomment-391911194. TLDR

• WinRM with NTLM auth is not encrypted so running over HTTPS should solve that issue

I see you said you can replicate this over HTTPS so I am curious as to what your packer.json file and the bootstrapping script you are running looks like. The only other explanation I can find is maybe the LocalAccountTokenFilterPolicy is not set up to allow administrative remote access that is required by WinRM https://support.microsoft.com/en-us/help/942817/how-to-change-the-remote-uac-localaccounttokenfilterpolicy-registry-se.

Thanks

Jordan

[Serge Nikalaichyk]

Please check out my comment on GitHub.