Home > Blogs > VMware Consulting Blog > Tag Archives: vRO

Tag Archives: vRO

vRO Architecture Considerations When Digitally Signing Packages

Spas KaloferovBy Spas Kaloferov

In this blog post we will take a look at how digitally signing packages in VMware vRealize® Orchestrator™ (vRO) may affect the way you deploy vRO in your environment.

In some use cases, digitally signing workflow packages may affect your vRO architecture and deployment. Let’s consider a few examples.

Use Case 1 (Single Digital Signature Issuer)

Let’s say you have vRO ServerA and vRO ServerB in your environment. You’ve performed the steps outlined in How to Change the Package Signing Certificate of a vRO Appliance (SKKB1029) to change the PSC on vRO ServerA , export the keystore, and import it on vRO ServerB. This will allow the following:

  • vRO ServerA can digitally sign workflow packages, and vRO ServerB can read packages digitally signed by vRO ServerA.
  • vRO ServerB can digitally sign workflow packages, and vRO ServerA can read packages digitally signed by vRO ServerB.

Now what happens when you add vRO ServerC?

Continue reading

Securing Your PowerShell Execution and Password in VMware vRealize Orchestrator

Spas Kaloferovby Spas Kaloferov

In this blog post we will look at how to secure your end-to-end PowerShell Execution from VMware vRealize® Orchestrator™ (vRO)—including how not to show passwords when using the Credential Security Support Provider (CredSSP) protocol in a double-hop authentication scenario.

Let’s look at a few common use cases regarding the configuration of vRO, the PowerShell host, the Windows Remote Management (WinRM) protocol, and the PowerShell script/command, and how we can best secure all of them.

Web Services (WS)-Management encrypts all traffic by default, and this is controlled by the AllowUnencrypted client and server WinRM configuration parameter—even if you only work with HTTP (the default configuration) and not with HTTPS. Prior to Windows Server 2003 R2, WinRM in an HTTP session was not encrypted.

Continue reading

Mini Post; How to Change the Package Signing Certificate of a vRO Appliance for update

Spas Kaloferov


By Spas Kaloferov

Importing Digitally Signed Packages to a Different Destination vRO (vRealize Orchestrator) Server

What we did in the previous changer was to change the PSC certificate on a vRO server to match our company requirements. The certificate will be used to digitally sign packages we export from vRO.

If you will import digitally signed workflow packages only to their original vRO, no further steps are required.

If you will import digitally signed workflow packages to a different vRO, additional configuration steps are required on the destination vRO. Continue reading

How to Change the Package Signing Certificate of a vRealize Orchestrator Appliance (7.0.1)

 

By Spas Kaloferov

In this post, we will take a look at how to change the Package Signing Certificate (PSC) in a vRealize Orchestrator appliance.

To change the PSC, let’s review a few steps first:

ŸIssue a certificate to meet the company’s requirements. The certificate must have:

  • ŸDigital Signature and Key Encipherment Key Usage attributes
  • ŸServer Authentication Extended Key Usage attribute
  • ŸAssurance that the certificate has a private key

ŸUse the keytool to:

  • ŸCreate new keystore; the keystore type must be JCEKS.
  • ŸImport the certificate into the keystore.
  • ŸChange the alias of the certificate to _dunesrsa_alias_.
  • ŸGenerate a Security Key and place it in the keystore.
  • ŸChange the alias of the Security Key to _dunessk_alias_.

ŸUse the Control Center interface to:

  • Ÿ Import the keystore you created.
  • Ÿ Restart the Orchestrator server.

Here is a screenshot of the original PSC certificate:

SKaloferov_PSC Certificate

Changing the Package Signing Certificate

First, you must obtain a PFX Certificate Package (containing your PSC Certificate) issued from the Certificate Authority (CA).

SKaloferov_Package Signing Certificate

SKaloferov_Package Signing Certificate 2

SKaloferov_Certificate Path

Note that the certificate has the Digital Signature and Key_Encipherment Key Usage attributes as shown above. It also has the Server Authentication Extended Key Usage attribute.

Copy the PFX certificate package to any Linux appliance.

SKaloferov_Certificate Signing vRO

Using the OpenSSL tool, enter the following commands to create a new keystore and import the PFX certificate package at the same time.

keytool -importkeystore -srckeystore "/etc/vco/app-server/security/rui.pfx" -srcstoretype pkcs12 -srcstorepass "dunesdunes" -deststoretype jceks -destkeystore "/etc/vco/app-server/security/psckeystore" -deststorepass "dunesdunes"

