ADCS Auto Enrollment
Zertifikate automatisch verteilen – ohne manuelle Klicks und ohne Ablaufdaten-StressAuto-Enrollment konfigurieren – Templates, GPO, Troubleshooting
Auto-Enrollment ist die Funktion, die deine PKI von „läuft technisch“ zu „läuft im Betrieb“ bringt: Computer und Nutzer bekommen ihre Zertifikate automatisch, ohne dass jemand klickt, und Erneuerungen passieren im Hintergrund. Klingt simpel, scheitert in der Praxis aber fast immer an genau drei Stellen – falsche Template-Berechtigung, vergessene Veröffentlichung auf der CA und eine GPO, die am Client gar nicht greift. Mein Rat: Bau Auto-Enrollment von Anfang an mit einer dedizierten Sicherheitsgruppe und einer sauberen Vorlage auf, dann ersparst du dir 90 Prozent der späteren Telefonate mit dem Helpdesk.
Abb. 1: Auto-Enrollment-Ablauf zwischen GPO, AD DS, Template Store und Issuing CA.
1. Was beim Auto-Enrollment wirklich passiert
Bevor du an Schaltern drehst, lohnt sich das mentale Modell. Auto-Enrollment ist kein einzelner Schalter, sondern ein Zusammenspiel aus vier Komponenten: einer Group Policy, die das Verhalten am Client aktiviert; einer Zertifikatsvorlage mit den richtigen Berechtigungen; der Issuing CA, auf der diese Vorlage veröffentlicht sein muss; und dem Client selbst, der bei jedem Logon und in regelmäßigen Abständen prüft, ob er etwas Neues braucht.
Der Client fragt dabei nicht „CA, gib mir ein Zertifikat“, sondern arbeitet eine Liste ab: Welche Vorlagen darf ich überhaupt sehen (Read), welche darf ich anfordern (Enroll), und für welche ist das Auto-Enroll-Recht gesetzt? Nur die letzte Kategorie wird ohne Nutzerinteraktion ausgerollt. Genau hier liegt die erste Stolperfalle: Read und Enroll reichen für die manuelle Anforderung über die MMC, aber eben nicht für die automatische.
Die Erneuerung folgt derselben Logik. Erreicht ein Zertifikat den im Template definierten Renewal-Zeitpunkt (Standard: 80 Prozent der Gültigkeitsdauer), fordert der Client automatisch ein neues an. Das ist der eigentliche Charme – du musst dich um Ablaufdaten nie wieder kümmern, vorausgesetzt, das Fundament steht.
2. Die GPO richtig setzen – und am richtigen Ort
Auto-Enrollment wird über zwei getrennte Policy-Einstellungen aktiviert: einmal in der Computer-Konfiguration für Maschinenzertifikate, einmal in der Benutzer-Konfiguration für Nutzerzertifikate. Beide findest du unter Windows-Einstellungen → Sicherheitseinstellungen → Richtlinien für öffentliche Schlüssel → Zertifikatdienstclient – Automatische Registrierung. Setz die Einstellung auf „Aktiviert“ und hak beide Folgeoptionen an: abgelaufene Zertifikate erneuern und Zertifikate mit geänderten Vorlagen aktualisieren.
Die spannendere Frage ist nicht das Ob, sondern das Wo. Eine Autoenroll-GPO an die Domain-Root zu hängen ist bequem, verteilt aber Zertifikate an wirklich jedes Objekt – inklusive der Maschinen, die du eigentlich nie im Blick hattest. Für reine Computer-Zertifikate ist das oft akzeptabel, für Nutzerzertifikate selten. Die saubere Variante ist die Steuerung über eine Sicherheitsgruppe.
Abb. 2: Drei Strategien, wo die Autoenroll-GPO verankert wird – mit klarer Empfehlung.
Meine Standardempfehlung im Mittelstand: GPO mit Security-Filtering auf eine Gruppe wie GG_Autoenroll_User verknüpft, dazu die passenden Konten in dieser Gruppe. So entscheidest du über Gruppenmitgliedschaft, wer Zertifikate bekommt – unabhängig davon, wie chaotisch die OU-Struktur historisch gewachsen ist.
|
Info · Verweis Welche Vorlagen-Version du für Auto-Enrollment wählst, hat direkte Auswirkungen auf Kompatibilität und Schlüsselattestierung. Den Vergleich v2 / v3 / v4 zeigt Spoke 3.2 „Zertifikatsvorlagen v2 vs. v3 vs. v4 – wann was?“ im Detail. |
|---|
3. Die Vorlage vorbereiten – Berechtigungen, die wirklich zählen
Die Vorlage ist das Herzstück. Dupliziere nie die mitgelieferten Standardvorlagen direkt, sondern leg dir eine Kopie an (Rechtsklick → Vorlage duplizieren) und vergib einen sprechenden Namen wie Musterwerk-Computer-Authentication. Auf dem Reiter „Sicherheit“ vergibst du der Zielgruppe genau drei Rechte: Lesen, Registrieren und Automatisch registrieren. Fehlt das dritte, passiert beim Auto-Enrollment schlicht nichts – und zwar völlig lautlos, ohne Fehlermeldung am Client.
Auf dem Reiter „Anforderungsverarbeitung“ entscheidest du, ob der private Schlüssel exportierbar sein soll. Für Maschinenzertifikate: nein. Für S/MIME-Verschlüsselung mit Key-Archival: anders gelagert, aber das ist ein eigenes Thema. Auf „Antragstellername“ legst du fest, ob der Subject-Name aus dem AD gebaut wird – für Auto-Enrollment fast immer „Aus diesen Active Directory-Informationen erstellen“.
Berechtigungs-Übersicht auf einen Blick
|
Recht |
Wofür nötig |
Bei Auto-Enrollment |
|---|---|---|
|
Lesen (Read) |
Vorlage überhaupt sehen |
Pflicht |
|
Registrieren (Enroll) |
Manuelle Anforderung |
Pflicht |
|
Automatisch registrieren |
Ausrollen ohne Klick |
Pflicht – der häufig vergessene |
|
Vollzugriff |
Vorlage ändern |
Nur Admins, nie der Zielgruppe |
4. Auto-Enrollment per PowerShell prüfen und ausrollen
Die GUI ist gut zum Verstehen, die Konsole ist gut zum Arbeiten. Mit dem PSPKI-Modul und Bordmitteln prüfst du in wenigen Zeilen, welche Vorlagen veröffentlicht sind, ob die Berechtigungen passen und ob ein Client gerade einen Pulse-Lauf braucht.
|
PowerShell # Welche Vorlagen sind auf der Issuing CA veroeffentlicht? # Bordmittel, kein Zusatzmodul noetig certutil -CATemplates | Select-String "Name"
# Auto-Enroll-Recht einer Vorlage pruefen (PSPKI-Modul) Import-Module PSPKI Get-CertificateTemplate -Name "Musterwerk-Computer-Authentication" | Get-CertificateTemplateAcl | Select-Object -ExpandProperty Access | Where-Object { $_.Rights -match "Autoenroll" } | Format-Table IdentityReference, Rights -AutoSize
# Client sofort zum Enrollment zwingen (statt aufs naechste Logon zu warten) certutil -pulse
# Ausgestellte Zertifikate im lokalen Computer-Store kontrollieren Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, Thumbprint | Sort-Object NotAfter |
|---|
Der Befehl certutil -pulse ist dein bester Freund beim Testen: Er triggert den Auto-Enrollment-Lauf sofort, statt dass du dich aus- und wieder einloggen musst. Im Computer-Kontext läuft das Pendant über certutil -pulse in einer administrativen Konsole.
5. Troubleshooting – wenn kein Zertifikat ankommt
Fast jedes Auto-Enrollment-Problem lässt sich auf eine von vier Ursachen zurückführen. Statt wild zu raten, arbeitest du den Entscheidungsbaum von oben nach unten ab. Das spart Zeit und führt dich zuverlässig zur Wurzel.
Abb. 3: Der Troubleshooting-Pfad – vier Prüfpunkte, ein klares Vorgehen.
Die mit Abstand häufigste Ursache aus meinem Beratungsalltag: Die Vorlage wurde dupliziert und konfiguriert, aber nie auf der Issuing CA veröffentlicht. In der CA-MMC unter „Zertifikatvorlagen → Neu → Auszustellende Zertifikatvorlage“ fehlt schlicht der Eintrag. Der Client sieht die Vorlage dann gar nicht und schweigt.
Die zweithäufigste: Cache. Nach Änderungen an Berechtigungen oder Template-Version dauert es, bis der Client das mitbekommt. gpupdate /force aktualisiert die Policy, certutil -pulse triggert den Enrollment-Lauf. Auf dem Event-Log-Kanal Applications and Services → Microsoft → Windows → CertificateServicesClient siehst du, was der Client tatsächlich versucht hat.
|
Warnung · Klassische Falle „Erweiterte Schlüsselverwendung“ falsch gesetzt. Eine Vorlage für Computer-Authentifizierung braucht die EKU „Clientauthentifizierung“ (und ggf. Serverauthentifizierung). Wer aus einer S/MIME-Vorlage dupliziert und die EKU nicht anpasst, rollt flächendeckend Zertifikate aus, die für den eigentlichen Zweck unbrauchbar sind. Das fällt oft erst Wochen später beim 802.1X-Login auf – und dann ist die halbe Flotte betroffen. |
|---|
|
Praxis-Tipp · Aus dem Beratungsalltag Test immer mit einem dedizierten Testkonto und einer Test-Maschine in einer eigenen OU, bevor du die GPO breit verknüpfst. Ich lege bei jedem Projekt eine OU _PKI-Test an, hänge die GPO zuerst nur dort hin und prüfe mit certutil -pulse plus Event-Log. Erst wenn ein Testzertifikat sauber im Store landet, geht die Verknüpfung produktiv. Das kostet fünf Minuten und verhindert den Flächenbrand. |
|---|
Praxis-Beispiel: Musterwerk GmbH
Die Musterwerk GmbH, ein Industrie-Mittelständler mit rund 1.200 Mitarbeitern, wollte 802.1X-Authentifizierung im WLAN über Maschinen- und Nutzerzertifikate ausrollen. Ausgangslage: zweistufige ADCS-Umgebung stand, aber die Zertifikate wurden bis dahin manuell pro Gerät angefordert – ein Helpdesk-Albtraum bei 1.200 Endgeräten.
Die Maßnahme: Zwei dedizierte Vorlagen (Musterwerk-Computer-Authentication und Musterwerk-User-Authentication), je eine Sicherheitsgruppe mit Auto-Enroll-Recht, zwei GPOs mit Security-Filtering auf diese Gruppen. Computer kamen über die Computer-Konfiguration, Nutzer über die Benutzer-Konfiguration. Rollout in Wellen über die Gruppenmitgliedschaft, gestartet mit der IT-Abteilung als Pilotgruppe.
Das Ergebnis: Innerhalb von zwei Wochen waren alle Geräte und Nutzer versorgt, ohne ein einziges manuelles Anfordern. Die Erneuerung läuft seitdem völlig unsichtbar im Hintergrund. Der entscheidende Hebel war nicht die Technik – die stand in einem Tag –, sondern die Steuerung über Gruppen statt über OU-Verknüpfungen.
Verwandte Themen
Häufige Fragen (FAQ)
Wie aktiviere ich Auto-Enrollment in ADCS?
Auto-Enrollment wird über zwei Group-Policy-Einstellungen aktiviert – eine in der Computer-, eine in der Benutzer-Konfiguration unter „Zertifikatdienstclient – Automatische Registrierung“. Zusätzlich muss die Zielgruppe auf der Vorlage das Recht „Automatisch registrieren“ haben und die Vorlage auf der Issuing CA veröffentlicht sein. Erst wenn alle drei Bausteine stimmen, rollt der Client ohne Klick aus.
Warum bekommt mein Client trotz GPO kein Zertifikat?
In den meisten Fällen fehlt entweder das Auto-Enroll-Recht auf der Vorlage oder die Vorlage ist gar nicht auf der CA veröffentlicht. Beides passiert lautlos, ohne Fehlermeldung am Client. Prüf mit certutil -CATemplates, ob die Vorlage ausgestellt wird, und kontrolliere die Berechtigungen auf dem Sicherheits-Reiter der Vorlage.
Was bewirkt der Befehl certutil -pulse?
certutil -pulse triggert den Auto-Enrollment-Lauf am Client sofort, statt aufs nächste Logon oder das Standard-Intervall zu warten. Das ist beim Testen Gold wert, weil du Änderungen an Vorlagen oder GPOs direkt verifizieren kannst. Im Computer-Kontext führst du den Befehl in einer administrativen Konsole aus.
Sollte ich die Autoenroll-GPO an die Domain-Root hängen?
Nur für reine Computer-Zertifikate und auch dann mit Bedacht, weil so wirklich jedes Objekt versorgt wird. Für Nutzerzertifikate empfehle ich Security-Filtering auf eine dedizierte Gruppe. So steuerst du über Gruppenmitgliedschaft, wer Zertifikate bekommt, unabhängig von der OU-Struktur.
Wie funktioniert die automatische Erneuerung?
Erreicht ein Zertifikat den im Template definierten Renewal-Schwellwert – standardmäßig 80 Prozent der Gültigkeitsdauer –, fordert der Client beim nächsten Auto-Enrollment-Lauf automatisch ein neues an. Du musst dich um Ablaufdaten nicht mehr kümmern, solange die Vorlage und die Berechtigungen unverändert gültig sind.
Welche Berechtigungen braucht eine Vorlage für Auto-Enrollment?
Genau drei: Lesen, Registrieren und Automatisch registrieren – vergeben an die Sicherheitsgruppe der Zielobjekte. Lesen und Registrieren allein reichen nur für die manuelle Anforderung. Vollzugriff gehört ausschließlich den Administratoren, niemals der Zielgruppe.
Nächste Schritte mit boddenberg.de
Auto-Enrollment ist genau die Art von Thema, bei der zwischen „läuft technisch“ und „läuft sauber im Betrieb“ ein paar Stunden Erfahrung liegen. Drei Wege, wie ich dich dabei unterstütze:
Schick mir eine kurze Mail mit deinem Szenario, und du bekommst innerhalb eines Werktags eine Einschätzung, welcher Weg am sinnvollsten ist.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund