Skip to content

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:
    • UPN format: user@DOMAIN.COM
    • Down-level format: DOMAIN\user
  • LDAP connectivity must be available from the VSatellite machine to the Domain Controller.

Before configuring credentials in VSatellite, you can verify that LDAP connectivity from the VSatellite machine is working as expected. These checks help confirm that Kerberos authentication can succeed.

If you skip this step or the tests fail, VSatellite will use NTLM authentication instead.

1. Run a Port Reachability Check

From the VSatellite machine, verify that required ports are reachable (no credentials required):

  • Test LDAPS: nc -zv <DOMAIN_CONTROLLER> 636 -w 5
  • Test LDAP: nc -zv <DOMAIN_CONTROLLER> 389 -w 5

2. Run a Full LDAP Query Test (Optional)

Run an LDAP query that replicates the SPN discovery performed by VSatellite. You can use either LDAPS or LDAP.

LDAPS (port 636):

ldapsearch -H ldaps://${DOMAIN}:636 \
  -x \
  -D "${USERNAME}" \
  -w "${PASSWORD}" \
  -b "DC=${DOMAIN_PART1},DC=${DOMAIN_PART2}" \
  "(&(objectClass=computer)((cn=${SHORT_NAME})(dNSHostName=${FQDN})))" \
  servicePrincipalName

Replace the variables with values from your environment, for example:

  • ${DOMAIN} = example.com
  • ${USERNAME} = user@example.com
  • ${SHORT_NAME} = AD CS server short hostname (uppercase)
  • ${FQDN} = full AD CS server hostname

Step 1: Configure the AD CS Connection in VSatellite

Once prerequisites are met, configure the integration in the VSatellite interface.

  1. Sign in to Certificate Manager - SaaS.

  2. Click Integrations > Certificate Authorities.

  3. Click New > Microsoft AD CS.

  4. Enter a Name for the Certificate Authority.

Tip: This is the name that will be used throughout Certificate Manager - SaaS for this CA.

  1. 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.

  1. 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.

  2. Provide credentials: Enter your Username and Password.

  3. To enable Kerberos, the username must include a domain qualifier.
  4. 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 Certificate Manager - SaaS

Now that the connection is made, we can set up certificate issuance through Certificate Manager - SaaS. This step is required only if you want to issue new TLS server authentication certificates through Certificate Manager - SaaS. If you just want to import existing certificates, see the import existing certificates steps below.

  1. Click in the Issuance templates field. After clicking in the field, Certificate Manager - SaaS queries your AD CS and returns a list of issuance templates from your AD CS server.

  2. Select the AD CS issuance templates that you want to map to Certificate Manager - SaaS.

  3. Click Add.

    Certificate Manager - SaaS tests all the templates you selected. Templates with a Passed result are available to map to Certificate Issuing Templates in Certificate Manager - SaaS. Those with a Failed result are not.

    Why did some templates fail?

    After adding templates, Certificate Manager - SaaS issues test certificates using each of the AD CS issuance templates. Certificate Manager - SaaS 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 (can't issue certificates with SN build from the AD)

    Issuance templates that are incapable of issuing such certificates fail the Certificate Manager - SaaS issuance test. This is expected. Some of the predefined (default) Issuance templates that will fail are:

    • DirectoryEmailReplication
    • DomainController
    • DomainControllerAuthentication
    • KerberosAuthentication

    Only the certificates that pass the test will be available when mapping AD CS templates to Certificate Manager - SaaS templates.

    However, issuance tests use a static 2048-bit CSR, and are expected to fail for AD CS templates that require larger key sizes. You will still be able to save the CA account settings, and issue certificates with ADCS templates with larger key sizes.

  4. 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.

What's Next?

Now that your AD CS templates are mapped to Certificate Manager - SaaS, you can create a Certificate Issuing Template and associate your AD CS templates with Certificate Manager - SaaS issuing templates.

Select Microsoft from the New Certificate Issuing template screen. The AD CS templates that passed validation will show up in the Product Option drop-down.

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. After clicking in the box, Certificate Manager - SaaS queries your AD CS and returns a list of templates from your AD CS server.

  2. Select the AD CS templates that you want to import certificates from. Only certificates issued by the templates you select will be imported.

  3. Click Add.

  4. If you want to schedule the import to occur on a regular basis, click the AD CS Import slider, and then set the import interval. This option is available only if one or more AD CS templates were added in the previous steps.

  5. Under Import options, select whether you want to import revoked or expired certificates.

  6. Click Done.

Certificate Manager - SaaS 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 Certificate Manager - SaaS Troubleshooting guide for solutions to common issues, including VSatellite and Microsoft AD CS configuration problems.