Create a new Microsoft Windows (PowerShell) machine¶

Before you begin¶

Choose an authentication method. Always use the most secure authentication method available that your organization allows. Methods like Kerberos over HTTPS offer stronger protection with built-in encryption to secure data over the network. Less secure options like Basic Authentication over HTTPS are more vulnerable to credential data exposure because they send username and password data in plaintext over the network if TLS is disabled. Choosing less secure options increases the liklihood of data exposure or interception.

The following list is ordered from most to least secure:

• Kerberos authentication over HTTPS is your best option if the Windows Server is joined to a domain and you already have a trusted TLS Server Certificate installed. Additional steps may be required to bind that certificate to the WinRM HTTPS Listener.
• Kerberos authentication over HTTP is your best option if the Windows Server is joined to a domain and you are not able to bootstrap the windows server with a TLS Server Certificate originally. This requires you to set the WinRM configuration to allow for unencrypted communication.
• Basic authentication over HTTPS is your only option for push installation to a Windows server that is not joined to a domain.

Follow the configuration steps below:

• Ensure that the PowerShell script configured on the Microsoft Windows (PowerShell) machine is managed and written to execute your intended actions, not exhaust system resources, and sign with a trusted certificate on the target system. The script must contain a specific function that would be executed to consume (bind) the certificate from the CAPI store.

  Warning

  You are responsible for managing, writing, and securing your PowerShell script. To minimize exposure and prevent unauthorized access, use a dedicated user account with only the necessary permissions (least privilege) instead of an admin or shared account, as a compromised script with broad access increases security risks. Script signing ensures integrity after deployment but does not gaurantee the security of its source or development environment.

  Refer to the following PowerShell script example:

      ```
      <##################
      .NAME
          bind-certificate
      .DESCRIPTION
          consumes a certificate from the CAPI store, mainly used to bind the certificate to a Windows service
      .PARAMETER certificateStore
          The Windows Certificates store location where the certificate is stored
      .PARAMETER thumbprint
          A text string that represents the public key hash of the certificate
      .NOTES
          A successful script execution returns an exit code 0. If the script fails, it returns a non-zero exit code
          and TLS Protect Cloud would show the error message in the UI
      ##################>
      function bind-certificate( [string]$certificateStore, [string]$thumbprint )
      {
          return "Success"
      }
      ```
  

• Ensure that you know the Windows Remote Management (WinRM) port you plan to use.

• Minimum required credentials on Microsoft Windows (PowerShell): Choose between user credentials or shared credentials. You must have permissions to create, read, and write to the CAPI stores, and to update network certificate configuration on the Microsoft Windows (PowerShell) instance. The easiest way is to use a service account with local or domain admin permissions unless you have a delegated user with the permissions to update CAPI store.
  • User credentials: The username and password you enter.
  • Shared credentials: Optionally, you can use shared credentials from your credential provider (CyberArk is the only credential provider currently supported by TLS Protect Cloud). To use this option, first set up the connection to CyberArk.

• If using Kerberos, you will also need:

  • Domain Name
  • Key distribution center address or hostname
  • Service Principal Name

• Supported Windows versions

  • Windows Server 2019 and 2022