winrm_username/password vs elevated_user/password

[andr...@gmail.com]

Hello,

can some explain to me why, for winrm we specify winrm_username/password in the builder, but we specify elevated_user/password to run the very same script in the provisioner?

I understand that you usually do not need both, but why credentials to run the same thing are specified in two different places depending on if it's an elevated run or not?

Cheers,

Andrew

[Jordan Borean]

An elevated command is run through a scheduled task and for that task to work correctly, both the username and password must be set on the task definition. You can created a scheduled task under different users hence why the username and password is set independently from the standard winrm username and password.

[andr...@gmail.com]

I don't think I understand this.

>>An elevated command is run through a scheduled task and for that task to work correctly, both the username and password must be set on the task definition

Okay, but same goes for regular WinRm connection except the scheduled task part. For a regular WinRm connection also both the username and password must be provided. So I do not see substantial difference here. Is there?

>> You can created a scheduled task under different users hence why the username and password is set independently from the standard winrm username and password.

Similarly, you might want to create a WinRm connection under a different user too, yet, packer supports that only for elevated user. It would be interested to find out why the distinction.

As you can see I was not able to make sense of your explanation - could you please expand?

Thanks,

Andrew

[Jordan Borean]

I'll try my best to explain it so here goes.

Okay, but same goes for regular WinRM connection except the scheduled task part. For a regular WinRm connection also both the username and password must be provided. So I do not see substantial difference here. Is there?

I don't fully understand the internals of Packer but I believe this may just be a cosmetic/UI decision to enforce the elevated_user and elevated_password variables and make them independent to the winrm_username and winrm_password. Theoretically there could be some sort of boolean flag like run_elevated which takes the existing winrm credentials and run it in the scheduled task but I don't think that is the case. The reason why it is independent is that you connect to a box with WinRM using the Administrator account but want to run "elevated" with say the DOMAIN\ServiceAccount or just another local account. Having the elevated task source from a different set of variables allows this behaviour whereas if you were to only have the one variables, you could only run an elevated command under the winrm user. Granted this may be a niche case but it is a valid thing to do.

Similarly, you might want to create a WinRm connection under a different user too, yet, packer supports that only for elevated user. It would be interested to find out why the distinction.

Probably for the simplicity, you usually only need to connect to the host through one set of WinRM credentials. It could also be difficult to change the underlying transport provider at different phases depending on how the code is written and put together. Even so, the elevated_user allows you to run under a different user so there really isn't much of a need to connect under a different WinRM user IMO.

For some background info as to what is actually happening, note these are all fundamental Windows processes and Packer (or any other tool) cannot change what is happening. The variable name seems to indicate that it will run the command under an elevated context, similar to a user logging in with RDP, right clicking "Run as administrator". This is a misnomer as by default all WinRM processes are run under the highest context that is available for a user, so if the user is an administrator, it will run under administrative rights. You can prove this by running on the Windows host in question (change user and password accordingly):

winrs -r:http://127.0.0.1:5985/wsman -u:Administrator -p:Password whoami /groups

The output should look similar to the below

You can see the process has the High Mandatory Level label set which means it is running with administrative rights. A non-admin process has a Medium mandatory level https://msdn.microsoft.com/en-us/library/bb625963.aspx.

What the "elevated" process in Packer does is to run the command under a scheduled task which in the process changes the logon session assigned to the process from the WinRM logon to the new scheduled task logon. The end result of this is the type of logon that is associated with the process session changing from a Network to a Batch logon type. Using the logonsessions tool from SysInternals, here are the types of logons that are associated with each logon;

WinRM with Basic: Network

WinRM with NTLM: Network

WinRM with CredSSP: NetworkCleartext

RDP Logon: RemoteInteractive

Console Logon: Interactive

Scheduled Task with Password: Batch

You can read more about each logon type here http://techgenix.com/logon-types/ but in short, the Windows behaviour changes based on the logon type and can restrict some Windows calls if it isn't allowed. When running under a Network logon, the following is either restricted or does not work as expected;

• Calls to some WUA (Windows Update API) functions will fail as this is restricted under a Network logon. This means anything that uses Windows Updates, be it a program installers or you installing an update, will fail with an access is denied
• Accessing DPAPI (required by some installers like SQL Server) is restricted as a Network logon does not have the user's plaintext credentials available to the logon token
• Access network resources will most likely fail as a Network logon does not have the user's plaintext credentials to present to a network server. Instead a plain authenticated user token is used but unless the ACL's on the share and folder are open to all this will fail

When using CredSSP with WinRM, this changes slightly where the logon type is now NetworkCredentials. This means the user's plaintext credentials are available to be used by the process removing the last 2 restrictions. The WUA restriction is still in place though and cannot be changed with a plain WinRM process. Also I don't believe Packer supports CredSSP authentication so this is just FYI.

To bypass the WUA restriction, Packer has gone the route of using scheduled tasks to run a process under the Batch logon type. This removes the WUA restriction and pretty much gives you access to most (not all) of the functions available in Windows and credentials are available to the process. You may still have a process that requires an Interactive logon type but those are pretty rare and are usually hard to use remotely anyway.

Hopefully that has explained more about this process but ultimately what it boils down to;

• There are restrictions around what you can do in WinRM enforced from Windows
• Most tools use scheduled tasks to bypass these restrictions as it changes the logon type from Network to Batch which is less restricted
• The reason why there are separate variables in Packer is that you can logon with WinRM using one user but run the elevated process with another user
• Technically I don't see why there couldn't just be a flag to elevated the existing WinRM user and just use the credentials already known by Packer but this is a UI decision made by the Packer people
  

Thanks

Jordan