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.:

  • EFS-Zertifikate
  • SMIME-Zertifikate

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.

Einschränkungen

Ehe ich in den folgenden Abschnitten die Funktionsweise erläutere, möchte ich vorab gleich schreiben, wann diese Technik versagt. Ansonsten kommen Sie vielleicht vorschnell auf den Gedanken, dass das Certificate Roaming all ihre Probleme mit Client Zertifikaten lösen könnte. Da der Container mit den Zertifikaten mit dem Kennwort des Anwenders geschützt ist, bricht das System wenn das Kennwort anderweitig geändert wird.

  • Kennwort Rücksetzung durch Admin
    Der Fall leuchtet ja noch recht einfach ein und hier kann das Verhalten durchaus auch als erwünschter "Schutz" bezeichnet werden

Wenn dem Anwender sein Kennwort später wieder einfällt und er es wieder auf diesen Wert zurücksetzt, dann kommt er angeblich sogar wieder an seine Zertifikate ran. Kniffliger und vielleicht überraschender sind aber Änderungen, die auf den ersten Blick nicht offensichtlich sind. Die betreffen alle Änderungen, die der Anwender selbst durchführen kann und nicht an einem "Windows PC in der Domäne" erfolgen. Davon gibt es mittlerweile durchaus einige Optionen

  • Kennwort Ändern über TMG (Thread Management gateway)
  • Kennwort ändern über ADFS-Server
    Anwender können über die Funktion ADFS Password Change per Browser ihr Kennwort ändern.
  • Kennwort Ändern in Office 365
    Mit aktivierter bidirektionaler Synchronisation können Anwender in der Cloud ihr Kennwort ändern und AADConnect repliziert dieses zurück nach On-Premises

Darunter fallen noch viele weitere Optionen, die oft 3rd Party Produkte oder Portale mitbringen, um das eigene Kennwort zu setzen.

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: 

  • Application Data\Microsoft\Crypto
  • Application Data\Microsoft\Protect
  • Application Data\Microsoft\SystemCertificates

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.

Hinweis:
Seit Windows 7 kann ein Anwender auch nach einem Kennwortwechsel weiter auf die Zertifikate zuzugreifen, wenn diese per Roaming wieder aus dem Active Directory geladen werden.

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;

  • Smartcard
    Wie schon geschrieben ist eine Smartcard ein optimaler Platz für die Ablage von Zertifikaten, Sie können einfach mitgenommen werden und in jedem PC mit Smartcard-Leser oder als USB-Token einstecken. Allerdings haben nur einige Firmen heute schon Smartcards entsprechende Leser in ihren Geräten. Oft sind es ausgewählte besonders zu schützende Systeme (z. B. Codesignatur, Rechnungssignatur).
  • LocalStore
    Da viele Firmen daher ihre Zertifikate mit im Windows Profile des Benutzers ablegen, muss sich der Administrator Gedanken machen, wie diese Zertifikate transportiert bzw. gesichert werden.
    • Nur lokale Profile
      Wer sich keine Gedanken macht, hat lokale Benutzerprofile auf dem PC und wenn der Anwender das erste mal den Arbeitsplatz wechselt, wird er nicht mehr an seine verschlüsselten Mails kommen. Dies ist sicher keine Lösung
    • Roaming Profiles
      Als einfachste Lösung bieten sich dabei "Roaming Profiles" an, mit denen ein Anwender seine komplette ArbeitsUmgebung beim Abmelden auf den Server kopiert und bei einer Neuanmeldung wieder auf das lokale System überträgt. Um die Datenmenge hier unter Kontrolle zu halten sollte das Profil "klein" bleiben. Administratoren können dies z. B: über den Ausschluss bestimmter Verzeichnisse oder eine Umlenkung von "Eigene Dateien" auf einen Netzwerkserver erreichen. Dennoch gibt es auch mit dieser Lösung Probleme, da z.B.: Profile zwischen Workstations und auf Terminal Servern unterschiedlich sind. Oft ist es auch eine Lösungsstrategie des Helpdesks ein Profil "frisch" zu machen, indem man es löscht. Das ist dann schon ein böser Fauxpas wenn mit Zertifikaten gearbeitet wird.
    • DIMS-Roaming
      Seit Windows XP und Windows 2003 ist es möglich, das der Client nur seine Zertifikate samt privatem Schlüssel in das Active Directory sichert. Natürlich ist dazu eine entsprechende Schemaerweiterung und Konfiguration durch Gruppenrichtlinien erforderlich.

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:

  • Client
    Windows XP SP2, Vista oder Windows 7 oder höher
  • Domain Controller
    Windows 2003 SP1 Domain Controlleroder höher auf allen DCs
    Es darf also keinen älteren DC mehr geben. In einem Forest mit Windows 2008 sind die erforderlichen Schemaerweiterungen schon eingebaut, In einer reinen Windows 2003 Umgebung müssen Sie das Schema noch erweitern.

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 Zertifikatclient 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