Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 15 Dateisystem und Dateidienste
Pfeil 15.1 Allgemeines zum Dateisystem
Pfeil 15.1.1 Aufbau
Pfeil 15.1.2 Platten verwalten
Pfeil 15.1.3 MBR vs. GPT
Pfeil 15.1.4 Partitionieren
Pfeil 15.1.5 Basis-Datenträger vs. dynamische Datenträger
Pfeil 15.1.6 Spiegeln
Pfeil 15.1.7 Volumes vergrößern und verkleinern
Pfeil 15.1.8 Weitere Optionen
Pfeil 15.1.9 Schattenkopien – Volume Shadow Copy Service
Pfeil 15.1.10 Transactional NTFS und Self-Healing NTFS
Pfeil 15.2 Installation der Rolle »Dateiserver«
Pfeil 15.3 Ressourcen-Manager für Dateiserver (RMDS)
Pfeil 15.3.1 Kontingentverwaltung
Pfeil 15.3.2 Dateiprüfungsverwaltung (File Screening Management)
Pfeil 15.3.3 Speicherberichteverwaltung
Pfeil 15.4 Verteiltes Dateisystem – Distributed File System (DFS)
Pfeil 15.4.1 Grundfunktion
Pfeil 15.4.2 DFS und DFS-Replikation
Pfeil 15.4.3 Ausfallsicherheit
Pfeil 15.4.4 Verteilen von Daten – standortübergreifendes DFS
Pfeil 15.4.5 Sicherung von Daten
Pfeil 15.4.6 DFS installieren
Pfeil 15.4.7 Basiskonfiguration
Pfeil 15.4.8 Konfiguration der Replikation
Pfeil 15.4.9 Redundanz des Namespaceservers
Pfeil 15.5 Encrypting File System (EFS)
Pfeil 15.5.1 Konfiguration und Anwendung
Pfeil 15.5.2 Zugriff für mehrere Benutzer
Pfeil 15.5.3 Datenwiederherstellungs-Agenten
Pfeil 15.5.4 EFS per Gruppenrichtlinie steuern
Pfeil 15.5.5 Cipher
Pfeil 15.6 ReFS und Speicherpools
Pfeil 15.7 iSCSI-Zielserver (iSCSI-Taget)
Pfeil 15.7.1 Einrichten eines iSCSI-Targets
Pfeil 15.7.2 Ein iSCSI-Target verwenden
Pfeil 15.8 Datendeduplizierung

Rheinwerk Computing - Zum Seitenanfang

15.5 Encrypting File System (EFS) Zur nächsten Überschrift

Je sensibler Daten sind, desto mehr muss zu ihrem Schutz unternommen werden – das klingt so weit einleuchtend. Neben der Einschränkung des Zugriffs mittels NTFS-Rechten bietet Windows Server 2012 genauso wie die Vorgängerversionen die Möglichkeit, Dateien verschlüsselt im Dateisystem zu speichern. EFS, das Encrypting File System, wurde erstmalig mit Windows 2000 Server ausgeliefert.

Bevor dieser Abschnitt »so richtig« beginnt, gibt es einige »planerische Anmerkungen«:

  • EFS arbeitet mit Zertifikaten, die natürlich zunächst erzeugt werden müssen. Obgleich das Betriebssystem ein selbstsigniertes Zertifikat erzeugen kann, empfiehlt sich der Aufbau einer PKI, die dann die für EFS erforderlichen Zertifikate an zentraler Stelle erzeugt.
  • EFS eignet sich nicht dazu, ein komplexes Sicherheitsmanagement für sensible Dokumente aufzubauen, bei dem beispielsweise festgelegt wird, das nur die Personen Müller, Meier und Schmidt ein Dokument öffnen dürfen. Dies wäre die Aufgabe der Active Directory-Rechteverwaltungsdienste (AD RMS).
  • Ein gewichtiger Vorteil von EFS gegenüber AD RMS ist, dass EFS für eine Anwendung transparent ist, d. h., die Anwendung muss nichts von Verschlüsselung auf der Festplatte wissen. AD RMS muss hingegen explizit unterstützt werden.
  • Denken Sie daran, dass es möglich ist, dass das Zertifikat, mit dem eine Datei verschlüsselt wurde, verloren geht. Dieser Fall ist sorgfältig zu durchdenken, denn wenn ein unternehmenswichtiges Dokument zwar vorhanden ist, aber nicht entschlüsselt werden kann, ist das sicherlich wenig begeisternd.
  • EFS ist übrigens kein Ersatz für die NTFS-Rechte. Ein fremder Benutzer kann zwar auf eine verschlüsselte Datei nicht zugreifen, er kann sie allerdings beispielsweise löschen.