SKaloferov_PFX Certificate

Enter the following command to change the alias of the certificate:

keytool -changealias -alias rui -destalias _dunesrsa_alias_ -keystore "/etc/vco/app-server/security/psckeystore" -storetype jceks -storepass "dunesdunes"

Next, enter this command to generate a security key:

keytool -genseckey -alias _dunessk_alias_ -keyalg DES -keysize 56 -keypass "dunesdunes" -storetype jceks -keystore "/etc/vco/app-server/security/psckeystore" -storepass "dunesdunes"

Notice I’ve used the DES algorithm and 56 key size in the above command, but you can also use the 3DES (DESese) algorithm and 168 key size.

Enter the following command to list the contents of the store.

keytool -list -storetype jceks -keystore "/etc/vco/app-server/security/psckeystore"

Copy the keystore file to your Windows machine.

Open Control Center and navigate to Certificates > Package Signing Certificate.

Click Import > Import from JavaKeyStore file.

Browse the keystore file, and enter the password.

SKaloferov_Current Certificate

Click Import to import the certificate.

Go to Startup Options and restart the Orchestrator service.

Navigate back to Certificates > Package Signing Certificate.

You should now see the new certificate.

SKaloferov_New Certificate

Open your vRealize Orchestrator appliance client, and navigate to Tools > Certificate Manager.

SKaloferov_vRO

You should now see the certificate shown below. The common name can differ, but if you compare the thumbprints, it should match the private key entry in your keystore.

SKaloferov_Keystore

I hope this post was valuable in helping you learn how to change the Package Signing Certificate in a vRealize Orchestrator appliance. Stay tuned for my next post!


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

Troubleshooting Tips: Orchestrator PowerShell Plug-in

By Spas Kaloferov

Background and General Considerations

In this post will we will take a look at some common issues one might experience when using the VMware vRealize Orchestrator (vRO) PowerShell Plug-In, especially when using HTTPS protocol or Kerberos authentication for the PowerShell Host (PSHost).

Most use cases require that the PowerShell script run with some kind of administrator-level permissions in the target system that vRO integrates with. Here are some of them:

  • Add, modify, or remove DNS records for virtual machines.
  • Register IP address for a virtual machine in an IP management system.
  • Create, modify, or remove a user account mailbox.
  • Execute remote PowerShell commands against multiple Microsoft Windows operating systems in the environment.
  • Run a PowerShell script (.ps1) file from within a PowerShell script file from vRO.
  • Access mapped network drives from vRO.
  • Interact with Windows operating systems that have User Access Control (UAC) enabled.
  • Execute PowerCLI commands.
  • Integrate with Azure.

When you add a PowerShell Host, you must specify a user account. That account will be used to execute all PowerShell scripts from vRO. In most use cases, like the one above, that account must be an administrator account in the corresponding target system the script interacts with. In most cases, this is a domain-level account.

In order to successfully add the PowerShell Host to that account—and use that account when executing scripts from vRO—some prerequisites need to be met. In addition, the use cases mentioned require the PowerShell Host to be prepared for credential delegation (AKA Credential Security Service Provider [CredSSP], double-hop authentication or multi-hop authentication).

To satisfy the above use cases for adding a PowerShell Host in vRO:

The high-level requirements are:

  • Port: 5986
  • PowerShell remote host type: WinRM
  • Transport protocol: HTTPS (recommended)
  • Authentication: Kerberos
  • User name: <Administrator_user_name>

The low-level requirements are:

  • PSHost: Configure WinRM and user token delegation
  • PSHost: Configure Windows service principal names (SPNs) for WinRM
  • PSHost: Import a CA signed-server certificate containing Client Authentication and Server authentication Exchange Key Usage Properties
  • PSHost: Configure Windows Credential Delegation using the Credential Security Service Provider (CredSSP) module
  • vRO: Edit the Kerberos Domain Realm (krb5.conf) on the vCO Appliance (Optional/Scenario specific)
  • vRO: Add the PS Host as HTTPS host with Kerberos authentication
  • vRO: Use the Invoke-Command cmdlet in your PowerShell code

Troubleshooting Issues when Adding a PSHost

To resolve most common issues when adding a PSHost for use with HTTPS transport protocol and Kerberos authentication, follow these steps:

  1. Prepare the Windows PSHost.

For more information on all the configurations needed on the PSHost, visit my blog, “Using CredSSP with the vCO PowerShell Plug-in.”

  1. After preparing the PSHost, test it to make sure it accepts the execution or removes PowerShell commands.

