Key Takeaways
- Installing AD CS on a Domain Controller complicates decommissioning, OS upgrades, and system recovery, creating challenges for seamless management.
- A Domain Controller failure with AD CS results in the breakdown of certificate validation and authentication processes, leading to network outages, system downtime, and disruption of secure communications. Recovery is complex and time-consuming due to the combined roles of AD CS and DC.
- Cloud PKIs, by contrast, offer improved flexibility, scalability, and simplified management. They eliminate the need for on-premise infrastructure, reduce administrative overhead, and provide enhanced security features.
- SecureW2’s Managed Cloud PKI further simplifies certificate management and enhances network security. It simplifies device enrollment through the JoinNow onboarding feature, reduces operational costs, and automates certificate lifecycle processes.
Microsoft public key infrastructure (PKI) solutions are the cornerstone for managing and distributing the digital certificates that are essential for protecting communication channels inside enterprises.
But one question often comes up with IT administrators: is it better to implement Active Directory Certificate Services (AD CS) directly on a domain controller (DC), or are there other options that take advantage of Microsoft Cloud PKI?
AD CS is the foundation of a strong Microsoft PKI, providing the digital certificate management and authentication features necessary for safe communication. In the middle of this, Microsoft Cloud PKI’s introduction offers a strong alternative that promises increased security, scalability and accessibility.
However, AD CS can be tricky, and many IT admins make mistakes during the configuration process. One such mistake is installing AD CS certificate authorities (CAs) on a DC instead of another server.
This article explains why domain controllers need certificates, why the CA role should generally be kept separate, and how organizations can structure their PKI to avoid these challenges.
What Is a CA Domain Controller?
A CA domain controller is a Windows Server that runs both the Active Directory Domain Services (AD DS) domain controller roles and the AD CS certificate authority role. This configuration allows the same server to manage the AD domain and issue digital certificates.
While Windows supports running these roles on the same server, keeping them on separate servers is generally recommended for production environments. Domain controllers are critical to AD, while a CA has its own security, maintenance and recovery requirements.
Keeping the roles on separate servers gives administrators more flexibility when managing either system.
Understanding Microsoft PKI
As the foundation for securing communications inside corporate networks, Microsoft PKI offers the resources to manage digital certificates and certificate authorities.
At its foundation, Microsoft PKI relies on public key cryptography to build confidence and support safe authentication and encryption operations.
Digital certificates issued by reputable CAs function as digital identities, allowing for safe network communication.
The integrity and validity of transmitted data are ensured by the public keys, private keys and information included in these certificates.
One of the main elements of Microsoft PKI is AD CS, which provides features designed to facilitate encryption and authentication on corporate networks.
AD CS helps organizations manage digital certificates and secure communications by:
- Making it easier to issue, validate and revoke digital certificates, protecting the integrity of data and identities across a range of network endpoints
- Protecting critical communications and transactions using Transport Layer Security (TLS), the standards-track successor to Secure Sockets Layer (SSL), which the IETF prohibited outright
- Interfacing with Microsoft Active Directory, allowing for the centralized administration of authentication policies and certificates. This improves overall network security posture and streamlines administrative operations
See your security gap before attackers do.
See continuous trust in action on a platform that includes RADIUS, PKI and AI security.
Why Domain Controllers Need Certificates
A domain controller needs a certificate for certain authentication and communication functions, but that doesn’t mean the DC needs to be a certificate authority.
A trusted CA can issue certificates to domain controllers without the CA role being installed on the DC. Confusing these two roles can lead administrators to install AD CS on a domain controller when they only need the DC to have a certificate.
Several common Active Directory functions rely on domain controllers having certificates:
- Secure LDAP:Lightweight Directory Access Protocol (LDAP) uses a certificate on the domain controller to establish an encrypted connection with clients.
- Smart card sign-in: Certificate-based authentication uses the domain controller’s certificate as part of the authentication process.
- Certificate-backed Kerberos authentication: Kerberos extensions, such as PKINIT, use certificates to authenticate users and domain controllers.
None of those functions require the CA to be installed on the DC. An issuing CA on a separate server can enroll every domain controller through Group Policy autoenrollment, provided it is a domain-joined enterprise CA.
What Certificate Requirements Do CA Domain Controllers Have?
A domain controller certificate must meet specific requirements for Windows to recognize and use it for authentication and secure communications. The certificate includes several fields and properties that identify the domain controller, define how the certificate can be used, and allow clients to verify its validity.
The table below outlines the key requirements and why each one matters:
| Certificate Field | Required Value | Why It Matters |
| Key Usage | Digital Signature, Key Encipherment | Allows the DC to sign and receive encrypted key material |
| Enhanced Key Usage | Client Authentication (1.3.6.1.5.5.7.3.2) and Server Authentication (1.3.6.1.5.5.7.3.1) | Marks the certificate valid for both sides of an authenticated session |
| CRL Distribution Point | A reachable certificate revocation list | Gives clients a location to check the certificate’s revocation status |
| Subject Alternative Name (SAN) | The Domain Name System (DNS) name of the domain controller | Ties the certificate to the exact host clients connect to |
| Private key | Generated with the Schannel cryptographic service provider | Makes the key usable by the Windows authentication stack |
| Store location | Local computer certificate store | Where Windows looks for the domain controller certificate |
A domain-joined enterprise CA can use a domain controller certificate template to automatically populate these fields during enrollment. This allows organizations to automate certificate issuance and renewal for domain controllers without installing the CA role on the DC itself.
Don’t Install AD CS on Domain Controllers
While it is possible to install an AD CS certificate authority on the same server as a DC, doing so will create several problems for admins in the future.
For starters, DCs eventually have to be decommissioned, which becomes more complicated if that DC contains AD CS. Admins would have to move AD CS off that DC before decommissioning the DC.
Upgrading the CA to a newer version of AD CS means upgrading the domain controller’s operating system (OS). An in-place OS upgrade of a domain controller is supported, but Microsoft prefers the cleaner path: promote a new server to domain controller and demote the old one. That path forces you to migrate AD CS off the DC first.
One of the worst problems is that if the DC were to fail, admins would face the grueling task of restoring the DC and CA. The CA being down means that certificate validation and authentication are affected.
Installing AD CS on a DC is a bad security practice because installing any additional role on a DC increases its attack surface.
Unfortunately, several security gaps with AD CS can compromise the DC if it is installed on the same server.
The AD CS web enrollment endpoint is a great example of this.
If the endpoint is accessible over plain HTTP, an attacker can force a privileged account to authenticate to a system they control and relay that authentication to the certificate service. The attacker can then obtain a certificate issued in that account’s identity.
This attack relies on authentication relay rather than a misconfigured certificate template, although a usable certificate template must still be available.
When the web enrollment endpoint is hosted on a domain controller, the relay target and identity that the attacker is attempting to impersonate are on the same server.
The security plan that scales with you.
Our solutions can scale from mid-market to global enterprises. Compare options and see how our solutions protect you from costly breaches and ensure peace of mind.
Where Should the CA Live Instead?
The recommended approach is a two-tier CA hierarchy with a separate root CA and issuing CA. The root CA signs the issuing CA’s certificate and is then kept offline when it is not needed. This protects the root CA from unnecessary exposure while the issuing CA handles day-to-day certificate enrollment and management.
The issuing CA should run on a domain-joined member server, where it can issue certificates to domain controllers and other users, devices and services. Neither the root CA nor the issuing CA needs to run on a domain controller.
Smaller environments may choose to combine the CA roles on a single server, but doing so introduces the same decommissioning, operating system upgrade and recovery challenges that come with placing AD CS on a domain controller.
Note: For larger environments, a dedicated issuing CA is the cheaper option once you price in a single unplanned DC rebuild.
Configure a Managed PKI With AD CS
While AD CS allows admins to build a PKI, there’s a major disadvantage to not using a third-party PKI solution. AD CS is an on-premises service that requires admins to keep legacy systems on-premises.
On-prem PKIs are incredibly expensive to set up because there are so many components to include, each with its own price tag.
Enterprises need to pay for many things, including:
- Hardware and software implementation
- Maintenance fees
- Software licensing
- Secure hardware storage
- Data backup
- Disaster recovery
These expenses often come as hidden costs, meaning enterprises aren’t aware of them until it’s too late.
Instead, Microsoft admins can integrate their AD CS setup with a managed cloud PKI solution, which removes the implementation and management workload from admins and provides full cloud capabilities.
The image below shows how a managed PKI operates at a high level:
Configure JoinNow Dynamic PKI and Cloud RADIUS With AD CS
Organizations that already use Active Directory Certificate Services can integrate it with JoinNow Dynamic PKI and JoinNow Cloud RADIUS.
This allows organizations to keep Active Directory for identity and device management while using SecureW2 to simplify certificate enrollment, management and network authentication.
Dynamic PKI provides centralized certificate management, including certificate issuance, renewal and revocation. JoinNow onboarding can automate certificate enrollment for users and devices, while Cloud RADIUS supports certificate-based EAP-TLS authentication for secure network access.
Together, these services can reduce the administrative work involved in managing certificates and help organizations avoid putting additional infrastructure on their domain controllers.
Take a look at the video below to gain more insight into Dynamic PKI.
To learn more about using EAP-TLS with RADIUS, see the following video:
Secure Your Network Today With Dynamic PKI and Cloud RADIUS
Installing AD CS on a domain controller can create unnecessary operational and security risks. Organizations can reduce that complexity by keeping their domain controllers focused on Active Directory services and using Dynamic PKI and Cloud RADIUS to manage certificates and certificate-based network authentication.
Schedule a demo to see how SecureW2 can simplify certificate management without requiring a CA on your domain controller.