Rheinwerk Computing - Zum Seitenanfang

15.5.1 Konfiguration und Anwendung Zur nächsten ÜberschriftZur vorigen Überschrift

Zunächst benötigt ein Benutzer ein Zertifikat, bevor mit der Verschlüsselung mittels EFS begonnen werden kann. Im Optimalfall haben Sie in Ihrem Unternehmen ohnehin Zertifikate ausgerollt, in deren Verwendungszweck auch die Verschlüsselung der Daten auf dem Datenträger enthalten ist (Abbildung 15.78).

Abbildung

Abbildung 15.78 Optimalerweise haben Sie bereits Zertifikate ausgerollt, in deren Verwendungszweck die Verschlüsselung auf dem Datenträger enthalten ist.

Falls nicht bereits ein passendes Zertifikat vorhanden ist, wird ein Vista/7/8/8.1-Client sich gemäß der Gruppenrichtlinie verhalten. Das Management von EFS mittels Gruppenrichtlinien wird weiter hinten besprochen; hier nur die möglichen Varianten:

  • Sofern eine Online-Zertifizierungsstelle vorhanden ist (eine solche wird mit Active Directory-Zertifikatdiensten aufgebaut), kann das Client-Betriebssystem dort ein geeignetes Zertifikat anfordern. Voraussetzung ist, dass die Online-Zertifizierungsstelle angeforderte Zertifikate direkt ausstellt.
  • Ist entweder keine Online-Zertifizierungsstelle vorhanden oder ist diese nicht erreichbar, kann das Client-Betriebssystem ein selbstsigniertes Zertifikat erstellen.

In Abbildung 15.79 sehen Sie ein solches selbstsigniertes Zertifikat. Sie sehen, dass bei Ausgestellt von keine Stammzertifizierungsstelle eingetragen ist (vergleiche Abbildung 15.78), und demzufolge gibt es kein zentrales Management dieser »dezentral« generierten Zertifikate.

Abbildung

Abbildung 15.79 Dieses selbstsignierte Zertifikat wurde erstellt, weil bei der ersten Nutzung von EFS die Online-Zertifizierungsstelle nicht erreichbar war.

Weiterhin müssen Sie sich Gedanken über die Sicherung des Zertifikats machen, denn es wird nicht im Active Directory gespeichert. Dass das Zertifikat nicht im Active Directory gespeichert ist, führt dazu, dass das Verschlüsseln einer Datei für mehrere Benutzer nicht funktioniert; mehr dazu folgt in Abschnitt 15.5.2. Sofern im Active Directory ein Datenwiederherstellungs-Agent eingerichtet ist (mehr dazu folgt in Abschnitt 15.5.3), wird dieser auch mit einem selbstsignierten Zertifikat funktionieren – Sie stehen also nicht ganz schutzlos im Regen.

Die Verwendung von EFS ist für den Benutzer recht simpel. In den Eigenschaften einer Datei oder eines Ordners findet sich eine Schaltfläche Erweitert, die zu dem Dialog aus Abbildung 15.80 führt. Dort können Sie durch einfaches Anwählen der Checkbox Inhalt verschlüsseln, um Daten zu schützen, die EFS-Verschlüsselung für eine Datei oder einen Ordner aktivieren. Hierzu noch zwei Anmerkungen:

  • Kompression und Verschlüsselung können nicht gleichzeitig verwendet werden.
  • Die Schaltfläche Details ist zunächst nicht anwählbar. Sie wird aktiv sein, wenn eine Datei bereits verschlüsselt ist, und führt zu einem weiteren Dialog, mit dem die Verschlüsselung der Datei so angepasst werden kann, dass mehrere Benutzer Zugriff haben.

Abbildung

