Introducing the Add CredSSP to a PowerShell script (vROCmdlet) workflow (SKKB1015)

Introduction

In this post we will take a look into a vROC that can help overcome CredSSP limitations introduced with the VMWare vRealize Orchestrator Plug-in for Microsoft Windows PowerShell. It give you an option to change credentials during command execution so that you can execute one PowerShell command with higher privileged user account and another with lower privileged user account. Currently all PowerShell commands are being run under the account which has been used to add the PowerShell Host. This has always been a concern among Security Administrators. By using this vROC you will no longer have to hardcode credentials in scripts that you call from vRO.
If you are new to what a vROC is, visit:
Let’s vROC with vRO!

If you are interested how to set up a Windows Powershell Host and vRO for CredSSP, visit:
Using CredSSP with the vCO PowerShell Plugin

 

Lab Environment

The following environment has been used in all of the examples below:

  • Active Directory Domain called vmware.com
  • Windows Server 2012 R2 (with FQDN lan1dc1.vmware.com)
    • Domain Controller
    • DNS Server.
    • PowerShell v4 Host.
    • .NET 4 Framework installed (4.0.30319)
  • Windows Server 2012 R2 (with FQDN lan2dc1.support.vmware.com)
    • Domain Controller
    • DNS Server.
    • PowerShell v4 Host.
    • .NET 4 Framework installed (4.0.30319)
  • Windows Server 2008 R2 SP1 (with FQDN lan1dm1.vmware.com)
    • Domain Member
    • PowerShell v3 Host.
    • .NET 4 Framework installed (4.0.30319)
  • vCO 5.5.1.0 Virtual Appliance (with FQDN vco-a-01.vmware.com)
    • vCO PowerShell Plugin installed (version 1.0.6.2283945)

The full lab logical design can be seen HERE.

 

Getting the vROC workflow

The workflow package can be downloaded here:
Once installed the [Add CredSSP to a Powershell script (vROCmdlet)] vROC can be found in the [WS-Management (WS-Man) and Windows Remote Management (WinRM)] library.

After install search for vROC in the vRO elements.

Examining the tabs

The following presentation tabs are shared across all vROC’s:

  • Settings
  • Connection
  • Input
  • Output
  • Execution

Examining the Settings Presentation Tab

On the Settings tab you specify the Windows PowerShell cmdlet command and the arguments with which it should be executed.
For example if you want to get the DNS Server Settings you will specify:

Examining the Connection Presentation Tab

On the Connection you specify the Window Powershell host (via the PShost input) and if CredSSP should take place (via the chooseRemoteComputer input)
Lets examine these inputs with more detail to see how these can control our execution path.

 

Use Case 1: Execute PowerShell command locally on the PShost against the PSHost itself

Let’s say you have specified the Connection tab inputs as follows:

  • PSHost = <your_Powershell_host>.( in this example: lan1dc1.vmware.com)
  • chooseRemoteComputer = No (false)

 

The PSHost input specifies your PowerShell host where the command will be executed.
The chooseRemoteComputer input specifies if CredSSP should be used.
This will execute the command specified on the Settings tab directly on the PShost without any windows credential delegation (CredSSP) taking place. The credentials with which the PSHost has been added in vRO will be used to execute the command.

Final command will look like something like this 

lan1dc1.vmware.com (PSHost)  :\> get-DNSClientSetting

In this case the execution path looks like this:

  • vRO Call: vRO makes a call to the PSHost
  • Cmdlet Exec: PSHost executes the command locally.
  • Cmdlet Resp: PSHost receives the execution response
  • vRO Resp: PSHost sends the execution response back to vRO

CredSSP required on:

  • none

Use Case 2: Invoke PowerShell command locally on the PSHost against remote computer

Let’s say you have specified the Connection tab inputs as follows:

  • PSHost = <your_Powershell_host>( in this example: lan1dc1.vmware.com)
  • chooseRemoteComputer = Yes (true)
  • chooseRemoteUsername = <Username to be used for the command execution>.
  • chooseRemotePassword = <Password to be used for the command execution>
  • InvokeCommandHost = localhost
  • cimSession = <empty>
  • computerName = Computer where the command will be executed.

 


