Ausgangslage: PKI wächst oft leise neben dem AD

Active Directory Certificate Services (AD CS) wird in vielen Umgebungen nicht als Identitätskontrolle wahrgenommen, sondern als Infrastruktur: WLAN-Zertifikate, VPN, Smartcards, LDAPS, interne Webserver, alte Enrollment-Webseiten, Autoenrollment für Clients. Genau dadurch entsteht Risiko. Die CA läuft irgendwie, Templates werden selten geprüft, und Enrollment-Rechte bleiben über Jahre unverändert.

Der kritische Punkt: Zertifikate sind nicht nur Verschlüsselung. In AD-Umgebungen können sie Authentifizierung ermöglichen. Wer ein geeignetes Zertifikat bekommt, kann sich unter Umständen gegenüber AD-Diensten ausweisen, ohne ein Passwort zu kennen. Deshalb gehört AD CS in jedes Tier-0-Programm.

Das ist keine Aufforderung zu Panik oder Großumbau. Es heißt: AD CS braucht Ownership, saubere Templates, kontrollierte Enrollment-Rechte und messbare Betriebsprozesse.

Zielbild: CA und Templates sind bewusst gesteuert

Ein belastbares Zielbild sieht so aus:

  1. Alle Enterprise CAs sind inventarisiert inklusive Rollen, Patch-Stand, Härtung, Backup und Verantwortlichen.
  2. Zertifikat-Templates sind klassifiziert: Authentifizierung, Server, Client, Enrollment Agent, SubCA, Legacy.
  3. Enrollment-Rechte folgen Least Privilege statt „Domain Users darf alles beantragen“.
  4. Sensitive Templates erzwingen Kontrolle: keine freie Subject-/SAN-Angabe ohne klaren Grund, Manager Approval oder definierte Issuance Requirements wo nötig.
  5. CA-Systeme werden wie Tier 0 betrieben: wenige lokale Admins, starke Protokollierung, kontrollierte Admin-Logons, klare Wiederherstellung.
  6. Änderungen sind nachvollziehbar: Template-Änderungen, CA-Konfiguration und Zertifikatsausstellung werden überwacht.

Das Ziel ist nicht, jede Zertifikatsnutzung zu blockieren. Das Ziel ist, dass Zertifikate nicht unbemerkt zu privilegierten Identitäten werden.

Umsetzung: von Inventar zu kontrollierter Änderung

1) CA-Landschaft und Vertrauenskette erfassen

Starte mit einem read-only Inventar. Für die Projektsteuerung brauchst du keine Angriffssimulation, sondern Klarheit:

  • Welche Enterprise CAs existieren?
  • Welche CAs sind im AD veröffentlicht und vertrauenswürdig?
  • Welche Zertifikat-Templates werden tatsächlich ausgegeben?
  • Welche Templates erlauben Autoenrollment?
  • Wer ist lokaler Administrator auf den CA-Servern?
  • Wer darf CA- und Template-Konfiguration ändern?
  • Wo liegen CRL- und AIA-Pfade, und sind sie erreichbar?

Pragmatische Startpunkte:

certutil.exe -config - -ping
certutil.exe -catemplates
certutil.exe -dump

Wichtig: Diese Kommandos ersetzen keine Auswertung der Berechtigungen. Sie helfen nur, die Landschaft zu sehen. Die eigentliche Arbeit liegt in Templates, ACLs, CA-Rollen und Change-Historie.

2) Templates nach Authentifizierungsrisiko priorisieren

Nicht jedes Template ist gleich kritisch. Priorisiere Templates, die Identität ausstellen oder Identität beeinflussen können:

  • Client Authentication, Smartcard Logon, PKINIT/Kerberos-nahe Nutzung
  • Any Purpose oder sehr breite EKUs
  • Enrollment Agent und SubCA
  • Templates mit „Enrollee supplies subject“ oder frei steuerbarer SAN
  • Templates mit breiten Enrollment- oder Autoenrollment-Rechten
  • lange Laufzeiten ohne starken Governance-Prozess