Start by testing simple commands. I like to use the $env:computername PowerShell command that returns the hostname of the PSHost. You can use the winrs command in Windows for the test. Here’s an example of the syntax:

winrs -r:https://lan1dc1.vmware.com:5986 -u:vmware\administrator -p:VMware1! powershell.exe $env:computername

 

Continue by testing a command that requires credential delegation. I like to use a simple command, like dir \\<Server_FQDN\<sharename>, that accesses a share residing on a computer other than the PSHost itself. Here’s an example of the syntax:

winrs -r:https://lan1dc1.vmware.com:5986 -ad -u:vmware\administrator -p:VMware1! powershell.exe dir \\lan1dm1.vmware.com\share


Note
: Make sure to specify the –ad command line switch.

  1. Prepare the vRO so it can handle Kerberos authentication. You need this in order to use a domain-level account when adding the PSHost.

For more information about the Kerberos configuration on vRO for single domain, visit my blog, “Using CredSSP with the vCO PowerShell Plugin.”

If you are planning to add multiple PSHosts and are using domain-level accounts for each PSHost that are from different domains (e.g., vmware.com and support.vmware.com) you need to take this into consideration when preparing vRO for Kerberos authentication.

For more information about the Kerberos configuration on vRO for multiple domains, visit my blog, “How to add PowerShell hosts from multiple domains with Kerberos authentication to the same vRO.”

If you make a mistake in the configuration, you might see the following error then adding the PSHost:

Cannot locate default realm (Dynamic Script Module name : addPowerShellHost#12
tem: ‘Add a PowerShell host/item8′, state: ‘failed’, business state: ‘Error’, exception: ‘InternalError: java.net.ConnectException: Connection refused (Workflow:Import a certificate from URL with certificate alias / Validate (item1)#5)’
workflow: ‘Add a PowerShell

 

If this is the case, go back and re-validate the configurations.

  1. If the error persists, make sure the conf file is correctly formatted.

For more information about common formatting mistakes, visit my blog, “Wrong encoding or formatting of Linux configuration files can cause problems in VMware Appliances.”

  1. Make sure you use the following parameters when adding the PSHost:
    • Port: 5986
    • PowerShell remote host type: WinRM
    • Transport protocol: HTTPS (recommended)
    • Authentication: Kerberos
    • User name: <Administrator_user_name>

Note: In order to add the PSHost, the user must be a local administrator on the PSHost.

  1. If you still cannot add the host, make sure your VMware appliance can authenticate successfully using Kerberos against the domains you’ve configured. To do this you can use the ldapsearch command and test Kerberos connectivity to the domain.

Here is an example of the syntax:

vco-a-01:/opt/vmware/bin # ldapsearch -h lan1dc1.vmware.com -D “CN=Administrator,CN=Users,DC=vmware,DC=com” -w VMware1! -b “” -s base “objectclass=*”
  1. If your authentication problems continue, most likely there is a general authentication problem that might not be directly connected to the vRO appliance, such as:
    • A network related issue
    • Blocked firewall ports
    • DNS resolution problems
    • Unresponsive domain controllers

Troubleshooting Issues when Executing Scripts

Once you’ve successfully added the PSHost, it’s time to test PowerShell execution from the vRO.

To resolve the most common issues when executing PowerShell scripts from vRO, follow these steps:

  1. While in vRO go to the Inventory tab and make sure you don’t see the word “unusable” in front of the PSHost name. If you do, remove the PSHost and add it to the vRO again.
  1. Use the Invoke an external script workflow that is shipped with vRO to test PowerShell execution commands. Again, start with a simple command, like $env:computername.

Then, process with a command that requires credential delegation. Again, as before, you can use a command like dir \\<Server_FQDN\<sharename>.

Note: This command doesn’t support credential delegation, so a slight workaround is needed to achieve this functionality. You need to wrap the command you want to execute around an Invoke-Command command.

For more information on how to achieve credential delegation from vRO, visit my blog, “Using CredSSP with the vCO PowerShell Plug-in.”

If you try to execute a command that requires credential delegation without using a workaround, you will receive an error similar to the following:

PowerShellInvocationError: Errors found while executing script <script>: Access is denied


SKaloferov_Power Shell Error

  1. Use the SilentlyContinue PowerShell error action preference to suppress output from “noisy” commands. Such commands are those that generate some kind of non-standard output, like:
    • Progress par showing the progress of the command execution
    • Hashes and other similar content

Finally, avoid using code in your commands or scripts that might generate popup messages, open other windows, or open other graphical user interfaces.


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.