Active Directory Certificate Services
About AD CS
Microsoft Active Directory Certificate Services (also known as AD CS originally called Certificate Services) is a platform that was first bundled as a Role in Microsoft Server 2000. It is a common choice for organisations seeking a simple and cheap Certificate Authority (CA) and wider, but small-scale Public Key Infrastructure (PKI) capability. This document discusses the pros and cons of the platform.
The Pros
Maturity
Inexpensive
Active Directory Certificate Services (AD CS) was first introduced as a role in Server 2000. Since then, it has undergone updates in Server 2003, 2008, and 2012, and has been tested extensively in many small-scale deployments. In 2016, the smartcard capability was added to keep up with the OS updates. However, the product has not received any significant updates since Server 2012, which was released in the year 2011.
The AD CS role is a feature that is available in the Windows Server operating system. It provides an inexpensive and easily accessible option for organisations that have invested in Windows Servers. However, it is common for some to install the Role on a Domain Controller, which, Cogito does not recommend due to some security implications.
Simplicity
Active Directory Domain Services Integration
Although it’s easy to set up and operate, its limited extensibility can limit growth in capability, scale, and reliability.
The platform integrates with Active Directory Domain Services (AD DS). To get the most out of the security and integration features, AD DS must be available to AD CS.
The Cons
Does Not Support High Availability (HA)
Not an Enterprise Database Product by Today’s Standards
Mature, but no significant upgrades
Limited Recovery Options
System clustering requires centralized storage, limiting Zero Trust and diversity. Two CAs complicate fault finding and create security risks during certificate revocation and validation.
JET database was introduced in 1992 but Microsoft stopped support for it in 2004. It is less robust, lacks locking mechanism and deadlock resolution strategies. AD CS is limited to one CA per OS instance due to this.
The JET Database, used by AD CS, hasn’t been updated since its introduction in Access 2000. It was declared end-of-life in 2004 and has limited high availability options. AD CS had a significant update in 2008 and minor one in 2012 and bug fixes 2016.
The JET Database Engine’s limited recovery options negatively affect the PKI system. It lacks adequate backup and recovery capabilities and doesn’t support replication. Disk backups are the only redundancy solution, posing a risk to the CA’s ability to revoke certificates in case of recovery.
Performance Issues at Scale
AD CS struggles with certificate issuance at scale
- 1 million certificates AD CS becomes slower
- 2 million certificates it becomes unresponsive
- 4 million effectively so slow as to be functionally stopped
Each certificate within the AD CS system takes up 32KB of disk space and needs to be checked during every system startup. This means that if a system has 4 million certificates, 128GB of data needs to be sifted through on every restart.
No Real Certifications for the CA platform
One CA per Operating System
Limited Automation Capabilities
Limited Management Capabilities
Microsoft claims that AD CS has certifications such as Common Criteria due to it being bundled with the OS. However, their website lacks an adequate description of the certification status of ADCS.
Each Certificate Authority (CA) must be installed on a separate Virtual Machine (VM) with AC DS, unlike other products that allow multiple CAs per OS.
AD CS only supports AEP and NDES protocols, and not more modern methods like ACME, CMP, EST or API-based requests. To overcome this limitation, options such as the Jellyfish Certificate Lifecycle Management capability are often used. However, this can reduce the two key advantages of AD CS – cost and simplicity.
ADCS is often used with CLM software like the Jellyfish Certificate Lifecycle Management feature because it lacks search and reporting capabilities for issued certificates and their recipients.
Security Due to Common Deployment Methods
Due to the fact that the service is often deployed by non-PKI experts in another role on the server, security risks can arise.
- Existing services such as DCs are often used to deploy AD CS, which can pose significant risks.
- AD CS and AD DS are interdependent services. For example, if an AD DS certificate expires, it may prevent AD CS from issuing a replacement certificate.
- No segregation of the AD CS services from other services.
- Deployment without security enforcing capability such as HSMs. This makes a key security enforcing function within an environment open to relatively unsophisticated attacks.
- Deployment of a single Root and Issuing CA.
- Deployment of a Root CA that is not offline.
- Service deployed without proper controls or enterprise support for backups, vulnerability management, or updates. Legacy implementations found on desktop servers under employees’ desks (e.g. have found instances at Cogito)
- No backup or recovery strategy, or a strategy that does not account for the limitations of the JET database
Limited Extensibility
Works Only on Windows Server Operating Systems
AD CS is Not Currently Supported by Azure Key Vault
The AD CS interface has a limited capacity to issue certificates. It allows users to only submit a Certificate Request (CSR). However, the CSR submission is restricted to CSRs that contain the Microsoft specification for Certificate Template information.
Windows Server deploys only on Windows Server OS and allows only one certification authority (CA) per server. The automatic enrolment protocol is a Microsoft proprietary protocol and is exclusively supported on Microsoft platforms.
AD CS currently uses CNG/KSP API to access HSMs through PKCS #11 interface. Unfortunately, Azure Key Vault does not offer a PKCS #11 interface. This means if you want to use AD CS within Azure, you’ll need to specify dedicated HSMs which can be significantly more expensive.
Limited Registration Authority Capability in the Form of Network Device Enrolment Service (NDES)
NDES is classified as an RA by Microsoft, but has limited capabilities. Cogito doesn’t consider NDES to be an RA, but just a SCEP agent to AD CS. NDES implementation of SCEP is limited, requiring additional software deployments to allow cloud platforms to access its capabilities. RA products maintain information about all requests received for processing by CA, which NDES doesn’t do.
AD CS Does Not Support Cloud Platforms or a Multi-Cloud Strategy
AD CS has limitations when used in complex and larger cloud deployments, and it requires additional Microsoft software for interactions with the cloud. While it’s still a good choice for providing certificates in simple, small Microsoft-only environments, it lacks flexibility and capability for diverse requirements. None of the major cloud vendors offer a solution that allows for seamless movement between cloud providers without creating new CAs.
Conclusion
AD CS is a good choice for what it was intended to do. That is to provide certificates in simple, small Microsoft only environments where budget is the overriding consideration. AD CS fails where it is pressed into service for more complex and larger deployments. Its simplicity in these environments encourages poor security choices and where it does not have the flexibility and capability to meet a diverse range of requirements, where availability, reliability, scale, and non-Microsoft product support are considerations.
You can download our AD CS- Pros and Cons White Paper