Diese Muster sind in vielen AD-CS-Findings wiederkehrend. Du musst sie nicht als Exploit-Katalog behandeln, sondern als Risikoklassen: Wer kann ein Zertifikat bekommen, für wen gilt es, und wofür kann es verwendet werden?

3) Enrollment-Rechte reduzieren

Der häufigste saubere Fix ist nicht technisch spektakulär: Rechte reduzieren.

Praktische Leitplanken:

  • Authentifizierungs-Templates nicht pauschal für Domain Users oder große Sammelgruppen freigeben.
  • Autoenrollment nur für klar definierte Gerätegruppen oder Benutzergruppen.
  • Sensitive Templates mit Owner, Zweck, Laufzeit, Freigabeprozess und Ablaufdatum dokumentieren.
  • Legacy-Templates nicht nur deaktivieren, sondern vorher Abhängigkeiten sauber klären.
  • Änderung an Template-ACLs über Change-Prozess und Vier-Augen-Prinzip.

Der Betriebsnutzen ist hoch: Wenn nur berechtigte Identitäten Zertifikate erhalten können, sinkt das Risiko deutlich, ohne dass du PKI als Ganzes neu bauen musst.

4) CA-Server als Tier-0-System behandeln

Eine Enterprise CA ist kein normaler Windows-Server. Wer die CA administrieren oder ihre Templates steuern kann, beeinflusst Identitäten in der Domäne.

Mindeststandard:

  • CA-Server in Tier-0-Betriebsmodell aufnehmen.
  • Lokale Administratoren und CA-Rollen hart begrenzen.
  • Keine Alltagsadministration mit normalen Server-Admin-Konten.
  • Interaktive Logons auf CA-Systemen einschränken.
  • RDP, PowerShell Remoting und lokale Anmeldung nur für definierte Admin-Pfade.
  • EDR/Monitoring, Patch-Management und gesicherte Backups sicherstellen.
  • CA-Private-Key-Schutz prüfen, je nach Kritikalität mit HSM/TPM oder klarer Exportkontrolle.

Wenn die CA alt ist und niemand sie anfassen will, ist das ein Projektrisiko, kein Betriebsargument.

5) Sperrung, Laufzeiten und Audit in Ordnung bringen

AD-CS-Hardening endet nicht bei Templates. Prüfe auch:

  • CRL- und AIA-Pfade sind erreichbar, redundant und dokumentiert.
  • Zertifikatslaufzeiten passen zum Risiko des Templates.
  • Sperrprozesse sind getestet, nicht nur beschrieben.
  • CA-Auditing ist aktiviert und wird zentral gesammelt.
  • Template-Änderungen und Änderungen an CA-Rollen erzeugen Alarme oder mindestens Review-Signale.
  • Ausnahmen haben Owner und Ablaufdatum.

Kurze Laufzeiten ohne funktionierenden Renewal-Prozess erzeugen Ausfälle. Lange Laufzeiten ohne Governance erzeugen Sicherheitsrisiko. Beides muss zusammen geplant werden.

6) Änderungen in Wellen ausrollen

Ein guter AD-CS-Change hat selten einen „Big Bang“.

Pragmatischer Ablauf:

  1. Inventar und Risikoklassifizierung.
  2. Kritische Templates in Pilot-Scope prüfen.
  3. Breite Enrollment-Rechte entfernen oder durch definierte Gruppen ersetzen.
  4. Legacy-Abhängigkeiten mit Applikationsverantwortlichen klären.
  5. Sensitive Templates mit Approval/Issuance Requirements härten.
  6. CA-Server in Tier-0-Betrieb überführen.
  7. Audit und wiederkehrenden Review etablieren.

Dabei immer prüfen: Welche Zertifikate werden bereits genutzt? Welche Systeme müssen vor Ablauf erneuern? Welche Rollback-Option gibt es pro Template?

