Strata Copilot
    Next-Gen Trust Security
    : Set Up Microsoft AD CS for Issuing and Importing Certificates
    Focus
    Focus
    1. Home
    2. Next‑Gen Trust Security
    3. Next-Gen Trust Security
    4. Next-Gen Trust Security Overview
    5. Overview: Certificate Issuance
    6. Adding a Certificate Authority
    7. Overview: VSatellite Integration with Microsoft AD CS
    8. Set Up Microsoft AD CS for Issuing and Importing Certificates

    Next-Gen Trust Security

    Set Up Microsoft AD CS for Issuing and Importing Certificates

    Table of Contents

    Set Up Microsoft AD CS for Issuing and Importing Certificates

    This guide provides step-by-step instructions for configuring a direct integration between VSatellite and Microsoft Active Directory Certificate Services (AD CS). By connecting directly from VSatellite, you no longer need a separate VSatellite Worker to establish or manage this integration.
    After completing these steps, you’ll be able to import existing certificates and issue new certificates through your AD CS service.

    Prerequisites

    Before you begin, ensure the following baseline requirements are met:
    • Linux server to run VSatellite: See Pre-requisites for installing VSatellites for a list of system and network requirements.
    • AD CS service network access: The VSatellite machine must have direct network access to the Microsoft AD CS service on the following ports:
      • TCP 135
      • TCP 49152–65535
    • AD CS permissions: The account used for authentication must have Read, Issue and Manage Certificates, and Request Certificates permissions on the Microsoft AD CS server.
    • Completed AD CS configuration: Your AD CS service must meet specific configuration requirements.
    • Microsoft AD CS server information:
      • IP or hostname of your Microsoft AD CS server
      • Username and password used to authenticate to Microsoft AD CS
      • Microsoft AD CS Issuing Certificate Common Name
    Note: Additional network access and connectivity requirements apply only if you want VSatellite to authenticate using Kerberos. These requirements are described in the sections below.

    How Authentication Works (Kerberos and NTLM)

    When configuring the integration, VSatellite attempts to authenticate to Microsoft AD CS using Kerberos by default when the environment supports it. Kerberos provides mutual authentication and stronger encryption than NTLM.
    Kerberos authentication is used automatically when all required conditions are met, such as:
    • Using a fully qualified domain name (FQDN) for the AD CS server
    • Supplying domain-qualified credentials
    • Having network connectivity to the Active Directory Domain Controller
    If Kerberos authentication cannot be established—for example, if the Kerberos Key Distribution Center (KDC) is unreachable or a required SPN cannot be resolved—VSatellite automatically falls back to NTLM authentication. No additional configuration is required to enable or manage this fallback behavior.
    If you are satisfied using NTLM authentication, no Kerberos-specific configuration or validation steps are required.

    How Do I Get Started?

    To configure the integration, enter the AD CS connection details directly in the VSatellite interface as described in Step 1 below.
    If you want to use Kerberos authentication (recommended for stronger security), complete the optional Kerberos configuration section before proceeding to Step 1.

    Optional: Configure Kerberos Authentication

    Complete the following requirements and verification steps only if you want to use Kerberos authentication. If you skip this section, VSatellite will use NTLM authentication.

    Kerberos Network and Connectivity Requirements

    • Domain Controller network access: The VSatellite machine must be able to reach the Active Directory Domain Controller using the following ports:
      • TCP 636: LDAPS for SPN discovery (attempted first)
      • TCP 389: LDAP for SPN discovery (fallback)
      • TCP/UDP 88: Kerberos KDC for ticket issuance
    • Credential and address requirements:
      • The AD CS server address must be specified as an FQDN, not an IP address.
      • The username must include a domain qualifier, either:
      • LDAP connectivity must be available from the VSatellite machine to the Domain Controller.

    Step 1: Configure the AD CS Connection in VSatellite

    Once prerequisites are met, configure the integration in the VSatellite interface.
    1. Click New > Microsoft AD CS.
    2. Enter a Name for the Certificate Authority.
      Tip: This is the name that will be used throughout Next-Gen Trust Security for this CA.
    3. Enter the server address: In the AD CS administrative address field, enter the FQDN of your Microsoft AD CS server.
      Note: Using an IP address forces NTLM authentication.
    4. Enter the CA common name: In the Common Name (CN) of the CA’s certificate field, enter the Common Name of the Microsoft AD CS issuing (root) certificate.
    5. Provide credentials: Enter your Username and Password.
      • To enable Kerberos, the username must include a domain qualifier.
      • Passwords must not exceed 128 characters.

    Step 2: Test Credentials

    To verify the configuration, click Test credentials in the VSatellite interface. This test confirms connectivity and authentication with the AD CS server.
    If Kerberos authentication fails during testing—for example, due to an unresolved SPN or an unreachable KDC—VSatellite automatically falls back to NTLM authentication.
    Once the test succeeds, click Next.

    Step 3: Select AD CS Issuance Templates to Map to Next-Gen Trust Security

    Now that the connection is made, we can set up certificate issuance through Next-Gen Trust Security.
    1. Click in the Issuance templates field.
    2. Select the AD CS issuance templates that you want to map to Next-Gen Trust Security.
    3. Click Add.
    Next-Gen Trust Security tests all the templates you selected. Templates with a Passed result are available to map to Certificate Issuing Templates in Next-Gen Trust Security. Those with a Failed result are not.
    Why did some templates fail?
    After adding templates, Next-Gen Trust Security issues test certificates using each of the AD CS issuance templates. Next-Gen Trust Security supports issuance through templates that:
    • Have Server Authentication set in the Application Policies setting of the Extensions tab on the issuance template
    • Allow issuing certificates using RSA keys
    • Supply the Subject Name in the request
    Issuance templates that are incapable of issuing such certificates fail the Next-Gen Trust Security issuance test. This is expected.
    Issuance tests use a static 2048-bit CSR and may fail for templates requiring larger key sizes. You can still issue certificates using those templates.
    1. Click Next.
    On the Statistics tab of your Microsoft AD CS certificate authority, you see a summary of your certificates. Click on any number to open a pre-filtered Certificate Inventory page to see those certificates.

    Step 4: Import Existing Certificates from AD CS

    This step is required only if you want to import existing certificates from AD CS.
    1. Click in the Import templates box.
    2. Select the AD CS templates that you want to import certificates from.
    3. Click Add.
    4. (Optional) Enable AD CS Import and configure the import interval.
    5. Under Import options, select whether to import revoked or expired certificates.
    6. Click Done.
    Next-Gen Trust Security imports the certificates.
    On the Statistics tab of your Microsoft AD CS certificate authority, you see a summary of your certificates. Click on any number to open a pre-filtered Certificate Inventory page to see those certificates.
    Need help? See the Next-Gen Trust Security Troubleshooting guide.

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