Learn Active Directory - Active Directory Certificate Services (AD CS)

#Introduction

In episode 17 we learned how to back up and restore Active Directory — ensuring the directory survives even a disaster. But there's one question we haven't answered: how do we ensure communication between users, machines, and services is truly trusted? The answer often depends on digital certificates. In episode 18 we build Active Directory Certificate Services (AD CS) — the service that turns AD into a certificate authority for the entire network.

Why does AD CS matter? Imagine an internal web application that must be accessed over HTTPS. Without your own CA, you'd have to buy certificates from a third party or use self-signed certificates that other machines don't trust. AD CS lets organizations issue certificates for machines, users, and services automatically — integrated with AD and immediately trusted by all domain-joined computers.

#What Is PKI

PKI (Public Key Infrastructure) is the whole system that issues, distributes, stores, and revokes digital certificates. Its core components:

• Certificate — a digital document containing the subject's identity (computer or user name), the public key, and the CA's signature.
• Key pair — a public key that may be shared and a private key that must be kept secret.
• Certificate Authority (CA) — the trusted entity that signs and issues certificates.
• Certificate chain — the sequence of certificates connecting a subject's certificate up to a trusted root CA.

The closest analogy is a passport. Your passport is issued by the immigration office (the CA), and border officers trust it because the issuer is legitimate. The same applies in the digital world: a computer trusts a certificate if it's signed by a CA already on its trusted root list.

#The Certificate Chain (Chain of Trust)

In enterprise environments, certificates are rarely issued directly by the root CA. Instead, a layered hierarchy is used:

1. Root CA — the pinnacle of trust. Often kept offline and stored securely so its private key is never exposed to the network.
2. Subordinate CA — the bridge between the root and issuing CAs.
3. Issuing CA — the CA that actually issues certificates to machines and users.

Why layer it? This is the principle of damage isolation. If one issuing CA leaks, you can revoke that subordinate certificate without dismantling the whole root. An offline root means its private key can't be stolen over the network. The longer the chain, the easier it is to isolate an incident.

#CA Types in AD CS

AD CS provides two basic types based on AD integration:

A common production combination: an offline Standalone Root CA at the top, then an online Enterprise Issuing CA that issues certificates to AD objects.

#Certificate Use Cases in Organizations

Once AD CS is up, certificates are used in many places:

• SSL/TLS for internal web servers and applications.
• Smart card logon and Windows Hello for Business.
• EFS (Encrypting File System) for per-user file encryption.
• Code signing for internal scripts and applications.
• 802.1x authentication for WiFi and wired networks.
• S/MIME for signing and encrypting email.
• IPsec for securing server-to-server communication.

The point: certificates turn AD identity into cryptographically provable identity — something that can't be forged just by knowing a username.

#Installing AD CS

Installation happens in two stages: install the role, then configure the CA. Use PowerShell on the server that will become the CA:

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
Install-AdcsCertificationAuthority -CAType EnterpriseRootCa -CACommonName "Corp-Root-CA" -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -KeyLength 4096 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 10
Restart-Service CertSvc

For an issuing CA, use the subordinate type:

Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCa -CACommonName "Corp-Issuing-CA" -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -KeyLength 2048 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 5

After installation, configuration continues in the certsrv.msc console: setting validity periods, certificate database location, and cryptography options.

#Certificate Templates

A template is a certificate recipe defining the usage, validity period, key length, and who may receive the certificate. AD CS ships with ready-to-use built-in templates:

• Web Server — for IIS and SSL/TLS.
• Computer and User — for machine and user authentication.
• Smartcard Logon — for smart card authentication.
• EFS Recovery Agent — for recovering encrypted files.

If built-in templates don't meet your needs, create a custom template: duplicate a version 2 or higher template, modify the attributes, then set the enrollment permissions. Permissions determine who may Read, Enroll, or Autoenroll against the template — as a principle, restrict enrollment to only the groups that genuinely need it.

#Certificate Enrollment

There are four enrollment paths:

• Manual — users request certificates via certlm.msc or certmgr.msc.
• Web enrollment — via the CA web interface at http://ca-server/certsrv.
• NDES — for network devices without an AD identity (routers, switches, printers).
• Auto-enrollment — machines and users receive certificates automatically without interaction.

Auto-enrollment is the most efficient mode. After a template is allowed to autoenroll and the CA is published to AD, create a GPO that enables it:

certutil -dspublish -f C:\Certs\Corp-Root-CA.crt RootCA
certutil -addstore -f -enterprise Root C:\Certs\Corp-Root-CA.crt
certutil -pulse

Enable auto-enrollment in GPMC: open a GPO, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment, set the Configuration Model to Enabled, then check the options to renew, update, and remove invalid certificates.

With this GPO, every computer that boots or every user who logs on automatically has their template checked and receives a certificate if eligible. Latest certificates are renewed without the user knowing anything — that's the power of centralized identity working behind the scenes.

#Verifying Certificates

To make sure the chain of trust is healthy, check from both the CA side and the client side:

• On the CA: certutil -dump shows CA details, and Get-CAService checks service status.
• On the client: open certlm.msc then open Trusted Root Certification Authorities — the root certificate should appear there, and the machine certificate appears in the Personal folder.

#Conclusion

In this episode you built a PKI on top of AD:

• Certificates are digital identities issued by a CA, and the chain of trust links certificates to a trusted root.
• Enterprise CA integrates with AD and supports templates and auto-enrollment; Standalone CA suits an offline root.
• Templates control certificate contents and who may receive them.
• Auto-enrollment via GPO distributes and renews certificates automatically.

Certificates are no longer expensive items bought from a vendor — they're now a self-managed infrastructure service. In episode 19, we cover Read-Only Domain Controllers (RODCs): how to place a domain controller in a branch office without sacrificing security, complete with the password replication policy. See you there!