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.

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.

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.

Wie aus einem Zertifikat ein Konto wird

Ein Zertifikat behauptet eine Identität. Damit daraus eine Anmeldung wird, muss der Domain Controller es einem Konto zuordnen. Diese Zuordnung ist der Punkt, an dem die gesamte Sicherheit einer Zertifikats-Anmeldung hängt — und sie ist nicht immer gleich stark.

Implizit über einen Namen

Der KDC liest einen Namen aus dem Zertifikat — etwa den Anmeldenamen im Subject Alternative Name — und sucht das passende Konto.

Explizit über `altSecurityIdentities`

Am Konto selbst steht, welches Zertifikat zu ihm gehört. Die Zuordnung ist damit ausdrücklich gesetzt statt hergeleitet.

Widerruf: die Notbremse und ihre Grenzen

Ein ausgestelltes Zertifikat ist bis zu seinem Ablaufdatum gültig — es sei denn, es wird widerrufen. Der Widerruf ist damit die einzige Möglichkeit, ein Zertifikat vor seiner Zeit zu entwerten. Er hat allerdings drei Eigenschaften, die man kennen muss, bevor man sich darauf verlässt.

• Er wirkt nur, wenn geprüft wird. Nicht jede Anwendung prüft den Widerrufsstatus, und nicht jede prüft ihn streng. Was nicht geprüft wird, ist nicht widerrufen.
• Er wirkt nur, wenn die Auskunft erreichbar ist. Die Sperrliste liegt an einem Ort, den der Prüfende erreichen muss. Ist er es nicht, entscheidet die Konfiguration der prüfenden Seite über das Ergebnis — und die ist selten streng eingestellt.
• Er wirkt verzögert. Sperrlisten werden in Abständen veröffentlicht und von den Prüfenden zwischengespeichert. Zwischen dem Widerruf und seiner Wirkung liegt deshalb ein Fenster, dessen Länge man kennen sollte, bevor man sie im Ernstfall ausrechnet.

Durchgerechnet: ein Template, das zu viel erlaubt

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.