Ich bin neulich auf das Phänomen getroffen, dass aufgrund einer fehlerhaften Beantragungslogik mehrere Benutzer in regelmäßigen Anständen neue Zertifikatanforderungen gestellt hatten.
Die Zertifikatvorlage war konfiguriert, eingehende Zertifikatanforderungen durch einen Zertifikatmanager freigeben zu lassen, d.h. es erfolgte keine automatische Ausstellung der Zertifkate. Die Zertifikatanforderungen sollten durch einen eigenen Code überprüft und anschließend freigegeben werden.
Man würde nun erwarten, dass (da alle Zertifikatanträge letztendlich genehmigt würden) die Benutzer nun mehrere Zertifikate gleichen Typs in ihrem Zertifikatspeicher (und den Anwendungen, welche diesen nutzen) vorfinden würden. Dem war aber nicht der Fall.
Versuchsaufbau
Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.
Um das Szenario nachzustellen, wurde eine Zertifikatvorlage erstellt und konfiguriert, dass eine Genehmigung durch einen Zertifikatmanager erforderlich war.
Anschließend wurden wiederholt Zertifikatanträge ausgelöst.
(1..20) | ForEach-Object -Process {
certreq -q -enroll "ADCSLaborBenutzerTest"
}
Diese waren nun im lokalen Speicher für Zertifikatanforderungen zu sehen.
Auch auf der Zertifizierungsstelle waren die Zertifikatanforderungen nun aufgelaufen und wurden manuell genehmigt.
Der Abruf der Zertifikate erfolgte durch den Benutzer-Autoenrollment-Task. Eine entsprechende Gruppenrichtlinie mit Einstellung "Renew expired certificates, update pending certificates, and remove revoked certificates" war eingerichtet.
certutil -pulse -user
Zunächst der Schreckmoment, alle Zertifikatanforderungen wurden abgeholt und fanden sich im Zertifikatspeicher des Benutzers wieder.
Nach einem erneuten Lauf des Benutzer-Autoenrollment-Task wurden aber alle Zertifikate bis auf das neueste archiviert, sodass nur eines übrig blieb.
Auch hierfür zeichnet sich die Option Einstellung "Renew expired certificates, update pending certificates, and remove revoked certificates" verantwortlich.
Der Umstand, warum die Archivierung erst beim zweiten Lauf des Benutzer-Autoenrollment-Task erfolgte ist darin begründet, dass erst beim zweiten Lauf alle abgeholten Zertifikate vorlagen, um das neueste zu ermitteln.
Weiterführende Links:
- Grundlagen manuelle und automatische Zertifikatbeantragung über Lightweight Directory Access Protocol (LDAP) und Remote Procedure Call / Distributed Common Object Model (RPC/DCOM)
- Den Autoenrollment Prozess für den angemeldeten Benutzer programmatisch auslösen
- Fehlersuche für die automatische Zertifikatbeantragung (Autoenrollment) via RPC/DCOM
Deutsch 
English