Abbildung 15.80 Durch das Anwählen der Checkbox »Inhalt verschlüsseln...« wird EFS aktiviert.

Sofern Sie eine Datei zur Verschlüsselung ausgewählt haben, wird der in Abbildung 15.81 gezeigte Dialog erscheinen, in dem Sie gefragt werden, ob Sie nur die aktuelle Datei verschlüsseln möchten oder den kompletten Ordner, in dem die Datei sich befindet. Ist ein Ordner verschlüsselt, führt das dazu, dass sämtliche dort neu angelegten Dateien ebenfalls verschlüsselt werden. Da viele Applikationen (z. B. Word, Excel etc.) beim Bearbeiten einer Datei im selben Verzeichnis eine Temporärdatei anlegen, wird diese ebenfalls verschlüsselt, sodass kein »Sicherheitsloch« durch unverschlüsselte Temporärdateien entsteht.

Eine Anmerkung: Wenn Sie in dem gezeigten Dialog der Empfehlung folgen und den übergeordneten Ordner ebenfalls als verschlüsselt markieren, werden nicht sämtliche darin enthaltenen Dateien mit dem Schlüssel des aktuellen Benutzers verschlüsselt. Das wäre beispielsweise auf einem Abteilungsverzeichnis tödlich, weil sofort sämtliche Kollegen vom Zugriff auf alle dort vorhandenen Dateien ausgeschlossen würden. Nicht verschlüsselte Dateien werden in diesem Fall nicht angerührt. Neu erstellte Dateien werden verschlüsselt gespeichert.

Mithilfe von EFS werden natürlich nicht nur Dateien auf der lokalen Festplatte des jeweiligen Benutzers verschlüsselt, vielmehr funktioniert EFS auch mit Dateien in einer Freigabe eines Fileservers. Das ist auch absolut sinnvoll, denn im Grunde sollen ja sämtliche Informationen auf dem Server und nicht auf lokalen Festplatten liegen. Das Verschlüsseln einer Datei funktioniert aus Sicht des Anwenders gleich, egal ob die Datei auf einer lokalen Platte oder auf einem Dateiserver liegt. (Abbildung 15.80 zeigt übrigens das Verschlüsseln einer Datei auf einem Server.)

Abbildung

Abbildung 15.81 Falls Sie eine einzelne Datei verschlüsseln, erscheint dieser Dialog.


Rheinwerk Computing - Zum Seitenanfang

15.5.2 Zugriff für mehrere Benutzer Zur nächsten ÜberschriftZur vorigen Überschrift

Einer der Vorteile eines Dateiservers ist, dass ein dort abgelegtes Dokument prinzipiell von mehreren Benutzern verwendet werden kann – vorausgesetzt, die NTFS-Berechtigungen lassen dies zu. Nun ist es nicht schwierig, einen Fall zu konstruieren, in dem mehrere Benutzer auf ein Dokument zugreifen sollen, das so sensibel ist, dass es verschlüsselt gespeichert werden soll.

Zunächst verschlüsselt EFS eine Datei so, dass nur der verschlüsselnde Benutzer diese öffnen kann (abgesehen vom Datenwiederherstellungs-Agent). Ein anderer Benutzer wird sich in der Situation wiederfinden, die in Abbildung 15.82 gezeigt ist – er bekommt keinen Zugriff.

Seit Windows Server 2003 ist es möglich, eine Datei für mehrere Benutzer zu verschlüsseln. Diese Möglichkeit steht natürlich auch in Windows Server 2012/R2 zur Verfügung.

Abbildung

Abbildung 15.82 Ist ein Dokument nicht mit dem eigenen Schlüssel verschlüsselt, erhält man keinen Zugriff.

Wenn eine Datei bereits verschlüsselt ist und Sie den Dialog aufrufen, in dem die Verschlüsselung aktiviert wird (Eigenschaften · Erweitert), wird der dortige Schalter Details nicht ausgegraut sein. (Er ist nicht anwählbar, wenn eine Datei noch nicht verschlüsselt ist.) Ein Klick auf diesen Schalter führt zu einem Dialog, in dem Sie festlegen können, welche Benutzer die Datei entschlüsseln können (Abbildung 15.83). Im Grunde genommen geht es darum, dass Sie das Zertifikat desjenigen Benutzers auswählen müssen, der Zugriff erhalten soll. Sie benötigen den öffentlichen Schlüssel des Benutzers zum Verschlüsseln, und er kann dann mit seinem privaten Schlüssel die Datei entschlüsseln.