The remoteComputerUsername and remoteComputerPassword inputs specify the credential set under which the command will be invoked.
The invokeCommandHost input specifies where (on which server) the command will be invoked. In this case we have selected value of localhost. This will invoke the command on the PSHost itself and will supply during the invoke credential under which the command will be executed.
The computerName input specifies the computer against which the command will be run. This is the equivalent of the –ComputerName Powershell cmdlet switch.

This will invoke the command specified on the Settings tab directly on the PShost . CredSSP will take place on the PSHost and the command will be executed on the PSHost agains the computer specified in the computerName input parameter.

Final command will look like something like this 

vRO > lan1dc1.vmware.com (PSHost)  :\> get-DNSClientSetting –ComputerName lan1dm2.vmware.com

In this case the execution path looks like this:

  • vRO Call: vRO makes a call to the PSHost
  • Cmdlet Exec: PSHost invokes the command locally and supplies credential set.
  • WinRM Call: PSHost makes a WInRM call to the remote computer to execute the command.
  • WinRM Resp: Remote computer sends WinRM Response.
  • Cmdlet Resp: PSHost receives the WInRM response
  • vRO Resp: PSHost sends the execution response back to vRO

CredSSP required on:

  • ServerA

Use Case 3: Invoke PowerShell command on remote computer and execute locally.

Let’s say you have specified the Connection tab inputs as follows:

  • PSHost = <your_Powershell_host>( in this example: lan1dc1.vmware.com)
  • chooseRemoteComputer = Yes (true)
  • chooseRemoteUsername = <Username to be used for the command execution>.
  • chooseRemotePassword = <Password to be used for the command execution>
  • InvokeCommandHost = custom
  • InvokeCommandHostCustom = Computer where the command will be invoked. In this example lan1dm2.vmware.com
  • cimSession = <empty>
  • computerName = <empty>

This time for the invokeCommandHost input we have selected value custom.
The invokeCOmmandHostCustom specifies on which host the command will be invoked.
Note that the computerName in this use case is empty.

This will invoke the command specified on the Settings tab on the server specified in the invokeCommandHostCustom input. CredSSP will take place on that server and the command will be executed localy on that server, because we haven’t specified the computerName input.

Final command will look like something like this 

vRO > lan1dc1.vmware.com (PSHost) > lan1dm2.vmware.com (InvokeCommandHostCustom)  :\> get-DNSClientSetting

In this case the execution path looks like this:

  • vRO Call: vRO makes a call to the PSHost
  • Invoke Call: PSHost invokes the command on the computer specified in invokeCommandHostCustom input.
  • Cmdlet Exec: The command get executed on the computer specified in the invokeCommandHostCustom input.
  • Cmdlet Resp: The computer specified in the invokeCommandHostCustom input retrieves back the execution response.
  • Invoke Resp: The computer specified in the invokeCommandHostCustom sends back the Invoke response to the PSHost.
  • vRO Resp: PSHost sends the execution response back to vRO

CredSSP required on:

  • ServerA

Use Case 4: Invoke PowerShell command on remote computer and execute remotely.

Let’s say you have specified the Connection tab inputs as follows:

  • PSHost = <your_Powershell_host>( in this example: lan1dc1.vmware.com)
  • chooseRemoteComputer = Yes (true)
  • chooseRemoteUsername = <Username to be used for the command execution>.
  • chooseRemotePassword = <Password to be used for the command execution>
  • InvokeCommandHost = custom
  • InvokeCommandHostCustom = Computer where the command will be invoked. In this example lan1dm2.vmware.com
  • cimSession = <empty>
  • computerName = Computer where the command will be executed. In this example lan2dc1.support.vmware.com

