AD CS Security 2026 – technische und organisatorische Praxis für Unternehmen.
Viele Unternehmen schützen Domain Controller sorgfältig, betrachten aber ihre interne Zertifizierungsstelle nur bei der Verlängerung eines TLS-Zertifikats. Das ist gefährlich: Active Directory Certificate Services (AD CS) können Zertifikate ausstellen, die für Benutzer- oder Computeranmeldungen verwendet werden. Eine falsch konfigurierte Zertifikatvorlage kann damit eine unbeabsichtigte Abkürzung zu besonders sensiblen Identitäten schaffen. Dieser Leitfaden zu AD CS Security 2026 erläutert, wie Sie Zertifikatsvorlagen, Enrollment-Rechte, Web Enrollment und Recovery zusammenhängend bewerten und absichern. Er richtet sich an Windows-Administratoren und Sicherheitsverantwortliche in Unternehmen mit lokalen oder hybriden Active-Directory-Umgebungen.
Was AD CS für Identität und Sicherheit bedeutet
AD CS stellt eine Public Key Infrastructure für interne Zertifikate bereit. Darunter fallen TLS-Zertifikate für Server, Client-Authentifizierung, Computerzertifikate für WLAN und VPN sowie andere Anwendungsfälle. Entscheidend ist der Ausstellungsprozess: Nicht jeder, der ein Zertifikat beantragen kann, darf damit jede beliebige Identität repräsentieren. Die Konfiguration von Vorlagen bestimmt, welche Identität in einem Zertifikat erscheint, welche Nutzung zugelassen ist und wer den Antrag stellen darf.
Eine Enterprise Certification Authority ist mit Active Directory verbunden. Ihre Zertifikatvorlagen werden im Verzeichnis gespeichert und sind über die Gesamtstruktur verfügbar; veröffentlicht wird jede Vorlage an den dafür vorgesehenen ausstellenden CAs. Bei einer Prüfung müssen Sie daher sowohl AD-Berechtigungen auf den Vorlagen als auch die tatsächlich veröffentlichte Konfiguration auf jeder CA erfassen. Eine Sicherheitsfreigabe nur auf Ebene eines einzelnen Servers übersieht mögliche alternative Ausstellungswege.
Angriffsflächen der Zertifizierungsstelle inventarisieren
Beginnen Sie mit einer Liste aller Root- und Issuing-CAs, deren Betriebssystemstände, Dienstkonten, administrativen Zugriffe, Enrollment-Endpunkte und veröffentlichten Vorlagen. Dokumentieren Sie dabei auch CA-Web-Enrollment, Certificate Enrollment Web Services, NDES/SCEP und mögliche Schnittstellen für Mobile Device Management. Oft existieren alte Zertifizierungsstellen, die technisch weiter signieren, obwohl niemand mehr einen klaren Eigentümer benennen kann.
Ordnen Sie jeder CA den Einsatzbereich und die betroffenen Geschäftsprozesse zu. Welche Authentifizierungsdienste vertrauen ihren Zertifikaten? Welche CRL- und AIA-Endpunkte müssen erreichbar bleiben? Welche Vorlage wird von einer geschäftskritischen Fachanwendung benötigt? Dieses Inventar ist die Grundlage für ein kontrolliertes Hardening: Wer einen Enrollment-Endpunkt deaktiviert, ohne Abhängigkeiten zu prüfen, kann VPN-Anmeldungen oder Geräte-Zertifikatserneuerungen unterbrechen.
AD CS Security 2026: Gefährliche Enrollment-Rechte erkennen
Auf Zertifikatvorlagen sind die Rechte Read, Enroll, Autoenroll und administrative Änderungsrechte zu unterscheiden. Wenn sehr breite Gruppen Zertifikate für eine Vorlage beantragen dürfen, die für interaktive Anmeldung geeignet ist, entsteht in Verbindung mit weiteren Fehlkonfigurationen ein Sicherheitsrisiko. Besonders wichtig sind EKUs wie Client Authentication und Smart Card Logon. Zugriffsrechte sollten anhand des konkreten Einsatzzwecks und der benötigten Nutzer- beziehungsweise Computergruppen vergeben werden.
Prüfen Sie außerdem, wer Vorlagen verändern, die Sicherheitsbeschreibung bearbeiten oder zusätzliche Vorlagen an der CA veröffentlichen kann. Solche Verwaltungsrechte sind kritischer als das bloße Lesen. Ein Assessment sollte für jede sensible Vorlage den vorgesehenen Besitzer, die berechtigten Antragsteller und die berechtigten Änderungsadministratoren dokumentieren. Verwenden Sie kleine Pilotgruppen und testen Sie ausdrücklich, dass unberechtigte Identitäten keinen Antrag stellen können.
ESC1: Warum Subject Alternative Names kontrolliert werden müssen
Das als ESC1 bekannte Risiko entsteht unter bestimmten Voraussetzungen, wenn Antragsteller bei einer für Authentifizierung nutzbaren Vorlage die Identität im Zertifikatsantrag selbst bestimmen können. Besonders problematisch wird das bei breiten Enrollment-Rechten und fehlenden Genehmigungsschritten. Die Abwehr besteht nicht in einer pauschalen Entfernung aller SAN-Felder, denn viele TLS- und Fachanwendungszertifikate benötigen legitime Subject Alternative Names.
Trennen Sie Vorlagen für serverseitige TLS-Zertifikate von Vorlagen für Benutzer- oder Computeranmeldung. Wo eine Identität aus AD abgeleitet werden kann, bevorzugen Sie eine von der Zertifizierungsstelle ermittelte Zuordnung. Wenn eine antragstellende Person Subjektinformationen liefern muss, setzen Sie eng begrenzte Enrollment-Rechte, geeignete Prüfungen und gegebenenfalls einen Genehmigungsprozess ein. Der Nachweis einer riskanten Einstellung sollte dokumentiert und vor produktiven Änderungen mit zuständigen Anwendungsverantwortlichen bewertet werden.
ESC8: Web Enrollment, NTLM und Extended Protection
AD CS kann Zertifikatsanträge über IIS-basierte Dienste entgegennehmen. Unsichere Web-Enrollment-Endpunkte mit NTLM-Authentifizierung und unzureichender Kanalbindung gehören zu den klassischen Risiken, die häufig unter ESC8 zusammengefasst werden. Ein falsch gesicherter Endpunkt kann NTLM-Relay-Szenarien begünstigen. Welche Abwehr greift, hängt vom konkreten Endpoint, Authentifizierungsmechanismus und dem bereitgestellten Dienst ab.
Inventarisieren Sie sämtliche HTTPS- und gegebenenfalls noch vorhandenen HTTP-Endpunkte. Prüfen Sie verpflichtende TLS-Verbindungen und, wo der Dienst es unterstützt, Extended Protection for Authentication (EPA). Deaktivieren Sie nicht benötigte Enrollment-Webdienste. Änderungen an IIS-Authentifizierung und EPA sollten mit mehreren legitimen Clients getestet werden, insbesondere bei älteren Anwendungen oder Geräten. Ein erfolgreicher Funktionstest nach der Umstellung ist genauso wichtig wie die kontrollierte Schließung der Fehlkonfiguration.
Starke Zertifikatszuordnung in Windows-Umgebungen
Ein vertrauenswürdiges Zertifikat ist nicht automatisch eindeutig mit einem AD-Benutzer verbunden. Bei zertifikatsbasierter Anmeldung müssen Domain Controller die Identität des Zertifikatsinhabers zuverlässig zuordnen. Microsoft hat das Thema starke Zertifikatszuordnung über mehrere Sicherheitsupdates weiterentwickelt. Für die Sicherheitsbewertung zählt, welche Zuordnungs- und Ausnahmeregelungen tatsächlich aktiv sind und ob ausgegebene Zertifikate die benötigten Identitätsinformationen enthalten.
Lassen Sie die Anmeldefunktion für Smartcards, Wi-Fi, VPN und mögliche Drittanbieter-Authentifizierung nach einer Änderung kontrolliert testen. Prüfen Sie insbesondere selbst ausgestellte Vorlagen, manuell gepflegte Mappings und Anwendungen, die ein Zertifikat zwar akzeptieren, aber nicht die vorgesehene Kontenidentität kontrollieren. Die richtige Sicherheitsmaßnahme ist eine nachvollziehbare Identitätsbindung, nicht das unüberlegte Deaktivieren von Zertifikatsauthentifizierung.
PKI-Administrationsrechte strikt trennen
CA-Administratoren, Zertifikatsmanager, Backup-Verantwortliche und Domain-Administratoren benötigen unterschiedliche Befugnisse. Ein allgemeines Supportkonto sollte weder die CA-Konfiguration verändern noch beliebige Zertifikate für privilegierte Identitäten ausstellen können. Vergeben Sie Rechte personenbezogen, schützen Sie administrative Sitzungen mit geeigneter starker Authentifizierung und dokumentieren Sie jede Ausnahme.
Besonders kritisch sind die privaten Schlüssel von Root- und ausstellenden Zertifizierungsstellen. Bewerten Sie den Einsatz eines geeigneten Hardware Security Module (HSM) entsprechend dem Schutzbedarf. Nutzen Sie für die CA einen reduzierten Softwarebestand und verwalten Sie den Server getrennt vom normalen Office-Desktop. Ein kompromittierter CA-Schlüssel kann weitreichendere Folgen haben als der Ausfall eines einzelnen Anwendungsservers, weshalb Notfallverfahren und Schlüsselverwaltung besonders streng behandelt werden müssen.
Zertifikatsvorlagen sicher neu erstellen und ablösen
Microsoft empfiehlt, eine geeignete vorhandene Vorlage zu duplizieren und eine neue Vorlage zunächst an einem engen Pilotkreis zu erproben. Dokumentieren Sie den Unterschied zwischen dem Anzeigenamen und dem internen Vorlagennamen. Prüfen Sie Kompatibilität, EKUs, Schlüsselverwendung, Subject-Name-Regeln, Gültigkeitsdauer und Enroll-/Autoenroll-Rechte. Änderungen an gemeinsam verwendeten Vorlagen können ansonsten viele Dienste gleichzeitig betreffen.
Führen Sie neue Vorlagen neben alten ein, testen Sie Neu-Ausstellung und Erneuerung und planen Sie anschließend eine geregelte Ablösung. Eine Vorlage aus der CA-Veröffentlichung zu entfernen ist nicht identisch mit ihrer Löschung aus Active Directory. Kontrollieren Sie, ob noch Anwendungen auf alte Zertifikate angewiesen sind und ob deren Vertrauensketten gültig bleiben. Bereinigen Sie verwaiste Vorlagen erst nach technischer und fachlicher Abnahme.
CA-Logs und Zertifikatsausstellung überwachen
Für eine prüfbare PKI müssen sicherheitsrelevante Änderungen sichtbar werden: neue oder veränderte Vorlagen, Änderungen an CA-Rechten, ungewöhnliche Zertifikatsanträge und administrative Tätigkeiten. Nutzen Sie die dokumentierten Windows-Auditkategorien der Zertifizierungsstelle und kombinieren Sie sie mit Verzeichnis- und Authentifizierungsereignissen. Einzelne Events dürfen nicht ohne Kontext als Angriff interpretiert werden.
Richten Sie Eskalationsregeln für Anomalien ein, beispielsweise viele fehlgeschlagene Anträge für sensible Vorlagen oder eine unerwartete Änderung von Enrollment-Rechten. Speichern Sie Protokolle so, dass sie nicht ausschließlich vom CA-Administrator verändert oder gelöscht werden können. Ein Bericht sollte nachvollziehbar zeigen, welche Zertifikate von welchen Vorlagen ausgegeben wurden und ob die Antragstellung im Rahmen der genehmigten Prozesse erfolgte.
CRL, OCSP und Verfügbarkeit berücksichtigen
Ein Zertifikat kann technisch korrekt ausgestellt sein und trotzdem im Einsatz ausfallen, wenn Clients seine Sperrinformationen nicht erreichen. Certificate Revocation Lists (CRL) und gegebenenfalls Online Certificate Status Protocol (OCSP) gehören deshalb zur Betriebsarchitektur. Planen Sie erreichbare Verteilungspunkte, Ablaufzeiten und Monitoring für Zertifikats- und Sperrlistenveröffentlichungen.
Vermeiden Sie sicherheitskritische Änderungen an AIA- oder CRL-URLs ohne Migrationskonzept: Bestehende Zertifikate können alte URLs über Jahre enthalten. Testen Sie, ob Clients in Zweigstellen, VPN-Szenarien und isolierten Netzbereichen die richtigen Sperrinformationen erhalten. Eine zentralisierte CA ist nicht automatisch hochverfügbar; insbesondere Offline-Root-CAs haben andere Wartungs- und Notfallanforderungen als Online-Issuing-CAs.
Backup und Recovery der Zertifizierungsstelle
Eine CA lässt sich nicht allein durch die Wiederherstellung ihres Windows-Servers ersetzen. Für Recovery werden je nach Architektur CA-Datenbank, Konfiguration, Zertifikate, private Schlüssel und die relevanten Verzeichnisinformationen benötigt. Dokumentieren Sie die Sicherung und Aufbewahrung entsprechend dem Schutzbedarf. Private Schlüssel dürfen nicht unverschlüsselt in allgemeinen Backup-Pfaden oder Tickets abgelegt werden.
Testen Sie die Wiederherstellung isoliert und prüfen Sie, ob ein wiederhergestelltes CA-System korrekt startet, Zertifikatsketten validiert und Sperrlisten bereitstellt. Notfallprozesse müssen auch dann funktionieren, wenn Teile von AD kompromittiert oder nicht erreichbar sind. Legen Sie die Verantwortlichkeiten für Widerruf, Erneuerung und Wiederaufnahme der Ausstellung vor einem Vorfall fest – mitten in einer kompromittierten PKI ist es dafür zu spät.
30-Tage-Plan für AD CS Security 2026
Woche eins: CAs, Web-Enrollment-Services, veröffentlichte Zertifikatsvorlagen und geschäftskritische Anwendungen inventarisieren. Woche zwei: sensible Vorlagen und Zugriffsrechte anhand eindeutiger Prüfkriterien bewerten, insbesondere Enrollment, Subject Names und Benutzeranmeldung. Woche drei: Pilotmaßnahmen für Vorlagen, IIS-Hardening und administrative Trennung durchführen. Woche vier: Monitoring, Backup-/Restore-Nachweis und Rollback der Änderungen testen.
Jede Maßnahme benötigt einen Besitzer und eine Abnahme. Dokumentieren Sie pro Befund den betroffenen Dienst, das tatsächliche Risiko, die geplante Änderung und den Testnachweis. Die wichtigste Kennzahl ist nicht die Zahl gelöschter Vorlagen, sondern der Anteil kritischer Zertifikatsausstellungswege mit nachvollziehbaren Berechtigungen, geprüfter Identitätszuordnung und erfolgreich getestetem Recovery.
Häufige Fragen zu AD CS Security 2026
Ist jede AD-CS-Installation automatisch unsicher?
Nein. Die Risiken ergeben sich aus konkreten Konfigurationen, Berechtigungen, Enrollment-Endpunkten und der Nutzung ausgegebener Zertifikate.
Muss Web Enrollment abgeschaltet werden?
Nicht pauschal. Nicht benötigte Dienste sollten entfernt werden; benötigte Endpunkte müssen angemessen durch TLS, Authentifizierungs- und Relay-Schutz abgesichert werden.
Reicht ein einmaliger AD-CS-Penetrationstest?
Er hilft, ersetzt aber nicht die regelmäßige Prüfung von Template-Änderungen, Berechtigungen, CA-Logs und Recovery.
Ist das Löschen einer unsicheren Vorlage immer die beste Lösung?
Nein. Häufig ist die gezielte Korrektur mit Pilotmigration sicherer als das sofortige Entfernen einer Vorlage, die noch produktiv genutzt wird.
Fazit: PKI muss als Identitätssystem geschützt werden
AD CS Security 2026 ist keine einmalige Prüfung der Zertifizierungsstelle, sondern ein Betriebsprozess. Besonders wertvoll ist eine Kombination aus eindeutig verantworteten Zertifikatvorlagen, kontrollierten Ausstellungsrechten, nachvollziehbaren Logs und wiederholbaren Recovery-Tests. Planen Sie Änderungen schrittweise und vermeiden Sie ungeprüfte Eingriffe in produktive Authentifizierungsdienste.
Über den Autor
Salman Dolatpanah Gortlar schreibt für GORTNET über Windows-Administration, Active Directory und IT-Sicherheit. Der Beitrag vermittelt einen technisch orientierten Prüf- und Umsetzungsrahmen; er ist kein Audit einer konkreten Unternehmensumgebung.
Weiterführende Artikel und IT-Beratung
Für eine technische PKI-Bestandsaufnahme und einen priorisierten Maßnahmenplan können Unternehmen GORTNET kontaktieren.
Offizielle Quellen
- Microsoft: Manage Certificate Templates
- Microsoft: Certificate Template Concepts
- Microsoft: CA Web Enrollment
Redaktionsstand: 28. Oktober 2026. Änderungen an PKI und Authentifizierungsdiensten nur nach dokumentierter Prüfung und Test im vorgesehenen Betriebsumfeld durchführen.