OS-specific requirements

Configure a target server so Cloud Management Platform (CMP) can run scripts on it over SSH or WinRM

These requirements apply to the generic execution method. A server that runs scripts through its platform’s own mechanism, such as a VMware server using VMware Tools, does not need them. See Configure remote script method.

*nix servers using SSH

Cloud Management Platform (CMP) copies the script to the server and runs it over SSH. For that to work:

  • The server’s IP address must be routable from the CMP appliance. In public cloud environments, this often means using a public IP address.
  • CMP must know the server’s IP address, usually because CMP provisioned it or the resource handler reports it.
  • TCP port 22 must be open. Test this by opening an SSH session from the CMP appliance to the server.
  • sshd must be installed and running on the server, with password authentication enabled in its configuration if you authenticate by password.
  • The package providing the scp client must be installed on the server: openssh-clients on CentOS and RHEL, openssh-client on Debian and Ubuntu, or the equivalent.

Windows servers using WinRM

On most platforms, running scripts on Windows servers uses WinRM. VMware Windows servers can also be set to use WinRM instead of VMware Tools.

Prerequisites

  • The server’s IP address must be routable from the CMP appliance. In public cloud environments, this often means using a public IP address.
  • CMP must know the server’s IP address, usually because CMP provisioned it or the resource handler reports it.
  • Firewalls and permissions inside the guest must allow WinRM connections.

Configure the Windows guest

  1. In the guest, run gpedit.msc to open the Local Group Policy editor.
  2. Go to Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Client.
  3. Enable Trust the remote machine.
  4. In the settings window, add the CMP appliance name to the TrustedHostsList field.
  5. Under WinRM Client, enable Allow unencrypted traffic.
  6. Under WinRM Service, enable Allow basic authentication and Allow unencrypted traffic.
  7. Open Control Panel > System and Security > Check Firewall Status > Advanced Settings > Inbound Rules, find Windows Remote Management (HTTP-In), open it, and make sure the public profile is enabled on the Advanced tab.
  8. In PowerShell, run Configure-SMRemoting and answer yes to each prompt.
  9. Allow inbound TCP on ports 5985 and 5986. On AWS, add the server to a security group that permits them. On Azure, they are usually open already in the server’s network security group inbound rules.

WinRM encryption

CMP encrypts WinRM traffic by default. The behavior is controlled by the ENCRYPT_WINRM setting, which is True unless you override it in your customer settings file. Setting it to False turns encryption off for every WinRM remote script execution, including the traffic between CMP and any Hyper-V resource handlers.

WinRM with CredSSP

CredSSP provides an encrypted TLS channel and delegates the user’s credentials from the client to the target server, for further remote authentication within a Windows domain. Enable it per server: add the Supports CredSSP parameter to the server and set it to True.

See the Microsoft documentation on CredSSP for background.

WinRM with Kerberos

Kerberos is the native authentication protocol for Windows domains. Used as the WinRM transport, it authenticates against the domain and gives access to the domain resources the account can reach.

The client requests a ticket-granting ticket (TGT) from the Key Distribution Center (KDC). The KDC verifies the credentials and returns an encrypted TGT and session key. The client keeps the TGT until it expires, then requests a new one.

Enable Kerberos on an environment

The Supports Kerberos parameter can be set on a group, an environment, or a blueprint build item. An environment is the most common choice.

  1. Go to Admin > Environments and select an environment.
  2. Open the Parameters tab and select Add.
  3. Select Supports Kerberos and select Add.
  4. In the Options column, select the pencil icon to edit.
  5. Change the value from False to True.

Configure Kerberos on the appliance

Edit the Kerberos client configuration file on the CMP appliance, krb5.conf, and set the realm, KDC, and domain to match your environment. A minimal configuration defines a default realm under libdefaults, the KDC and admin server for that realm under realms, and the mapping from your DNS domain to the realm under domain_realm.

includedir /etc/krb5.conf.d/

[libdefaults]
default_realm = MY.DOMAIN.COM
dns_lookup_realm = false
ticket_lifetime = 5d
renew_lifetime = 7d

[realms]
MY.DOMAIN.COM = {
  kdc = ad-server.my.domain.com
  admin_server = ad-server.my.domain.com
  default_domain = my.domain.com
}

[domain_realm]
.my.domain.com = MY.DOMAIN.COM
my.domain.com = MY.DOMAIN.COM

Replace the realm, server, and domain names with your own.

Ticket lifetime is set in the same file. The example above uses five days, after which a new ticket must be requested.

Initialize a ticket-granting ticket

Use a domain account with access to the resources you need.

  1. In a terminal on the appliance, run kinit followed by your domain account name, which is case-sensitive.
  2. Enter the password. Upon success, you receive a correctly formatted user principal name (UPN), which is all that Kerberos authentication needs thereafter.

Run klist to view the tickets that have been generated.