In this use case in addition to the settings defined in the previous one, we have added value for the computerName input parameter.
This will invoke the command specified on the Settings tab on the server specified in the invokeCommandHostCustom input. Command will be executed agains the computer specified in the ComputerName input . CredSSP will take place on the that computers specified in the invokeCommandHostCustom  and computerName inputs.

Final command will look like something like this 

vRO > lan1dc1.vmware.com (PSHost) > lan1dm2.vmware.com (InvokeCommandHostCustom)  :\> get-DNSClientSetting –ComputerName lan2dc1.support.vmware.com

In this case the execution path looks like this:

  • vRO Call: vRO makes a call to the PSHost
  • Invoke Call: PSHost invokes the command on the computer specified in invokeCommandHostCustom input.
  • Cmdlet Exec: The command get executed on the computer specified in the invokeCommandHostCustom input.
  • WInRM Call: Command execution makes WinRM Call to the computer specified in the cmoputerName input.
  • WinRM Resp: the computer specified in the computerName sends back WinRM Resp to the computer specified in the invokeCommandHostCustom input.
  • Cmdlet Resp: The computer specified in the invokeCommandHostCustom input retrieves back the execution response.
  • Invoke Resp: The computer specified in the invokeCommandHostCustom sends back the Invoke response to the PSHost.
  • vRO Resp: PSHost sends the execution response back to vRO

CredSSP required on:

  • ServerA
  • ServerB

Examining the Input Presentation Tab

The settings on the Input presentation specify the input settings for the PowerShell cmdlet that is going to be executed.
There are 3 ways you can use to input (pipe) content to the command that is going to be executed.

  • inputObjectPipeManual – Manually specify the PowerShell command that will generate input
  • inputObjectPipeWorkflow – Specifies that the input will be provided by another vROC workflow.
  • inputObjectPipeCim – Specifies  that the input will be provided by a CIM Session.

Let’s say you have specified the Settings tab inputs as follows:

  • cmdlet = Set-DNSServerSettings

Let’s say you have specified the Input tab inputs as follows:

  • chooseInputObject = Yes (true)
  • InputObject = inputObjectPipeManual
  • inputObjectPipeManual = Get-DNSServerSetting

This will result in the following command being executed:

PS:\> Get-DNSServerSetting | Set-DNSServerSetting

This is an example of how the vROC workflow can be used to manually pipe PowerShell input.
If you are using this vROC workflow within another workflow and you want to pipe the input object, then select value of InputObjectPipeWorkflow for the InputObject input.

You can find example workflows documenting how powershell can be piped between different vROC’s in the library under [WS-Management (WS-Man) and Windows Remote Management (WinRM)]. The example workflows are called [Piped vROCmdlet execution]

Examining the Output Presentation Tab

The settings on the Output presentation specify  common PowerShell cmdlet switches like –Force or –Confirm should be used when executing the command. This switches are useful, for commands that support them, to avoid showing confirmation prompts during execution which in term can lead to vRO workflow failure.


On other swith that requires attention is the –PassThru siwth. Selecting this for commands that support it will result in passing the powrehsell object for validation by the Add CredSSP to a Powershell script vROC workflow
Output workflow parameters that are affected by the existence of the PowerShell object are:

  • outpuPS – Specifies the Powershell object for output.
  • outputBoolen – Specifies if the output Powershell object exists.



These outputs can be used for workflow execution validation purposes.
The other two output the vROC’s generate are:

  • outputPSCmd – Specifies the Powershell command for output.
  • outputSessionid – Specifies the Winrm session id .

Examining the Execution Presentation Tab

The settings on the Execution presentation specify if the vROC is being executed as standalone vROC or as part of another workflow.
The executionMode input accepts the following values:

  • Execute – Specify this value if you are NOT calling this workflow from another workflow and want only to execute it.
  • Pipe – Specify this value if you are calling this workflow from another workflow and want only to pipe the output without executing it.

If you select PIPE, you must select NO for the chooseRemoteComputer input parameter on the Connection tab . Even if you don’t select it CredSSP will be ignored in PIPE mode

 

DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.

Leave a Reply

Your email address will not be published. Required fields are marked *