Abbildung

Abbildung 15.83 Im Dialog »Benutzerzugriff« kann die Verschlüsselung so modifiziert werden, dass mehrere Benutzer auf eine Datei zugreifen können.

Wenn Sie auf Benutzer suchen klicken, erhalten Sie den üblichen Dialog zum Suchen eines Objekts im Active Directory (hier nicht abgebildet). Auf diese Weise können beliebige weitere Benutzer hinzugefügt werden, die dann auf die geschützten Inhalte zugreifen können.

Es ist nun denkbar, dass für einen Benutzer, dem Sie gern den Zugriff auf die verschlüsselte Datei ermöglichen würden, kein Zertifikat mit dem Verwendungszweck Dateiverschlüsselung existiert. In diesem Fall werden Sie die Fehlermeldung aus Abbildung 15.84 erhalten. Dieser Fehler kann übrigens zwei Ursachen haben:

  • Es ist schlicht und ergreifend kein Zertifikat mit dem Verwendungszweck Datenverschlüsselung vorhanden.
  • Das Zertifikat ist nicht im Active Directory veröffentlicht. Dies ist dann der Fall, wenn das Betriebssystem mangels Online-Zertifizierungsstelle ein selbstsigniertes Zertifikat erstellt hat. Sie können sich in diesem Fall nur so helfen, dass die Benutzer untereinander jeweils den öffentlichen Teil ihres EFS-Zertifikats exportieren und weitergeben und die entsprechenden Schlüssel der anderen Benutzer in ihren lokalen Zertifikatspeicher übernehmen. Bevor Sie den Benutzern das beigebracht haben, ist das PKI-Konzept fertig und vermutlich auch bereits umgesetzt.

Abbildung

Abbildung 15.84 Diese Fehlermeldung erscheint, wenn für einen Benutzer kein EFS-geeignetes Zertifikat vorhanden ist.

In Abbildung 15.85 sehen Sie den Dialog für die Konfiguration des Benutzerzugriffs, wenn zwei Benutzer berechtigt sind. Dieser Dialog enthält zwei Elemente, die als Gedankenstütze für die Planung von EFS gelten können:

  • Es ist extrem wichtig, dass die Schlüssel der Benutzer gesichert werden. Sofern Sie nicht über eine PKI verfügen, die die Schlüssel im Active Directory speichert (und dieses regelmäßig gesichert wird), müssen diese Schlüssel exportiert und an einem sicheren Ort aufbewahrt werden. Der Export der Schlüssel kann aus dem hier gezeigten Dialog mit der Schaltfläche Schlüssel sichern erfolgen. Alternativ bietet sich das Snap-In Zertifikate an.
  • Im Rahmen von EFS können Datenwiederherstellungs-Agenten eingerichtet werden. Hierbei handelt es sich um ein spezielles Zertifikat (oder mehrere), das jede Datei entschlüsseln kann, die von einem Client der Domäne mit EFS verschlüsselt worden ist. In dem gezeigten Dialog ist der Wiederherstellungs-Agent aufgeführt.

Abbildung

Abbildung 15.85 Zum Zugriff auf diese Datei sind zwei Benutzer berechtigt.


Rheinwerk Computing - Zum Seitenanfang

15.5.3 Datenwiederherstellungs-Agenten Zur nächsten ÜberschriftZur vorigen Überschrift

Es ist durchaus denkbar, dass Sie (bzw. die Benutzer) nicht mehr »so ohne Weiteres« auf eine verschlüsselte Datei zugreifen können. Dies kann zum Beispiel passieren, wenn das Konto eines Benutzers, der das Unternehmen verlassen hat, bereits im Active Directory gelöscht wurde und seinen Kollegen einfällt, dass sie Zugriff auf die Dateien brauchen. Wenn diese Dateien mit EFS verschlüsselt sind, sieht es übel aus, da der benötigte private Schlüssel mit dem Konto vernichtet worden ist.

Deaktivieren, nicht löschen

