>
    Strata Copilot
    Create a Microsoft IIS Machine
    Focus
    Focus
    1. Home
    2. Next‑Gen Trust Security
    3. Next-Gen Trust Security
    4. Next-Gen Trust Security Overview
    5. Welcome to Installations
    6. About Machines
    7. Create a Microsoft IIS Machine
    Next‑Gen Trust Security

    Create a Microsoft IIS Machine

    Table of Contents

    Create a Microsoft IIS Machine

    Create a Microsoft Internet Information Services (IIS) machine so Next-Gen Trust Security can discover the certificates on a Windows server that runs IIS and provision certificates to it. Next-Gen Trust Security connects to the server through Windows Remote Management (WinRM) from a VSatellite.

    Before You Begin

    • A Superuser role or a custom role with write access to the Machines permission set.
    • An active VSatellite that can reach the Windows server on its WinRM port and, if you use Kerberos authentication, the Key Distribution Center.
    • IIS 10.0 or later on the server, with the WebAdministration PowerShell module. Discovery and provisioning both fail on earlier IIS versions.
    • WinRM turned on for the server. To connect over HTTPS, the server needs a WinRM HTTPS listener with a TLS server certificate.
    • An account that's a member of the local Administrators group on the server. For Kerberos authentication, use an Active Directory domain account. For Basic authentication, use a local account, and turn on Basic authentication for the WinRM service.
    • For Kerberos authentication, the server's Active Directory domain name, the address of a Key Distribution Center (domain controller) for the domain, and the server's WinRM service principal name (SPN).
    The VSatellite must be able to reach the target Windows server on its Windows Remote Management (WinRM) port and, for Kerberos authentication, the Key Distribution Center. A firewall or other network control that blocks these ports causes Test Access and certificate operations to fail.
    PurposeProtocolPortWhen required
    WinRM over HTTPTCP5985When Use TLS for WinRM is disabled. Next-Gen Trust Security uses this port when you leave Windows Remote Management (WinRM) Port empty, even if Use TLS for WinRM is enabled.
    WinRM over HTTPSTCP5986When Use TLS for WinRM is enabled. Next-Gen Trust Security doesn't use this port automatically, so enter it in Windows Remote Management (WinRM) Port.
    KerberosTCP and UDP88When you use Kerberos authentication. The VSatellite connects to the Key Distribution Center (domain controller) that you enter.
    If the server's WinRM listener uses a custom port, open that port instead and enter it in Windows Remote Management (WinRM) Port.

    To Create a Microsoft IIS Machine

    1. Sign in to Next-Gen Trust Security.
    2. Click Insights > Certificate Installations > Machines.
    3. Click New, and then select Microsoft IIS.
    4. On the Properties step, in Name, enter a name for the machine.
    5. (Optional) For Authorized Workspaces, choose the workspaces to share the machine with. Sharing is supported for machines that use credentials you enter directly. To learn what other workspaces can do with a shared machine, see Sharing Makes a Resource Visible Elsewhere.
    6. For VSatellite, choose a VSatellite that can reach the machine. The list shows each VSatellite with the number of its active replicas.
    7. For Authentication Type, choose Basic Authentication or Kerberos Authentication. To compare them, see "Authentication Options" later on this page.
    8. In Microsoft IIS Hostname, enter the hostname, fully qualified domain name (FQDN), or IP address of the Windows server.
    9. (Optional) In Windows Remote Management (WinRM) Port, enter the port of the server's WinRM listener. If you leave it empty, Next-Gen Trust Security uses 5985, the default HTTP port. If you enable Use TLS for WinRM, enter the HTTPS listener port, which is usually 5986.
    10. (Optional) To connect to the server over HTTPS, enable Use TLS for WinRM.
      Note: Next-Gen Trust Security doesn't verify the TLS certificate of the server's WinRM listener. The connection is still encrypted.
    11. If you chose Kerberos Authentication, under Kerberos Details, in Domain Name, enter the Active Directory domain name of the server, for example, example.com.
    12. If you chose Kerberos Authentication, in Key Distribution Center Address/Hostname, enter the hostname or IP address of a domain controller for the domain.
    13. If you chose Kerberos Authentication, in Service Principal Name, enter the server's WinRM SPN in the format WSMAN/<fqdn>, for example, WSMAN/server.example.com.
    14. For Credential Type, choose how to provide the credentials:
      • Enter Credentials to enter the credentials in the next step. This is the default.
      • Select Credentials to use credentials stored in a credential manager integration. Then, for Credential, choose the credential.
      Note: Select Credentials requires a configured credential manager integration. Credential manager integrations require additional licensing.
      Important: Your view of credentials depends on the workspace you have selected. Under Tenant you can select any credential in the tenant. Inside a workspace you can select only that workspace's credentials.
    15. If you chose Enter Credentials, enter the Username and Password of the Windows account. For Kerberos authentication, enter the username without the domain. If you chose Select Credentials, the stored account needs the same access on the server.
      Non-ASCII characters aren't supported in the username or password.
      Note: Next-Gen Trust Security encrypts the credentials you enter and doesn't display them again. On the machine's Properties tab, they appear masked. To keep a stored credential when you edit the machine, leave its masked value unchanged. Keep your own secure record of the credentials in case you need them again.
    16. Click Test Access. After the connection succeeds, click Continue. The Discovery step opens.
      Note: A successful test confirms that Next-Gen Trust Security can reach the server's WinRM listener, sign in, and run a command. It doesn't check the IIS version or the WebAdministration module.
    17. (Optional) Choose the certificate stores to discover: Both Personal and Web Hosting, Personal, or Web Hosting. Discovery searches the stores under the server's local computer account and finds the IIS web site bindings that use each certificate. If you don't choose, discovery searches both stores.
    18. (Optional) To skip certificates that have already expired, enable Exclude expired certificates.
    19. (Optional) To skip certificates that no IIS web site binding uses, enable Exclude inactive certificates.
    20. (Optional) To discover certificates on a schedule, enable Schedule. For Repeat every, choose Day, Week, or Month, and then in At, enter the time. For Week, select the days of the week. For Month, enter the days in Day of month. Times are in Coordinated Universal Time (UTC).
    21. Click Continue. The Provisioning step opens.
    22. (Optional) To provision certificates on a schedule, enable Schedule. For Repeat every, choose Day, Week, or Month, and then in At, enter the time. For Week, select the days of the week. For Month, enter the days in Day of month. Times are in Coordinated Universal Time (UTC).
      Scheduled provisioning pushes only certificates that are queued for deployment, such as renewed certificates, so renewals install during the window you choose.
    23. Click Finish.

    Authentication Options

    How Next-Gen Trust Security protects the WinRM connection depends on the Authentication Type you choose and on whether you enable Use TLS for WinRM.
    • Kerberos Authentication over HTTP: Next-Gen Trust Security encrypts all WinRM traffic with Kerberos message encryption, whatever the server's WinRM AllowUnencrypted setting, so you can keep AllowUnencrypted at false. Message encryption supports the AES encryption types aes256-cts-hmac-sha1-96 and aes128-cts-hmac-sha1-96, and it refuses RC4 and DES. If authentication fails because of the encryption type, make sure the domain issues AES tickets for the account.
    • Kerberos Authentication over HTTPS: TLS encrypts the traffic. Next-Gen Trust Security sends a Kerberos channel binding token, so you can keep the WinRM CbtHardeningLevel setting at Strict.
    • Basic Authentication over HTTPS: TLS encrypts the traffic, including the username and password.
    Warning: Use Basic Authentication only with Use TLS for WinRM enabled. Without TLS, the username and password cross the network unencrypted.

    What's Next?

    After you create the machine, provision a certificate to it. You can also run discovery on the machine at any time to track the certificates on the server.

    © 2026 Palo Alto Networks, Inc. All rights reserved.