In vielen Umgebungen sind die Active Directory Certificate Services (AD CS) ein unbemerkter Schlüssel zur gesamten Domäne. Ernst genommen werden sie meist erst, wenn der erste Angriff auffliegt. In mehreren Assessments und Incident-Analysen habe ich gesehen, wie falsch konfigurierte Zertifikatvorlagen den direkten Weg zum Domain-Admin freimachen. Besonders häufig betrifft das Vorlagen mit „Enrollee supplies subject“ oder mit zu weit gefassten Berechtigungen. Microsoft Defender for Identity (MDI) bringt inzwischen brauchbare Werkzeuge mit, um solche Schwachstellen sichtbar zu machen und gezielt zu beheben.

Falsch konfigurierte Zertifikatvorlagen öffnen den Angriffsweg ESC1

Wer sich mit AD-CS-Härtung genauer befasst, landet schnell beim Angriffsvektor „ESC1“. Dabei nutzt ein Benutzer eine zu offen oder unsauber konfigurierte Vorlage, um ein Zertifikat für eine beliebige Identität im Active Directory anzufordern. In vielen Umgebungen, die ich betreue, gibt es selbst nach Jahren des Betriebs noch mehrere solcher Templates. Manche stammen aus alten Migrationen, andere sind einfach historisch gewachsen. Richtig kritisch wird es, wenn „Enrollee supplies subject“ aktiviert ist und die Enrollment-Berechtigungen nicht restriktiv gesetzt sind. Selten ist diese Kombination keineswegs, oft bleibt sie als Altlast früherer PKI-Projekte zurück.

Defender for Identity bewertet AD CS über Sensoren und Assessments

Seit Microsoft die Security Posture Assessments in MDI erweitert hat, lassen sich die Risiken rund um AD CS deutlich besser einschätzen. Dafür muss allerdings auf den AD-CS-Servern der Defender-for-Identity-Sensor installiert sein. Genau das vergessen viele, nachdem die Domain Controller ausgerollt sind. Im Microsoft-Defender-Portal unter „Exposure management“ → „Recommendations“ oder direkt im Secure Score tauchen potenziell gefährliche Vorlagen dann mit konkreten Hinweisen auf, etwa in der MDI-Bewertung „Prevent users to request a certificate valid for arbitrary users“. Die technische Dokumentation finden Sie unter Security posture assessments for AD CS.

Darüber hinaus behält MDI den laufenden AD-CS-Betrieb im Blick. Beantragt jemand ein Zertifikat für eine fremde Identität oder nutzt eine bekannte Schwachstelle aus, meldet das Portal dies umgehend. Wer einschätzen möchte, wie das mit der hybriden Identität aus Entra Connect zusammenspielt, sollte sich meinen Beitrag Entra Cloud Sync vs. Connect Sync: Hybrid Identity 2024 ansehen.

Die MDI-Assessments machen typische AD-CS-Schwachstellen sichtbar

Die folgende Mermaid-Grafik zeigt, wie eine fehlerhafte Zertifikatvorlage (ESC1) ohne AD-CS-Härtung einen direkten Angriffsweg bis zu Domain-Admin-Rechten eröffnet:

flowchart TD
    User["Benutzer"] --> Template["Fehlkonfigurierte Vorlage"]
    Template --> ADCS["AD CS Server"]
    ADCS --> Cert["Zertifikat für beliebigen Anwender"]
    Cert --> AD["Active Directory"]
    AD --> DomainAdmin["Domain Admin Rechte"]

Abbildung: Eine ESC1-Schwachstelle in AD CS ohne Härtung als direkter Pfad zum Domain-Admin.

In größeren Umgebungen sind die MDI-Assessments eine echte Hilfe, um bei vielen Templates den Überblick zu behalten. Sie zeigen kritisch konfigurierte Vorlagen an und begründen jeweils, warum diese riskant sind. Typische Gründe sind die Extended Key Usage „Any Purpose“ oder Enrollment-Berechtigungen, die für breite Gruppen offenstehen.

Diese Härtungsschritte setze ich bei AD-CS-Templates regelmäßig um

Ein gründliches PKI-Review ersetzt MDI selbstverständlich nicht. Für den Einstieg in eine gezielte AD-CS-Härtung eignet es sich aber gut. Diese Maßnahmen setze ich regelmäßig um:

  • „Enrollee supplies subject“ bei allen Vorlagen auf ein Minimum reduzieren
  • Enrollment-Berechtigungen auf die kleinstmögliche Gruppe beschränken
  • Nachvollziehbare Genehmigungen (Manager Approval) für sensible Vorlagen aktivieren
  • Wo möglich, „StrongCertificateBindingEnforcement“ aktivieren (ab 2022)
  • Alte, nicht mehr benötigte Templates und Enrollment Agents entfernen

Praxistipp: Sichern Sie die Templates vor jeder Änderung mit Certutil und spielen Sie die Enrollment-Prozesse vorher mit Testgruppen durch. Vor allem Altanwendungen sorgen bei Zertifikatfeldern und Key Usage immer wieder für Überraschungen.

Wie die Sensoren mit verschiedenen Rollen zusammenarbeiten, beschreibt auch die Microsoft-Dokumentation zu AD FS und Zertifikaten mit Defender for Identity.

MDI schlägt bei verdächtigen Zertifikatanfragen in Echtzeit Alarm

Ihre eigentliche Stärke spielt Defender for Identity bei der Sichtbarkeit aus. Neben Fehlkonfigurationen erkennt MDI auch, wenn ein Benutzer (oder Angreifer) versucht, ein Zertifikat für eine fremde Identität zu beantragen, und warnt sofort. Diese Alerts landen im Defender-Portal unter „Incidents“ und verweisen direkt auf die betroffene AD-CS-Schwachstelle. In meinen Projekten lieferten sie oft den ersten Hinweis auf einen Angriffsweg, den bis dahin niemand bemerkt hatte.

Für eine tiefere Analyse lassen sich im Defender-Portal eigene Abfragen auf die MDI-Daten ausführen, etwa um alle Anfragen nach hochprivilegierten Zertifikaten aufzulisten. Dafür brauchen Sie eine passende Lizenz, z. B. Microsoft 365 E5 Security. Weitere Details finden Sie unter Was ist Defender for Identity?.

AD-CS-Härtung ist Pflicht, und Defender for Identity weist den Weg

Auch 2025 wird AD CS als Risiko häufig unterschätzt. MDI liefert jedoch die Werkzeuge, mit denen sich die Schwachstellen erkennen und in den Griff bekommen lassen. Aus meiner Sicht ergeben Security Posture Assessments, installierte Sensoren und gezielte Template-Reviews zusammen die beste Grundlage, um AD CS ohne großen Aufwand auf ein sicheres Niveau zu bringen. Wer einmal miterlebt hat, wie schnell ein „altes“ Template zur Übernahme der Domäne führt, wird seine PKI nie wieder sich selbst überlassen.