Packer times out following domain join with WinRM

[JF Simard]

Hello! I'm fairly new to Packer but I believe there may be an "issue" with the WinRM Communicator on a very specific case: While this is typically very rare, I need to join my images to our domain based on Citrix recommendations, when the image is not using their MCS feature.

Now, I am able to run the complete process of my Citrix images build via WinRM. However, once I join to the domain, the communication instantly stops, even before the machine is rebooted.

I am not super familiar with Packer nor WinRM, but I did the following to troubleshoot:

• Start Powershell from my own machine
• Run the lines (To initiate an https connection with unverified certificate):

$Creds = Get-Credential (Entered the winrm_user and winrm_password I supplied to packer in my code)
$sessionOption = New-PSSessionOption -SkipCACheck -SkipCNCheck
New-PSSession -ComputerName "IpOfMyPackerCreatedMachine" -Credential $Creds -SessionOption $sessionOption -UseSSL

• Until I join the domain, I can run the last command multiple times and it goes through.
• The second the computer is joined (even before the required restart of the machine), I lose connection and I get an "Access Denied".

After more troubleshooting, I realized that WinRM changes and tries to use the supplied credentials with @mydomain.com instead of trying to authenticate locally. If I re-run $Creds = Get-Credential and enter local\packeruser however, it works!

I tried to set winrm_user to local\packeruser but, that fails to create the Azure VM stating that there is an invalid character for the admin user. Is there any way to make this work? The following is what I have set for the communicator, to create an Azure VM:

  communicator   = "winrm"
  winrm_insecure = true
  winrm_username = "packer"
  winrm_use_ssl  = true
  winrm_password = "FictivePassword"
(also tried winrm_use_ntlm = true, but no luck)

Thanks in advance!

[JF Simard]

I am fairly certain that if there was a "local" appended during the winrm connection that would prevent this issue from happening. I'm still trying to find a workaround. I also tried using an existing AD user as the local user credentials on the machine for packer, but it does the same behavior on my end unfortunately.