AutoEnroll

Windows Zertifizierungsstellen erlauben ein automatisches Enrollment von Zertifikaten. Diese an sich ganz nette Funktion erlaubt es z.B., dass Domänenbenutzer oder Computer automatisch ein Zertifikat bekommen um sich per 802.1x am Switch oder oder WIFI-AccessPoint anzumelden. Allerdings kann dies auch "nach hinten" los gehen, wenn die Clients dann damit unkontrolliert Dateien per EFS oder Mails per SMIME verschlüsseln und Sie als Administrator sich nicht über ein "Key Recovery" Gedanken gemacht haben.

Das Problem mit OAB

Ein Problem wird den meisten Administratoren erst dann offenbar, wenn bei der Generierung des Exchange Offline Adressbuchs plötzlich Fehler erscheinen:

Oder als Text-Auszug, damit die Suchmaschinen das auch finden können

Ereignistyp: Fehler
Ereignisquelle: MSExchangeSA
Ereigniskategorie: OAL-Generator
Ereigniskennung: 9321
Beschreibung:
OALGen konnte für den Eintrag 'Administrator' keine vollständigen Detailinformationen erstellen, weil die Gesamtgröße der Detailinformationen größer als 64 KB ist.

Bei der Suche nach diesem Fehler ist dann aufgefallen, dass dieser Benutzer "sehr viele" Zertifikate hatte

Per ADSIEDIT kann ich das Feld ebenfalls anzeigen lassen:

Ein Zertifikat ist je nach Schlüssellänge in der Regel 1-4kByte lang, so dass bei vielen "Versuchen" mit Zertifikaten schnell die 64kbit Grenze für das Offline Adressbuch erreicht ist.

Beschränken Sie AutoEnrollment
Sie sollten ein "wildes" Autoenrollment rechtzeitig in die Grenzen weisen. Zertifikate für die Authentifizierung von Computern sind für alle sinnvoll, Webserver Zertifikate für die Benutzer, die auch Webserver verwalten aber SMIME-Zertifikate sollten vielleicht nicht per Autoenroll verteilt werden.

Das viel kritischere Problem

Nun könnten Sie sagen, dass die internen Zertifikate ja nichts kosten aber das ist etwas kurz gedacht. Stellen Sie sich mal vor, sie sind ein Anwender, der sich an mehreren PCs anmeldet und jeder PC fordert nun für den Anwender ein eigenes Zertifikat an. Am Ende sind ihnen als Benutzer im Active Directory mehrere Zertifikate zugeordnet, die für SMIME und andere Zwecke genutzt werden können. Viel unangenehmer ist aber, dass zu jedem Zertifikat Auch ein "Private Key" gehört und auf jedem PC ist ein eigener Key. Das kann dazu führen, dass ihnen jemand eine Mail verschlüsselt sendet und Sie diese nur auf genau dem einem PC lesen können, auf dem auch der passende private Schlüssel dazu vorliegt.

Sie müssen also zum einen dafür sorgen, dass jeder Benutzer am besten immer nur ein Zertifikat hat, welches nach Ablauf auch einfach verlängert wird und dass diese Zertifikat mit dem Benutzer "mitzieht". Dazu gibt es gleich mehrere Optionen:

In allen Fällen müssen sie aber sicherstellen, dass die "AutoEnroll"-Funktion nicht schon Zertifikate anfordert, wenn sich der Mitarbeiter das erste Mal an einem Client anmeldet und seine eigenen Zertifikate noch nicht importiert sind.

AutoEnrollment steuern

Damit AutoEnrollment funktioniert, müssen mehrere Dinge zusammenpassen.

Das sind dann natürlich auch die Hebel, über die ein Administrator diese Funktion steuern kann und z.B. nur bestimmte Vorlagen für "AutoEnrollment" zulässt und selbst hier noch über Sicherheitsgruppen geht.

Enrollment Prozesse ohne Automatik

Wenn ihnen diese Automatik nun suspekt ist und sie doch lieber als CA-Administrator anstehende Zertifikatanforderungen für wichtige Zertifikate (z.B. SMIME) erst von Hand freigeben wollen, dann ist dies natürlich möglich. Eine passende Änderung der Berechtigung an den Vorlagen erlaubt, dass die Anwender ein Zertifikat zwar anfordern aber ein CA-Admin dieses erst nach einer Prüfung ausstellen muss.

Kleiner Tipp: Sie können ihre CA so einstellen, dass ausstehende Anforderungen ihnen per Mail zugesendet werden.

certutil -setreg exit\smtp\smtpserverServerName
certutil -setreg exit\smtp\CRLIssued\To caadmin@firma.tld
certutil -setreg exit\smtp\CertPending\To caadmin@firma.tld
certutil -setreg exit\smtp\Startup\To caadmin@firma.tld
certutil -setreg exit\smtp\Shutdown\To caadmin@firma.tld

Alternativ könnte mal geprüft werden, ob die Ausstellung nach Ablauf einer Wartezeit auch automatisch z.B. per Skript erfolgen könnte. Hierzu konnte ich aber noch keine weiteren Experimente durchführen.

Zertifikate und private Schlüssel sichern !

Wenn Sie nun Zertifikate auf den Client eventuell schon per AutoEnrollment verteilt haben und die vorbereitenden Schritte zur Sicherung des privaten Schlüssels aus der CA vergessen oder mangels Enterprise Lizenz nicht aktiviert haben, dann sollten Sie sich schon mal Gedanken machen, wie die die Zertifikate samt privatem Key entsprechend sichern. Denn wenn das Zertifikat (d.h. der Public Key) über das Active Directory für alle Outlook Benutzer im Forest erreichbar wird, können diese sehr einfach auch Mails "verschlüsselt" senden. Eine "Sicherung" der privaten Schlüssel ist daher ratsam aber wird von vielen Anwendern nicht vernünftig durchgeführt. Ein Roaming Profile ist auch kein rechter Schutz, denn wenn der Benutzer das Kennwort vergisst, dann können Sie es als Administrator zwar "zurücksetzen", aber ein Zugriff auf die privaten Schlüssel ist damit dennoch nicht möglich, weil der "Protected Store" zusätzlich gesichert ist.

Es ist durchaus denkbar, per Software eine "Sicherung" der Schlüssel samt privatem Key z.B. auf einen Dateiserver oder ein anderes Medium durchzuführen. Ein fertiges Programm habe ich bislang aber nicht gefunden. Firmen mit Active Directory fahren mit dem "Zertifikat Roaming" oder "Roaming Profiles" am besten. Einzelpersonen sollten ihr System entsprechend sichern oder beim Erhalt eines Zertifikats manuell eine Kopie an einem anderen Ort hinterlegen.

CAPICOM 2.1.0.2
http://www.microsoft.com/downloads/details.aspx?FamilyId=860EE43A-A843-462F-ABB5-FF88EA5896F6&displaylang=en

Security Update for CAPICOM (KB931906) (for Capicom prior to 2.1.0.2)
http://www.microsoft.com/downloads/details.aspx?FamilyId=CA930018-4A66-4DA6-A6C5-206DF13AF316&displaylang=en

Weitere Link

Keywords:AutoEnroll PFX Backup