Vorteile (explizit)

  • Reduziert versteckte Domain-Takeover-Pfade: Zertifikate werden nicht mehr unkontrolliert zu AD-Identitäten.
  • Hoher Nutzen ohne Komplettneubau: Viele Risiken lassen sich über Template-ACLs, Enrollment-Gruppen und Governance reduzieren.
  • Bessere Betriebsqualität: CRL, AIA, Laufzeiten und Ownership werden sichtbar statt „PKI läuft halt“.
  • Stärkt Tier 0: CA-Server, Template-Admins und PKI-Owner werden in das privilegierte Betriebsmodell aufgenommen.
  • Gute Grundlage für LDAPS, Smartcard und Client-Zertifikate: Sicherheitsgewinn, ohne produktive Zertifikatsnutzung pauschal zu stoppen.

Nachteile und Grenzen (explizit)

  • Abhängigkeiten sind oft schlecht dokumentiert: VPN, WLAN, MDM, alte Webserver und Middleware hängen manchmal an Templates, die niemand mehr kennt.
  • Fehlkonfigurationen sind nicht immer sofort sichtbar: Ein Template kann jahrelang riskant sein, ohne Störung zu erzeugen.
  • Zu harte Änderungen brechen Betrieb: Autoenrollment, Renewal und Revocation müssen getestet werden.
  • AD CS ersetzt keine Identity-Hygiene: Schwache Admin-Pfade, Tiering-Probleme und unsaubere Service Accounts bleiben separate Risiken.
  • Private-Key-Schutz kann teuer oder organisatorisch schwer sein: HSM, Offline Root CA und saubere CA-Hierarchie sind sinnvoll, aber nicht immer kurzfristig realistisch.

Typische Stolperfallen in Projekten

  • CA wie normalen Member Server behandeln: falsche Admin-Gruppen, unsaubere Logons, kein Tier-0-Denken.
  • Nur den CA-Server prüfen, nicht die Templates: die meisten Risiken stecken in Templates und Berechtigungen.
  • Domain Users überall berechtigt lassen: bequem im Betrieb, riskant für Authentifizierungs-Templates.
  • Freie Subject-/SAN-Angabe unterschätzen: bei Authentifizierungs-Templates ist das besonders sensibel.
  • CRL/AIA nicht testen: Sperrung sieht auf Papier gut aus, scheitert aber im Ernstfall.
  • Legacy-Templates ohne Owner: niemand traut sich aufzuräumen, also bleibt das Risiko dauerhaft bestehen.
  • Kein Monitoring auf Template-Änderungen: eine sichere Baseline hilft wenig, wenn spätere Änderungen unbemerkt bleiben.

Projekt-Checkliste (für AD-CS-Hardening)

  • [ ] Enterprise CAs, Standalone CAs und veröffentlichte Vertrauenspunkte inventarisieren.
  • [ ] CA-Server als Tier-0-Systeme klassifizieren und Admin-Pfade prüfen.
  • [ ] Alle Templates nach EKUs, Subject/SAN-Steuerung, Enrollment-Rechten und Laufzeiten klassifizieren.
  • [ ] Authentifizierungs-Templates priorisiert prüfen und breite Enrollment-Rechte entfernen.
  • [ ] Autoenrollment auf definierte Gruppen begrenzen.
  • [ ] Sensitive Templates mit Owner, Approval, Issuance Requirements und Ablaufdatum versehen.
  • [ ] CRL/AIA-Erreichbarkeit und Sperrprozesse praktisch testen.
  • [ ] CA-Audit, Template-Änderungen und CA-Rollenänderungen zentral überwachen.
  • [ ] Legacy-Abhängigkeiten dokumentieren und Migrationsplan festlegen.
  • [ ] Wiederkehrenden PKI-Review in den AD-Hardening-Zyklus aufnehmen.