An dieser Stelle können Sie übrigens nachvollziehen, warum man Konten nicht direkt löscht, sondern zunächst deaktiviert. Ich habe aber gerüchteweise gehört, dass in der Praxis meistens direkt die endgültige Lösung – also das Löschen des Kontos – zur Anwendung kommt.

Man könnte nun natürlich das gelöschte AD-Konto aus der Datensicherung wiederherstellen, was aber auch nicht ganz trivial ist. Eventuell fällt den Kollegen auch erst nach vier Wochen ein, dass sie auf die eine oder andere Datei zugreifen müssen, und so lange »zurück« können Sie gegebenenfalls ohnehin nicht auf AD-Sicherungen zugreifen.

Für diese Fälle existiert der EFS-Datenwiederherstellungs-Agent. Hierbei handelt es sich sozusagen um eine »kontrollierte Hintertür«, die das Wiederherstellen jeglicher Datei ermöglicht.

Kurz zur Funktion: Der öffentliche Schlüssel des Wiederherstellungs-Agenten wird über eine Gruppenrichtlinie innerhalb der Domäne bekannt gemacht. Jeder PC oder Server, der Mitglied der Domäne ist, verschlüsselt dahingehend, dass der Wiederherstellungs-Agent mit seinem privaten Schlüssel ebenfalls in der Lage ist, die Datei zu öffnen.

Bei der Installation des ersten Domänencontrollers einer Domäne wird übrigens ein Wiederherstellungs-Agent angelegt. Das dabei generierte Zertifikat ist nur auf dem ersten Domänencontroller vorhanden und wird regelmäßig gern vergessen, wenn dieser Domänencontroller neu installiert oder einfach außer Betrieb genommen wird. Das ist dann das »klassische Eigentor«, denn ab diesem Moment ist keine Wiederherstellung mehr möglich, wenn das Zertifikat sich nicht doch noch in irgendeiner Sicherung findet.

Erstellen und verwalten

Wenn Sie sich in den Eigenschaften einer verschlüsselten Datei anschauen, welche Benutzer die Datei entschlüsseln können, werden Sie auch die Information über die Wiederherstellungs-Agenten finden. Abbildung 15.86 zeigt den entsprechenden Dialog – vergleichen Sie den Fingerabdruck des Zertifikats mit der Abbildung 15.87.

Abbildung

Abbildung 15.86 Der Fingerabdruck des Zertifikats des Wiederherstellungs-Agenten wird angezeigt.

Abbildung

Abbildung 15.87 Der Wiederherstellungs-Agent (d. h. der öffentliche Teil des Zertifikats) wird in der Domänenrichtlinie gespeichert.

Der Wiederherstellungs-Agent wird mit der Gruppenrichtlinie für die Domäne konfiguriert. Im Gruppenrichtlinienverwaltungs-Editor findet sich in der Computerkonfiguration unter Windows-Einstellungen · Sicherheitseinstellungen · Richtlinien für öffentliche Schlüssel · Verschlüsselndes Dateisystem der Wiederherstellungs-Agent (Abbildung 15.87). Bei der Installation des ersten Domänencontrollers wird dieser für das Konto des Administrators ausgestellt. Der Wiederherstellungs-Agent ist letztendlich ein Zertifikat, dessen Fingerabdruck natürlich mit dem zuvor aus den Eigenschaften des Dokuments ermittelten übereinstimmt (Abbildung 15.87, rechts).

In Abbildung 15.88 können Sie das automatisch erzeugte Zertifikat des Wiederherstellungs-Agenten genauer betrachten. Folgendes ist festzustellen:

  • Es handelt sich notwendigerweise um ein selbstsigniertes Zertifikat. Zum Installationszeitpunkt ist ja im Allgemeinen auch keine Online-Zertifizierungsstelle verfügbar.
  • Das Zertifikat wird als Zertifizierungsstellen-Stammzertifikat angesehen, das aufgrund seines Speicherorts nicht als vertrauenswürdig gilt. Daran brauchen Sie sich allerdings nicht zu stören – es funktioniert trotzdem!

