Packer: Using Elevated PowerShell provisioner with AWS auto-generated password

Created on 28 Jul 2015  路  4Comments  路  Source: hashicorp/packer

It appears to be undocumented as to if it is possible, or how to use the auto-generated AWS Windows password with the powershell elevated_password parameter. Setting "elevated_password": "{{ .WinRMPassword }}" does not seem to work (I get "incorrect password" errors). Further, there seems to be no way to dump variables out to a file anywhere to inspect them and figure out what exactly I should be putting in the template interpolation, if anything. I'd prefer not to use a static password of course - let me know if I have to.

bug communicatowinrm

Most helpful comment

I'm finding that I still can not run certain things. The issue I'm running into is installing WMF 5.0. I'm having to manually run it as a scheduled task using the local System account. My script is something like this:

$action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument '-WindowStyle Hidden -command "& { wusa.exe C:\Windows\Temp\Win8.1AndW2K12R2-KB3134758-x64.msu /quiet /norestart /log }"'
$task = Register-ScheduledTask "Install WMF" -Action $action -User "System"
Start-ScheduledTask -InputObject $task

Looking at the code in elevated.go it looks like packer is using a scheduled task as well. It would be convenient if packer offered a way to use one of the local accounts that do not have passwords (such as System). Currently if you pass in an empty password you will get an error related.

Anyway, wanted to comment in case someone else is running into Access Denied related errors.

All 4 comments

Thanks for the report! I have not looked at the code but I think you will have to use a hard-coded value for now.

Internally the builder sets this value in the communicator, which knows how to login. The communicator is passed off to the provisioner (winrm) and but (I think) the password itself is not. You could think of it as a private visibility scenario.

Further, there seems to be no way to dump variables out to a file anywhere to inspect them and figure out what exactly I should be putting in the template interpolation, if anything.

I've noticed this too, and I don't have a good solution. packer inspect will show you some things, but probably not what you want in this case. In general, not a lot of variables are shared throughout a packer run. Mostly it's the user variables you pass in.

Good to know. Thanks for the quick response! I did some more testing and it turns out Amazon ships their AMIs with UAC off for the Administrator user, so elevated_password/user is actually 100% not needed if you're using the Amazon Windows AMIs as the default - just use PowerShell normally since it's already an admin token.

Amazon ships their AMIs with UAC off for the Administrator user, so elevated_password/user is actually 100% not needed if you're using the Amazon Windows AMIs as the default

That's great to know! Thanks for sharing your findings :)

I'm finding that I still can not run certain things. The issue I'm running into is installing WMF 5.0. I'm having to manually run it as a scheduled task using the local System account. My script is something like this:

$action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument '-WindowStyle Hidden -command "& { wusa.exe C:\Windows\Temp\Win8.1AndW2K12R2-KB3134758-x64.msu /quiet /norestart /log }"'
$task = Register-ScheduledTask "Install WMF" -Action $action -User "System"
Start-ScheduledTask -InputObject $task

Looking at the code in elevated.go it looks like packer is using a scheduled task as well. It would be convenient if packer offered a way to use one of the local accounts that do not have passwords (such as System). Currently if you pass in an empty password you will get an error related.

Anyway, wanted to comment in case someone else is running into Access Denied related errors.

Was this page helpful?
0 / 5 - 0 ratings