Configure the Targets for IIS Management

On each target machine where you wish to manage the machine certificate store with the Universal Orchestrator Keyfactor orchestrators perform a variety of functions, including managing certificate stores and SSH key stores., you need to grant the Active Directory service account under which the orchestrator is running sufficient permissions to read the local machine certificate store and, if you plan to deploy certificates to it using Keyfactor Command, write to it. This can be accomplished by adding the Universal Orchestrator service account to the local administrators group on each target machine.

The orchestrator uses PowerShell remoting to deliver certificates in 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. format to targets and bind certificates to IIS web sites. This includes certificates delivered directly from the PFX 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 an IIS certificate store in Keyfactor Command, you are given the option to choose whether to secure the channel to the target hosting the IIS 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. 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 IIS 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 PowerShell cmdlet on the Universal Orchestrator to validate that communication can occur between the Universal Orchestrator and the IIS target in the manner you are intending to configure it (SSL or not SSL). For example, for SSL using the default port (where websrvr8.keyexample.com is your IIS target):

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

Output from this command should look something like this if both HTTP and HTTPS are configured for WinRM:

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 = 79 ee 04 7d 67 3d a8 3c ea 87 ba 77 97 61 b0 ec 2b 92 17 f8
   ListeningOn = 192.168.216.42, 127.0.0.1, ::1, fe80::21e1:ab7e:9c35:5550%3