Auch wenn ich mich wiederhole: Der öffentliche Schlüssel dieses Zertifikats ist im Active Directory für jeden PC zugänglich, denn er wird ja für die Verschlüsselung von Dateien benötigt. Um eine verschlüsselte Datei wieder zu entschlüsseln, wird der private Schlüssel benötigt. Dieser befindet sich ausschließlich im Zertifikatsspeicher des ersten Domänencontrollers. Nirgends sonst!

Dass auf Abbildung 15.88 der Hinweis Sie besitzen einen privaten Schlüssel ... erscheint, liegt daran, dass dieses Bildschirmfoto genau auf dem ersten Domänencontroller angefertigt worden ist. Auf den anderen DCs ist der private Schlüssel nicht vorhanden.

Exportieren Sie also diesen Schlüssel, und heben Sie ihn gut auf!

Vorsicht

Folgendes ist übrigens ein häufiger und eventuell ziemlich katastrophaler Fehler: Bei der Ablösung eines Domänencontrollers verschiebt man natürlich die FSMO-Rollen, vergisst aber leicht, das Zertifikat des EFS-Wiederherstellungs-Agenten zu exportieren. Der private Schlüssel ist, wenn Sie nicht etwas unternehmen, nur auf der Maschine vorhanden, auf der der Wiederherstellungs-Agent erzeugt wurde. Standardmäßig ist das der erste installierte Domänencontroller.

Sie können mehrere Datenwiederherstellungs-Agenten definieren, die gleichzeitig verwendet werden können. Ob das so unglaublich sinnvoll ist, sei allerdings dahingestellt. Allerdings wird auch das Zertifikat des Wiederherstellungs-Agenten irgendwann ablaufen, sodass Sie früher oder später ein neues erstellen müssen.

Abbildung

Abbildung 15.88 Das bei der Installation des ersten Domänencontrollers einer Domäne erzeugte Zertifikat für die Dateiwiederherstellung

Um einen neuen Datenwiederherstellungs-Agenten zu erstellen, können Sie im Gruppenrichtlinienverwaltungs-Editor im Kontextmenü des Knotens Verschlüsselndes Dateisystem die gleichnamige Funktion aufrufen (Abbildung 15.89).

Abbildung

Abbildung 15.89 Im Kontextmenü können Sie das Erstellen eines neuen Datenwiederherstellungs-Agenten starten.

Beim Erstellen eines neuen Datenwiederherstellungs-Agenten wird bei der Onlinezertifizierungsstelle ein Zertifikat mit dem Verwendungszweck Dateiwiederherstellung angefordert. Alternativ können Sie auch das Hinzufügen eines Agenten wählen. In diesem Fall wird ein bereits im Dateisystem liegendes Zertifikat importiert. Das neue Zertifikat wird übrigens ausschließlich für den Verwendungszweck Dateiwiederherstellung ausgestellt.

Nach dem Erstellen eines neuen Wiederherstellungs-Agenten werden vermutlich zwei davon vorhanden sein. Sie werden feststellen, dass es absolut kein Problem ist, dass mehrere Wiederherstellungs-Agenten aktiv sind.

Wenn Sie nun den alten Agenten mit dem selbstsignierten Zertifikat löschen möchten, können Sie dies einfach mit einem Mausklick erledigen. Bedenken Sie aber, dass früher verschlüsselte Dateien nur mit dem alten Agenten und nicht mit dem neu erzeugten entschlüsselt werden können. Der neue Datenwiederherstellungs-Agent funktioniert nur bei denjenigen Dateien, die verschlüsselt worden sind, als er schon da war – schließlich wird für die Verschlüsselung der öffentliche Schlüssel des Wiederherstellungs-Agenten verwendet.

Sie sollten also vor dem Löschen den alten Dateiwiederherstellungs-Agenten exportieren.

Es ist auf jeden Fall eine gute Idee, einen Datenwiederherstellungs-Agenten zu exportieren, die Datei auf CD zu brennen und in den sichersten Tresor zu legen, der in Ihrer Organisation vorhanden ist. Das Zertifikat zu exportieren ist nicht schwierig, Sie können diese Funktion aus dem Kontextmenü des Eintrags des Datenwiederherstellungs-Agenten aufrufen.

Wichtig ist, dass Sie den privaten Schlüssel exportieren. Die vorbelegte Einstellung ist übrigens, den privaten Schlüssel nicht zu exportieren. Hier ist also ein wenig Sorgfalt erforderlich (Abbildung 15.90).

