Configure Windows Targets for Remote Management

On each target machine where you wish to manage certificate stores with the Universal Orchestrator, you need to grant the Active Directory or local service account the orchestrator is using to authenticate to the server sufficient permissions to read the directories where the certificate stores are located (for the Remote File extension) or local machine certificate store (for the IIS extension) and, if you plan to deploy certificates to it using Keyfactor Command and bind certificates to IIS, write to the directories (Remote File) and local machine store (IIS) and appropriate permissions to bind certificates in IIS. For the Remote File extension, granting read/write permissions on the given directories may be sufficient. For IIS, the Universal Orchestrator service account needs to be added to the local administrators group on each target machine.

The orchestrator uses PowerShell remoting to deliver certificates to targets and bind certificates to IIS web sites. This includes certificates delivered directly from the PFX A PFX file (personal information exchange format), also known as a PKCS#12 archive, is a single, password-protected certificate archive that contains both the public and matching private key and, optionally, the certificate chain. It is a common format for Windows servers. enrollment Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA). option of the Keyfactor Command Management Portal or Keyfactor API A set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command. to targets. If you wish to use any of these features, you will need to make sure that each target machine on which you want to use one of these features is running at least PowerShell version 3 and that PowerShell remoting has been enabled. To check the PowerShell version on a given machine, open a PowerShell window, run the following command, and check the output CLRVersion:

PowerShell version 3 is available for download from Microsoft.

To enable PowerShell remoting:

1. On the target machine, open a PowerShell window using the “Run as administrator” option.
2. On the target machine, run the following command to enable PowerShell remoting:
   Enable-PSRemoting

   Respond Yes to all the question prompts (or A for all).

3. On the target machine it may be necessary to run the following command to enable execution of unsigned local PowerShell scripts for some operating systems (e.g. Windows Server 2008 R2):
   Set-ExecutionPolicy RemoteSigned

4. To test the PowerShell remoting, on the Universal Orchestrator server, open a PowerShell window and run the following command (where TARGET_MACHINE is the FQDN of the target machine you wish to manage with the orchestrator):
   Enter-PSSession –ComputerName TARGET_MACHINE

   Use the actual hostname The unique identifier that serves as name of a computer. It is sometimes presented as a fully qualified domain name (e.g. servername.keyexample.com) and sometimes just as a short name (e.g. servername). of the target machine rather than a DNS The Domain Name System is a service that translates names into IP addresses. alias (either A or CNAME records) when running this test. This is necessary because PowerShell remoting relies on Kerberos authentication, which requires that the target machine has a service principal name (SPN) in the HTTP/ format assigned to the target’s machine account. This will be present by default (as part of the HOST/ format record) as long as the HTTP/ format SPN has not been manually assigned elsewhere. Using an alias gets into complexities of setting up appropriate SPNs and assuring that there are not duplicate SPNs in the environment.

   You should be connected to the target machine and be able to execute PowerShell commands on the target machine.

When you add a certificate store in Keyfactor Command using an extension from Keyfactor‘s GitHub that relies on WinRM, you are given the option to choose whether to secure the channel to the target hosting the certificate store with SSL TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers.. If you select True, Microsoft Windows Remote Management (WinRM) on the target needs to be running on HTTPS and to have been configured with a certificate for WinRM. If you select False, WinRM on the target needs to be running on HTTP. By default, WinRM HTTP uses port 5985 and WinRM HTTPS uses port 5986. WinRM HTTPS is not enabled out-of-the box.

Make sure that any firewalls between the Universal Orchestrator, Keyfactor Command, and the remote target allow communications over port TCP 5985 or 5986, depending on your SSL selection, or the alternate port you've configured for WinRM on the target if you're not using the default WinRM port(s).

You can use the Test-WSMan and Test-netConnection PowerShell cmdlets on the Universal Orchestrator to validate that communication can occur between the Universal Orchestrator and the remote target in the manner you are intending to configure it (SSL or not SSL). For example, for SSL using the default port (where websrvr38.keyexample.com is your remote target):

Output from this command should look something like this if the connection completes successfully:

ComputerName     : websrvr38.keyexample.com
RemoteAddress    : 192.168.216.38
RemotePort       : 5986
InterfaceAlias   : Ethernet0
SourceAddress    : 192.168.216.42
TcpTestSucceeded : True

And:

Output from this command should look something like this if the connection completes successfully:

wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0

On the remote target, you can use the following WinRM command to check the configuration of WinRM , whether it has been configured to support HTTPS, whether it has a certificate configured for HTTPS, and the ports in use:

Output from this command should look something like this if both HTTP and HTTPS are configured for WinRM (notice the port for HTTPS and the certificate thumbprint indicating a certificate has been configured for WinRM on HTTPS):

Listener
   Address = *
   Transport = HTTP
   Port = 5985
   Hostname
   Enabled = true
   URLPrefix = wsman
   CertificateThumbprint
   ListeningOn = 192.168.216.42, 127.0.0.1, ::1, fe80::21e1:ab7e:9c35:5550%3

Listener
   Address = *
   Transport = HTTPS
   Port = 5986
   Hostname = websrvr42.keyexample.com
   Enabled = true
   URLPrefix = wsman
   CertificateThumbprint = 79ee047d673da83cea87ba779761b0ec2b9217f8
   ListeningOn = 192.168.216.42, 127.0.0.1, ::1, fe80::21e1:ab7e:9c35:5550%3

For troubleshooting help, see Remote Management Helpful Tools. For more information about configuring WinRM for HTTPS, see: