Client Zertifikate und Roaming

Zertifikate werden nicht nur für Webserver und Computer ausgestellt, die sich damit z.B.: gegen Switches identifizieren oder dem Anwender die Möglichkeit zur Identifizierung der Webseite und Verschlüsselung der Daten geben. Auch wenn solche Zertifikate und er dazu gehörige private Schlüssel "gesichert" werden müssen, so ist der Verlust (Daten zerstört) nicht allzu schlimm, da diese Zertifikate relativ problemlos mit einem neuen Schlüsselpaar erzeugt werden können. Selbst wenn die Schlüssel "Abhanden" kommen, wird das Zertifikat einfach zurück gezogen und durch ein neues Zertifikat ersetzt.

Anders sieht dies aber bei Zertifikaten aus, deren Schlüssel wirklich auch zur permanenten Verschlüsselung von Daten genutzt werden. Dazu zählen u.a.:

Mit dem Public Key dieser Zertifikate werden z.B. lokale Dateien verschlüsselt oder Absender können ihnen damit Mails verschlüsselt senden. Sie benötigen unbedingt den dazu passenden privaten Schlüssel, um die Informationen auch später wieder zu lesen. Damit stellt sich natürlich die Frage, wo die Zertifikat liegen, wie diese "wieder hergestellt" werden können und wie diese auf verschiedene Arbeitsplätze kommen.

Zertifikatsspeicher - "Protected Store"

Wenn Sie über die MMC sich mal ihren "Zertifikatsspeicher" anschauen, dann sehen Sie hier mehrere Ordner und Unterordner, in denen verschiedenen Ordnern. Interessant ist da natürlich erst mal der Ordner "Eigene Zertifikate" in dem sich einige Zertifikate befinden. Anhand des Icons kann man schon erkennen, dass einige einen kleinen gelben "Schlüssel" haben. Zu diesen Zertifikaten habe ich also auch einen privaten Schlüssel in meinem Zertifikatsspeicher

Allerdings tut Windows alles, damit diese private Schlüssel "geschützt" ist. Der Zertifikatsspeicher besteht aus Dateien in den folgenden Ordnern: 

Dort drin finden Sie aber nur jede Menge "Systemdateien", die aber nicht lesbar sind, da sie zusätzlich verschlüsselt sind. Auch wenn Microsoft nicht allzu offenherzig mit dem genauen Verfahren umgeht, so ist der "Protected Store" Zumindest mit dem Windows Profil und dem Kennwort verbunden.

Kennwort Zurücksetzen
Vergisst ein Benutzer z.B. sein Kennwort und setzt der Administrator dieses Kennwort "zurück", dann kann der Benutzer trotzdem nicht mehr auf die privaten Schlüssel in seinem Speicher zurück greifen. Erst wenn der Anwender sein Kennwort selbst wieder auf den alten Wert gesetzt hat, kann er die Schlüssel erreichen.

Spätestens jetzt erkennen Sie, dass ein "Key Recovery" oder ein "Key Backup" eine ganz wichtige Funktion ist.

Protected Store und Roaming

Nun ist es ja nicht unbedingt so, dass ein Anwender immer nur an einem PC arbeitet und so stellt sich die Frage, wie er "seine" Zertifikate auch auf andere System mitnehmen kann. Zertifikate können im lokalen Speicher oder auf einer Smartcard liegen. Eine Smartcard ist ja noch ein "Stück weit" mobil aber für einen Speicherplatz auf einer Festplatte gilt dies nicht. Schauen wir uns das etwas genauer an;

Eigentlich ist DIMS die einzig richtige Lösung, um Clientzertifikate im lokalen Zertifikatsspeicher so zu hinterlegen, damit diese auch beim "Roaming" verfügbar werden. Sie sind dann unabhängig vom lokalen Benutzerprofile. Doch wie ist das zu konfigurieren ?

Localstore und Roaming

Die Konfiguration ist recht einfach und bei Microsoft sehr gut dokumentiert. Insofern beschränke ich mich auf der MSXFAQ einmal darauf, sie einfach auf dieses nützliche und wichtige Features aufmerksam zu machen, die passenden Links beizusteuern und mit Bildern und Infos die Fehlersuche zu erlauben. Die Voraussetzungen sind schnell genannt:

Ansonsten können Sie sich an den entsprechenden Seiten entlang hangeln.

Damit sie sich nicht selbst die Dateien aus der Doku als Text-Kopie abziehen müssen, hab ich ihnen die beiden relevanten Dateien hier zum Download bereit gestellt:

dimsroam.adm Gruppenrichtlinienvorlage
dimsroam.ldf Schema Erweiterung

Der Client

Die Einrichtung einer Gruppenrichtlinie erkläre ich hier nicht weiter. Nachdem diese aber eingestellt und von den Clients übernommen wurde (notfalls mit GPUPDATE forcieren), sollte der Zertifiaktclient diese neue Einstellungen "verstanden" haben.

Sie können dies einfach mit einer Kontrolle der entsprechenden Einträge in der Registrierung prüfen:

Die "0x1" hinter DIMSRoaming zeigt an, dass die Ablage der Zertifikate im Active Directory auf dem Client aktiviert ist. Alternativ können Sie natürlich auch die MMC für den Richtlinienergebnissatz (RSOP.MSC) nutzen.

Auch hier sehen Sie nun "lesbar" die einzelnen Felder und Werte, die aber "Grau" angezeigt werden, weil der Benutzer diese Werte nun nicht mehr ändern kann.

Ob ein Client seine Zertifikate nun wirklich im AD hinterlegt hat, können Sie mit ADSIEDIT.MSC am einfachsten überprüfen. Die Zertifikate liegen in dem Feld "msPKIAccountCredentials" und "msPKIDPAPMasterKeys". Die Felder sind allerdings binär und nicht mit ADSIEDIT direkt einsehbar. Verwechseln Sie dies bitte nicht mit den ebenfalls im AD veröffentlichten Benutzerzertifikate.

Das ist auch nicht weiter tragisch, da die privaten Schlüssel hier natürlich nicht im Klartext hinterlegt sind, sondern ähnlich dem "Protected Store" auf dem Client in sich wieder verschlüsselt sind. Nur der Anwender kann mit "seinem" AD-Kennwort diesen Safe aufschließen. Das Problem eines "vergessenen Kennworts" bleibt also bestehen. Wer sein Kennwort vergisst und dessen Konto durch einen Admin ein neues Kennwort bekommt, kommt nicht mehr an den Schlüsselspeicher heran, bis er wieder sein altes (vergessenes) Kennwort eingetragen hat.

Weitere Links

Keywords: SignCrypt Zertifikate Profil Roaming