Certificate Services & PKI (AD CS)

Wozu eine PKI in AD — und warum sie Tier-0 ist

Active Directory Certificate Services (AD CS) ist die interne Public-Key-Infrastruktur der Domäne. Sie stellt Zertifikate aus, mit denen sich Nutzer und Maschinen authentifizieren (Smartcard-/PKINIT-Logon, 802.1x, VPN, LDAPS, Code Signing). Ein Zertifikat ist damit ein zweiter Weg, eine Identität zu beweisen — neben dem Passwort.

Der entscheidende Punkt für die Sicherheit: Eine Enterprise-CA wird beim Setup in den NTAuth-Store der Domäne eingetragen. Jedes Zertifikat, das an eine dieser CAs zurückkettet und eine Authentifizierungs-EKU trägt, wird von Domain Controllern als gültiger Logon-Nachweis akzeptiert. Wer also unkontrolliert Client-Auth-Zertifikate ausstellen kann, kann sich als beliebige Identität anmelden — ganz ohne deren Passwort.

Zweistufig: Offline-Root und Online-Issuing

Die verbreitete Praxis ist eine zweistufige Hierarchie: eine Root-CA, die den Vertrauensanker signiert, und darunter eine oder mehrere Issuing-CAs, die den Tagesbetrieb erledigen. Der Grund ist Blast-Radius-Kontrolle:

Root-CA	Signiert nur die untergeordneten CA-Zertifikate — selten, mit langer Laufzeit. Wird als standalone aufgesetzt und danach offline gehalten (heruntergefahren/getrennt). Nicht domänengejoint, kein Netz. Ihr privater Schlüssel ist das höchste Gut.
Issuing-CA (Enterprise, online)	Domänengejoint, stellt die Massenzertifikate für Nutzer/Maschinen aus, kennt Templates und Autoenrollment. Wird sie kompromittiert, kann man sie widerrufen und über die Root neu ausstellen, ohne den Vertrauensanker zu verlieren.

Eine einstufige PKI (Root = Issuing, online, domänengejoint) spart Aufwand, koppelt aber den Vertrauensanker an die Angriffsfläche des Tagesbetriebs: Wird diese eine CA kompromittiert, ist der Anker selbst verloren — Recovery heißt dann, die gesamte PKI neu aufzubauen und überall neu zu verteilen.

Kurzcheck

Warum hält man die Root-CA offline und lässt eine separate Issuing-CA den Betrieb machen?

Damit eine Kompromittierung der Betriebs-CA widerrufen und über den weiterhin vertrauenswürdigen Anker neu ausgestellt werden kann.
Weil eine Offline-Root Zertifikate schneller ausstellt als eine Online-CA.
Weil nur eine Offline-Root Zertifikate für Smartcard-Logon ausstellen darf.

Genau. Die Trennung begrenzt den Blast-Radius: Der seltene, offline gehaltene Schlüssel bleibt geschützt, während die exponierte Issuing-CA ersetzbar bleibt.

Certificate Templates: die Blaupause der Ausstellung

Eine Enterprise-CA stellt nichts frei Hand aus — sie folgt Certificate Templates. Ein Template legt fest: welche EKU das Zertifikat trägt, wer es beantragen darf, wer Subject/SAN liefert und ob ein Mensch die Ausstellung genehmigen muss. Wer das Template (bzw. dessen ACL) kontrolliert, kontrolliert damit was ausgestellt wird.

Enroll	Recht, ein Zertifikat aus diesem Template aktiv zu beantragen. Sollte auf die Gruppe begrenzt sein, die es fachlich braucht — nicht `Domain Users` oder `Authenticated Users` für Auth-Templates.
Autoenroll	Zusätzlich zu Enroll: Clients ziehen das Zertifikat automatisch und lautlos per Gruppenrichtlinie. Bequem für Flottenrollout, aber es verteilt ein gefährliches Template ohne jede menschliche Zwischenkontrolle an die gesamte Zielpopulation.
Write/FullControl auf das Template	Wer die Template-Konfiguration ändern darf, kann Flags, EKU und Enroll-Rechte umschreiben — also ein harmloses Template in ein gefährliches verwandeln. Dieses Recht gehört ausschließlich zu Tier-0-PKI-Administratoren.

EKU: wofür ein Zertifikat überhaupt gilt

Die Extended Key Usage (EKU) ist die Liste der Zwecke, für die ein Zertifikat gültig ist. Sie ist die eigentliche „Vollmacht“ des Zertifikats. Für die Sicherheit zählt vor allem, ob eine EKU die Authentifizierung gegen AD erlaubt:

Client Authentication (`1.3.6.1.5.5.7.3.2`)	Erlaubt, sich mit dem Zertifikat als Client zu authentifizieren (u. a. PKINIT/Kerberos, LDAPS-Clientauth). Reicht für Identitätsübernahme, wenn der Antragsteller den Namen im Zertifikat bestimmen kann.
Smart Card Logon (`1.3.6.1.4.1.311.20.2.2`)	Ebenfalls eine Authentifizierungs-EKU — für interaktives Smartcard-/PKINIT-Logon. Aus Angreifersicht gleich brisant wie Client Authentication.
Any Purpose / keine EKU	„Any Purpose“ oder ein fehlendes EKU-Feld (SubCA) machen das Zertifikat für jeden Zweck nutzbar — inklusive Auth. Am gefährlichsten, weil unbegrenzt.
Server Authentication, Encrypting File System, …	Zwecke ohne Client-Auth. Ein reines Server-Auth-Zertifikat erlaubt keine Anmeldung als Nutzer — die EKU begrenzt die Vollmacht.

Wer liefert Subject und SAN?