Abbildung

Abbildung 15.90 Beim Exportieren des Zertifikats ist darauf zu achten, dass der private Schlüssel exportiert wird!

Die entstehende Datei muss an einem wirklich sicheren Ort aufbewahrt werden, denn mit ihr können alle EFS-verschlüsselten Dokumente geöffnet werden.

Falls die Option, den privaten Schlüssel zu exportieren, nicht vorhanden ist, liegt das daran, dass Sie auf dem falschen Server sind. Gehen Sie zu dem Server, auf dem der Wiederherstellungs-Agent erstellt wurde, bzw. zum ersten Domänencontroller.

Anwenden

Das Anwenden des Datenwiederherstellungs-Agenten ist trivial. Ein Benutzer, in dessen persönlichem Zertifikatspeicher sich das Zertifikat für des Datenwiederherstellungs-Agenten findet, kann auf die Datei zugreifen und beispielsweise die Verschlüsselung deaktivieren oder einem weiteren Benutzer Zugriff gewähren.


Rheinwerk Computing - Zum Seitenanfang

15.5.4 EFS per Gruppenrichtlinie steuern Zur nächsten ÜberschriftZur vorigen Überschrift

Im vorigen Abschnitt haben Sie gesehen, wie man einen Datenwiederherstellungs-Agenten anlegt. An derselben Stelle im Gruppenrichtlinienverwaltungs-Editor können Sie weitere Eigenschaften für die Verwendung von EFS definieren. Wenn Sie die Eigenschaften des Knotens Verschlüsselndes Dateisystem aufrufen, erscheint der Dialog aus Abbildung 15.91:

  • Zunächst können Sie einstellen, ob die Verwendung von EFS überhaupt möglich sein soll. Wenn Sie für eine bestimmte OU (oder die komplette Domäne) EFS aktivieren wollen, stellen Sie dies in den Gruppenrichtlinien der OU mit diesem Dialog ein.

    Abbildung

    Abbildung 15.91 Die Optionen im Gruppenrichtlinienobjekt-Editor für die Steuerung von EFS

  • Die Optionen sind zumeist selbsterklärend. Sie sehen hier, dass sich die Sicherheit bei der Verwendung von EFS noch dadurch optimieren lässt, dass Sie verlangen, dass eine Smartcard verwendet wird.
  • Auf der Registerkarte Zertifikate (Abbildung 15.92) wird festgelegt, ob ein selbstsigniertes Zertifikat erzeugt werden soll, falls keine Online-Zertifizierungsstelle vorhanden ist. Deaktivieren Sie diese Option, wenn Sie eine PKI aufgebaut haben. Es ist durchaus denkbar, dass die Stammzertifizierungsstelle kurzzeitig nicht verfügbar ist (z. B. wegen Wartungsarbeiten). Wenn in diesem Moment ein Benutzer ein EFS-Zertifikat benötigt, bekäme er sonst ein selbstsigniertes.

    Weiterhin können Sie einstellen, welche Zertifikatvorlage bei Zertifikatanforderungen verwendet werden soll.

Abbildung

Abbildung 15.92 Zweite Registerkarte der Optionen im Gruppenrichtlinienobjekt-Editor für die Steuerung von EFS


Rheinwerk Computing - Zum Seitenanfang

15.5.5 Cipher Zur vorigen Überschrift

Die Verschlüsselung von Dateien mit EFS lässt sich auch über die Kommandozeile steuern und kontrollieren. Hierfür kommt das Werkzeug cipher.exe zur Anwendung. Abbildung 15.93 zeigt die Ausgabe des Werkzeugs beim Aufruf von cipher /?.

Das Werkzeug steht übrigens nicht nur auf dem Windows Server 2012/R2 zur Verfügung, sondern auch im Vista/7/8/8.1-Client. Auch XP und Windows Server 2003 kennen cipher.

Die Optionsauflistung von cipher ist recht ausführlich kommentiert (der Screenshot zeigt nur das erste Fünftel) und muss daher nicht weiter erläutert werden.

Abbildung

Abbildung 15.93 EFS-Steuerung auf der Kommandozeile mit »cipher.exe«



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo