Skip to content

Overview: VSatellite Integration with Microsoft AD CS

With the retirement of the VSatellite Worker, integration with Microsoft Active Directory Certificate Services (AD CS) now functions directly via VSatellite. This architectural update eliminates the need for a separate VSatellite Worker and simplifies the connection and authentication process between VSatellite and the AD CS server.

Features and Benefits

  • Streamlined architecture: The integration no longer requires a separate VSatellite Worker. By connecting directly from VSatellite to the AD CS server, the overall deployment and ongoing management are simplified.

  • Kerberos attempted by default: VSatellite now authenticates directly with AD CS using Kerberos when standard environmental conditions are met. While Kerberos authentication was technically possible with the Worker-based architecture, it required additional, customer-managed configuration on the Worker machine and was therefore rarely implemented in practice.

  • Improved security with reduced configuration effort: Kerberos is the recommended authentication method because it provides mutual authentication and stronger encryption than NTLM. The direct integration removes the need for customer-side Worker configuration to achieve these security benefits.

  • Selectable authentication method: You can choose how VSatellite authenticates to AD CS using the Authentication method setting, available with VSatellite 2.0.31 or later:

  • Automatic (default): VSatellite attempts Kerberos when environmental conditions are met and automatically falls back to NTLM otherwise. This preserves the existing default behavior.
  • NTLM: VSatellite connects using NTLM only, skipping Kerberos discovery entirely.

  • Kerberos: VSatellite connects using Kerberos only, with the Service Principal Name (SPN), Key Distribution Center (KDC), and Domain that you supply. VSatellite does not fall back to NTLM.

  • Built-in resiliency through automatic fallback: In Automatic mode, if a Kerberos attempt fails quickly—for example, because no usable SPN was found, the credentials were rejected, or the KDC actively refused the request—VSatellite falls back to NTLM to maintain connectivity, without requiring manual intervention. The explicit NTLM and Kerberos methods do not fall back; each uses only the selected protocol.

Note: Fallback cannot rescue a Kerberos attempt that hangs rather than fails. If traffic to the KDC on port 88 is silently dropped, or the realm cannot be resolved in DNS, the request times out and fails instead of falling back to NTLM. In that case, fix KDC reachability or select NTLM explicitly.

  • VSatellite High Availability (HA) support: The direct integration now supports VSatellite High Availability configurations when using Microsoft AD CS, enhancing reliability and uptime for certificate operations.

Audience and Use Cases

This integration is intended for system administrators who are configuring and managing certificate issuance workflows between VSatellite and Microsoft AD CS. It applies to scenarios where you are setting up new AD CS connections, including migrating existing configurations that previously relied on the retired VSatellite Worker and required additional machine-side configuration.

Requirements and Compatibility

To successfully utilize the direct integration and enable Kerberos authentication, the following prerequisites and system requirements must be met:

  • Minimum VSatellite Version: The Authentication method setting requires VSatellite 2.0.31 or later. On earlier versions the setting is not available, and VSatellite behaves as it does in Automatic mode.

  • AD CS Service Port Requirements: Network access that was previously configured for the worker machine must now be applied to the VSatellite machine. The VSatellite machine requires access to ports 135 and 49152–65535 on the AD CS Service.

  • Automatic-mode Kerberos Conditions: When the Authentication method is set to Automatic, all three of the following conditions must be met for VSatellite to use Kerberos (otherwise it falls back to NTLM):

  • The Server address must be an FQDN (for example, adcs.example.com), not an IP address.
  • The Username must include a domain qualifier, either in UPN format (user@DOMAIN.COM) or down-level format (DOMAIN\user).
  • LDAP connectivity must be available from the VSatellite machine to the Active Directory Domain Controller (used for automatic SPN discovery).

  • The AD CS server must have at least one HOST/ or RPCSS/ SPN registered. VSatellite ignores SPNs with any other prefix during discovery and falls back to NTLM if neither is found.

  • Explicit Kerberos Requirements: When the Authentication method is set to Kerberos, you supply the Service Principal Name (SPN), Key Distribution Center (KDC), and Domain directly. VSatellite does not perform SPN discovery in this mode, so LDAP connectivity to the Domain Controller is not required. The VSatellite machine needs to reach only the specified KDC on port 88 for ticket issuance. The username must still be domain-qualified (user@DOMAIN.COM or DOMAIN\user); otherwise, the connection fails.

  • Domain Controller Port Requirements: In Automatic mode, the VSatellite machine requires standard outbound connectivity to the Active Directory Domain Controller on the following ports:

  • Port 636 (TCP): LDAPS for SPN discovery (tried first).
  • Port 389 (TCP): LDAP for SPN discovery (fallback).
  • Port 88 (TCP/UDP): Kerberos KDC for ticket issuance.

What's Next

The topics in this section describe how to set up and configure the AD CS integration with Certificate Manager - SaaS.

Before you begin, ensure that you have a Linux server available for VSatellite. For details, see the system requirements.

Your AD CS service must also meet specific configuration requirements. For details, see Setting up Microsoft AD CS.

After the server is in place and AD CS is configured, follow the remaining setup steps described in Issuing certificates with Microsoft AD CS.