Ein Auth-Zertifikat sagt: „Ich bin dieser Principal.“ Welcher Principal das ist, steht im Subject bzw. im Subject Alternative Name (SAN) — bei AD-Auth meist der UPN. Entscheidend ist, wer diesen Namen setzt:

Von der CA aus AD gebaut (Default und sicher): Die CA setzt Subject/SAN anhand des authentifizierten Antragstellers aus dem Verzeichnis. Man kann nur ein Zertifikat für sich selbst bekommen.
Vom Antragsteller geliefert (`ENROLLEE_SUPPLIES_SUBJECT`): Das Template erlaubt, dass der Antragsteller Subject/SAN frei angibt (im Template-Dialog „Angabe in der Anforderung“). Damit kann jemand einen fremden UPN eintragen — z. B. den eines Domain Admins.

Kurzcheck

Ein Template hat die Client-Authentication-EKU und erlaubt dem Antragsteller, den SAN selbst zu setzen; Enroll ist für `Domain Users` offen. Was ist das Kernproblem?

Jeder Domänennutzer kann ein Auth-Zertifikat auf einen fremden Principal (z. B. Domain Admin) ausstellen und sich damit als dieser anmelden.
Nichts Kritisches — die CA prüft beim Logon ohnehin das Passwort des Ziel-Accounts.
Nur ein Verfügbarkeitsproblem, weil zu viele Nutzer gleichzeitig enrollen.

Richtig. Auth-EKU plus selbst gelieferter SAN plus breite Enroll-Rechte ergibt Identitätsübernahme — das ist die ESC1-Klasse.

Fehlkonfig-Klassen: ESC1 und ESC8 als Prinzip

Die bekannten AD-CS-Eskalationen (in der Forschung als ESCx nummeriert) sind keine Exploits in einer Software-Version, sondern Klassen von Fehlkonfigurationen. Zwei sind das Fundament:

ESC1 — antragstellergelieferter SAN auf einem Auth-Template. Ein Template erfüllt gleichzeitig: (1) niedrig privilegierte Enroll-Rechte, (2) eine Auth-EKU (Client Auth / Smart Card Logon / PKINIT / Any Purpose), (3) ENROLLEE_SUPPLIES_SUBJECT, (4) keine Manager-Genehmigung und (5) keine geforderte autorisierte Signatur. Ergebnis: jeder berechtigte Antragsteller stellt sich ein Zertifikat für einen beliebigen Principal aus. Die Abwehr sitzt an jeder dieser Bedingungen — am wirksamsten daran, den selbst gelieferten SAN abzuschalten und Auth-EKUs nur an enge Gruppen zu vergeben.
ESC8 — NTLM-Relay auf die Web-Enrollment-Endpunkte. Die HTTP-basierten Enrollment-Schnittstellen (Web Enrollment certsrv, Certificate Enrollment Web Service) akzeptieren standardmäßig NTLM und sind nicht gegen Relay geschützt. Ein Angreifer zwingt ein privilegiertes Maschinenkonto (etwa einen DC) zur Authentifizierung (Coercion) und relayt diese an den HTTP-Endpunkt, um ein Zertifikat für den DC zu erhalten. Die Abwehr sitzt am Kanal: Extended Protection for Authentication (EPA/Channel Binding) erzwingen, HTTPS verlangen, NTLM unterbinden — oder Web-Enrollment ganz entfernen, wenn ungenutzt.

Härten, Widerruf und der CA-Schlüssel

Härten heißt: die Ausstellungs-Vollmacht auf das Nötige verengen. Die wirksamsten Hebel, grob nach Wirkung:

ENROLLEE_SUPPLIES_SUBJECT auf Auth-Templates abschalten (CA baut Subject/SAN aus AD).
Enroll-Rechte kürzen — keine Domain Users/Authenticated Users auf Auth-Templates; Autoenroll nur, wo bewusst gewollt.
Manager-Genehmigung für sensible Templates erzwingen (menschliches Gate).
Gefährliche/unnötige EKUs entfernen; keine „Any Purpose“-Templates für breite Gruppen.
Ungenutzte Auth-Templates ganz von der CA nehmen (unpublish) — was niemand braucht, ist reine Ausstellungsfläche und wird durch eine spätere Fehländerung zum Pfad.
Für die HTTP-Enrollment-Endpunkte EPA + HTTPS erzwingen und NTLM unterbinden.

Revocation ist die Notbremse — aber nur so gut wie ihre Erreichbarkeit. Ein Zertifikat gilt als gültig, solange die prüfende Gegenstelle keinen Widerruf sieht. Ein Widerruf wirkt erst, wenn eine aktualisierte CRL (oder OCSP-Antwort) veröffentlicht und erreichbar ist und die Gegenstelle sie prüft; zwischengespeicherte CRLs gelten bis zu ihrem Ablauf weiter. Wichtig: Der AD-CS-Online Responder (OCSP) leitet seine Antwort in der Standardkonfiguration aus derselben CRL ab — er ist damit nicht automatisch aktueller als die CRL, nur feiner abrufbar. Kehrseite: Ist der CRL Distribution Point (CDP) unerreichbar und prüft die Gegenstelle „hart“, schlägt jede Validierung fehl — ein klassischer, flächiger Ausfall (TLS, Logon), ganz ohne Angreifer.

Zusammenfassung — gleich im Check

Die Achsen dieses Moduls: zweistufige Hierarchie (Offline-Root/Online-Issuing) und die CA als Tier-0-Vertrauensanker; Templates (Enroll vs. Autoenroll, wer darf ändern); EKU (welche Zwecke Auth erlauben); Herkunft von Subject/SAN; die Fehlkonfig-Klassen ESC1 und ESC8; Härtung, Revocation/CRL-Abhängigkeit und der Blast-Radius des CA-Schlüssels.