AD CS aufräumen: CA-Template-Wildwuchs, Autoenrollment und Auditing sauber steuern

Active Directory Certificate Services (AD CS) ist ein mächtiges Werkzeug, das leider allzu oft mit default Templates und vergessenen Konfigurationen betrieben wird. Dabei steckt gerade in der Template-Hygiene ein enormes Sicherheitspotenzial. Hier zeige ich, worauf es bei der Pflege und Härtung eurer Zertifikatsvorlagen ankommt.

Warum Template-Hygiene wichtiger ist als „noch eine neue CA”

AD CS ist schnell installiert, aber schwierig sauber zu betreiben, sobald mehrere Teams Zertifikate „bestellen“.

Typische Symptome:

• 30+ Zertifikat-Templates, von denen niemand mehr weiß, wofür sie sind
• Autoenrollment verteilt Zertifikate an Geräte/Benutzer, die sie nie brauchen
• Legacy-Templates mit schwachen Einstellungen (Key Usage, EKU, Key Length)
• Unklare Zuständigkeiten („wer darf das Template ändern?“)

Schritt 1: Template-Inventar erstellen

Ich fange gern mit einem Export der Templates an: Was existiert, wer ist Owner, wer darf enrollen, wie sind die wichtigsten Flags gesetzt.

# Template-Inventar (ausführen auf einem Domain-joined Admin Host)
Get-ADObject -LDAPFilter "(objectClass=pKICertificateTemplate)" -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com" |
  Select-Object Name, DistinguishedName, whenChanged |
  Sort-Object whenChanged -Descending

Das Ergebnis ist noch kein Audit, aber ihr seht sofort „aktive Baustellen“ (kürzlich geändert) und die Menge.

Quick-Check: Wer darf enrollen?

In der Praxis sind es die ACEs auf dem Template-Objekt, die euch nachts wachhalten.

# Zeige ACL eines Templates (Beispiel)
$template = "User"
$dn = (Get-ADObject -LDAPFilter "(cn=$template)" -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com").DistinguishedName
(Get-Acl "AD:$dn").Access | Where-Object {
  $_.ActiveDirectoryRights -match "ExtendedRight|GenericAll|WriteProperty"
} | Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType

Schritt 2: Autoenrollment bewusst machen

Autoenrollment ist super, wenn es sauber designed ist. Es ist gefährlich, wenn:

• Gruppen „zu breit“ sind (z.B. Domain Computers)
• Templates Client Authentication enthalten, obwohl sie nur TLS-Serverzertifikate sein sollten
• Private Keys exportierbar sind

Empfehlung: „Enroll“ vs. „Autoenroll“ trennen

• „Enroll“: Nur wenige definierte Gruppen
• „Autoenroll“: Nur dort, wo ihr es wirklich braucht, mit Change-Prozess

Schritt 3: Auditing einschalten (und auch auswerten)

Viele AD-CS-Installationen loggen zu wenig oder Logs werden nicht zentral gesammelt.

Wichtige Datenpunkte:

• Template-Änderungen im AD (Configuration Partition)
• CA-Events (Issue/Fail/Revocation)
• Enrollment über CEP/CES (falls im Einsatz)

# CA Event Logs abfragen (auf der CA)
Get-WinEvent -LogName "Microsoft-Windows-CertificationAuthority/Operational" -MaxEvents 20 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Wenn ihr die Logs zentral sammelt: unbedingt Felder wie Requester, Template, SerialNumber normalisieren.

Schritt 4: Ein „Template Lifecycle“ einführen

Für jedes Template:

• Zweck (1 Satz)
• Owner-Team
• „Consumers“ (wer nutzt es)
• Review-Intervall
• Deprecation-Plan

Ein praktischer Einstieg: „Keine neuen Templates ohne Ablaufdatum für die Review“.

Takeaways

• AD CS wird durch Template-Wildwuchs unübersichtlich – ein Inventar ist der schnellste Einstieg.
• Autoenrollment ist ein Hebel, aber ohne Scope-Disziplin ein Risiko.
• ACLs auf Template-Objekten sind oft der eigentliche Angriffsvektor.
• Schaltet CA-Operational-Logs ein und sammelt sie zentral.
• Führt einen einfachen Lifecycle für Templates ein (Owner/Review/Deprecation).