Overview: VSatellite Integration with Microsoft AD CS
Table of Contents
Expand all | Collapse all
-
- Activate Next-Generation Trust Security
-
-
- Configure Akamai Connection
- Configure AWS Connection
- Configure Azure Key Vault Connection
-
- Workload Identity Federation Authentication
- Workload Identity Federation - Azure Identity Provider Authentication
- Next-Gen Trust Security Generated Key Authentication
- User Permissions
- Workload Identity Federation Authentication
- Next-Gen Trust Security Generated Key Authentication
- User Permissions
- Supported OIDC Claims
-
-
-
- Working with the Built-in CA
- Add AWS Public CA
- Add AWS Private CA
- Add DigiCert One Certificate Authority
- Add Entrust
- Add GlobalSign Atlas
- Add GlobalSign MSSL
- Add GoDaddy
- Add Google Cloud Private CA
- Add a HID PKIaaS CA
- Add Certificate Manager - Self-Hosted
- Set Up an OpenSSL Certificate Authority Connector
- Create a Sectigo Certificate Manager Certificate Authority
- Add Zero Touch PKI
- Set Up Certificate Expiration Notifications
- Using a Custom DNS Provider
-
-
-
-
- Create an F5 BIG-IP LTM Machine
- Create a Microsoft Azure Private Key Vault Machine
- Create a Microsoft Azure Application Registration Machine
- Create a Microsoft IIS Machine
- Create a Microsoft Windows (PowerShell) Machine
- Create a Microsoft SQL Server Machine
- Create a Common KeyStore Machine
- Create a Citrix ADC Machine
- Create an Imperva WAF Machine
- Create a VMware NSX Advanced Load Balancer (AVI) Machine
- Create an A10 Thunder ADC Machine
- Create a Cloudflare Machine
- Create Kemp Virtual LoadMaster Machine
- Create a Palo Alto Panorama Machine
- Create a Radware Alteon Machine
-
- Provision to an F5 BIG-IP LTM
- Provision to a Microsoft Azure Private Key Vault
- Provision to Microsoft IIS
- Provision to Microsoft Windows (PowerShell)
- Provision to Microsoft SQL Server
- Provision to a Common KeyStore
- Provision to a Citrix ADC
- Provision to an Imperva WAF
- Provision to VMware NSX Advanced Load Balancer (AVI)
- Provision to an A10 Thunder ADC
- Provision to Cloudflare
- Provision to a Kemp Virtual LoadMaster
- Provision to Palo Alto Panorama
- Provision Certificates to Radware Alteon
-
-
- 47-Day Validity Readiness TLS Certificates dashboard
- About the Certificate Inventory
- Managing Certificate Lifecycle Settings
- Reissuing Certificates in Next-Gen Trust Security
- Downloading Certificates, Certificate Chains, and Keystores
- Retiring, Recovering, and Deleting Certificates
- Finding Certificates in the Certificate Inventory
- Importing Certificates from a CA Using EJBCA
- Domain-Based Validation for External Emails
-
- Create a Workload Identity Management or Discovery Agent Built-in Account
- Create an OCI Registry Built-in Account
- Create a Certificate Manager - Self-Hosted Built-in Account
- Create a Scanafi Built-in Account
- Toggling a Built-in Account on or Off
- Editing Built-in Accounts
- Deleting Existing Built-in Accounts
- Renew Existing Built-in Accounts
- Troubleshooting
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 authentication enabled 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.
- Built-in resiliency through automatic fallback: If Kerberos authentication cannot be established (for example, due to missing SPNs or an unreachable KDC), the system automatically falls back to NTLM to maintain connectivity—without requiring manual intervention.
- 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:
- 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.
- Kerberos Authentication Conditions: All three of the following conditions must be met to use Kerberos (otherwise the system falls back to NTLM):
- The Server address must be an FQDN (e.g., 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.
- Domain Controller Port Requirements: The VSatellite machine requires standard outbound connectivity to the Active Directory Domain Controller on the following inbound 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 Next-Gen Trust Security.
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.