Problem mit EFS
Thorsten Schmid
ich habe hier ein Problem mit dem EFS. Es existiert ein Windows 2000 AD
mit einem Windows 2003 Memberserver als Fileserver. Soweit so gut.
Nun wollen ein paar User ihre Daten die auf dem Server liegen verschlüsseln.
Es kommt die Fehler-Meldung: "Die Wiederherstellungsrichtlinie für diesen
Computer
enthält ein ungültiges Wiederherstellungszertifikat".
Ich habe herausgefunden dass das Zertifikat für den Wiederherstellungsagent
im August 2005,
genau 3Jahre nach der Installation abgelaufen ist. Dieser steht in der
Standard Domain Policy.
Schau ich mir die Zertifikate des Benutzers Administrator an besitzt er noch
eines das 100Jahre
gültig (jetzt noch 96,5Jahre) ist, die Frage ist nun: wie kann ich das
austauschen? Wäre super
wenn mir da jemand einen Tipp hat. Oder wie kann ich ein neues erstellen
ohne gleich eine
Zertifizierungsstelle zu brauchen
Danke,
Thorsten
PS: Verschlüsseln auf dem DC (Windows 2000) klappt nach wie vor...
Frank Röder
AFAIK kommst Du nicht herum eine Zertifizierungsstelle zu erstellen.
Nach dem Du das getan hast, aktivierst Du den DRA in der "Default Domain
Policy". Wenn Du jetzt auf dem Fileserver ein "cipher /u" ausführst,
bekommen alle Dateien den neuen DRA eingetragen.
>
> PS: Verschlüsseln auf dem DC (Windows 2000) klappt nach wie vor...
Das wundert mich. Ich setze kein EFS ein da es fast "unbrauchbar" ist
und einen zu hohen administrativen Aufwand mit sich bringt.
--
Viele Grüße
Frank Röder
Daniel Melanchthon [MSFT]
> Ich habe herausgefunden dass das Zertifikat für den
> Wiederherstellungsagent im August 2005, genau 3Jahre nach der
> Installation abgelaufen ist. Dieser steht in der Standard Domain Policy.
Richtig.
> Schau ich mir die Zertifikate des Benutzers Administrator an besitzt er
> noch eines das 100Jahre gültig (jetzt noch 96,5Jahre) ist, die Frage ist
> nun: wie kann ich das austauschen?
Nein. Denn das ist ein ganz anderer Zertifikatstyp.
> Wäre super wenn mir da jemand einen Tipp hat. Oder wie kann ich ein
> neues erstellen ohne gleich eine Zertifizierungsstelle zu brauchen
Anbei mal eine Anleitung auf englisch. Wichtig ist, daß Du auf jeden Fall
vorher das abgelaufene Zertifikat exportierst, und zwar als *der*
Administrator!
SO WIRD'S GEMACHT: Sichern des privaten EFS-Schlüssels für den
Wiederherstellungsagenten http://support.microsoft.com/kb/q241201/
Solltest Du eine Fehlermeldung beim Exportieren des Privaten Keys erhalten,
gibt es folgenden Artikel:
EFS Recovery Agent Cannot Export Private Keys
http://support.microsoft.com/default.aspx?scid=kb;en-us;259732
Und hier die Anleitung für die Erneuerung des Zertifikats:
You cannot extend the life of the Recovery Agent certificate. The expired
Recovery Agent (RA) needs to be removed from the Default Domain Policy.
2000 Clients require a valid Recovery Agent and will not be able to encrypt
any new documents until one is available.
This resolution is without installing a new CA
1. Logon to a Windows XP or Windows 2003 machine with the account you
want to be the EFS Recovery agent.
2. Use the 2003 version of Cipher or EfsInfo with /R switch will create a
new self-signed File Recovery certificate and private key. Either tool will
generate the new public File Recovery certificate and it will also generate
the PFX for the customer to save for safekeeping
a.) Open a command prompt and run "CIPHER /R:filename" (without the "
quotations) to generate the new EFS Recovery certificate.
b.) When prompted for a password to protect your .PFX file, enter a
password you will easily remember.
c.) Verify that a new .CER and .PFX file are created in the same
directory as the file in step (a.)
5. On a Domain Controller, open the default domain policy
6. Navigate down to Computer configuration\Windows Settings\Security
Settings\Public Key Policies\Encrypted Data Recovery Agents folder
7. Right click on the current certificate on the right pane and select
All Tasks/Export
8. Please confirm you have exported your old EFS Recovery Agent
certificate with key to a .CER file.
----->Notice: This step is importantß----
9. Keep the new EFS Recovery Agent PFX file and the old EFS Recovery
Agent .PFX file securely.
10. Delete the old the EFS Recovery Agent certificate for domain policy.
11. As the domain administrator, right click in the right hand pane of
Computer configuration\Windows Settings\Security Settings\Public Key
Policies\Encrypted Data Recovery Agents and select Add
12. Use the "browse folder" option, import the new certificate (the .cer
file) from the XP/2003 machine into the folder. When you open the file, the
cert will say the user is "user_unknown" (this is normal) and you will
receive a warning message from the wizard that the cert is not trusted. The
trust issue will be resolved by the next step.
13. Repeat step 12 but import the certificate (the .cer file) into the
Computer configuration\Windows Settings\Security Settings\Public Key
Policies\Trusted Root Authorities folder.
14. If you have multiple domain controllers, run "secedit /refreshpolicy
machine_policy /enforce" (without the " quotations) to refresh your policy.
15. Go to a client machine, reboot it and verify the fix worked
After you replace the Encrypted Data Recovery Agents in the default
domain policy, newly encrypted files with have the new "recovery agent". An
encrypted file is not updated with the new RA until the file is accessed
either by the user who has received the updated policy and accessed the
file or by running cipher /u in a logon
You can always recover old EFS'd data with the existing DRA private key
(even though the "Recovery Agent" certificate has expired, the private key
doesn't), you do not *need* to cipher /u all the user's files. If you
*know* you have the private key safely tucked away somewhere you can get at
it, then cipher /u is just a *nice* to have - to update all encrypted files
with the newer keys (which you should also have tucked aware somewhere
safe). It is not a requirement - unless you're not sure you've got the
right private key.
They were able to update the EFS policies over a modem with 'GPUpdate
/force', even if Windows uses cached credentials. They were successful in
being able to decrypt and encrypt files.
How can you know whether you've got the necessary DRA's private key?
* EFSINFO /R /C will tell you which DRA cert (thumbprint) is being used
on existing EFS'd files
* EFSINFO /R /C /U will tell you which DRA cert (thumbprint) is being
used on existing EFS'd files and also the user cert (thumbprint) who
encrypted the data.
This user cert should also be able to decrypt the file.
* If you have the PFX backup of that DRA's cert & keys, then import it
(on a safe system that you'll later wipe) using the Certificates MMC and
inspect the cert that's imported to see if the Thumbprint field matches
* If you only have the first DC, logon as the domain's Administrator
account, fire up the Certificates MMC and see if any of the certs marked
"File Recovery" also have the notation on the General tab that "You have a
private key that corresponds to this certificate". [If not, try another
account.]
* If yes, then export that certificate (including the private key) - if
the export succeeds, then that should mean you have the necessary private key.
* If you didn't find a match, logon as all the other Administrator-level
accounts that could've first logged on to the DC, the first time it was
promoted, and check for any File Recovery certificates that have an
associated private key.
After you have created the new DRA agent, if you can have one user
connect to the domain and runs gpupdate /force they will then have the
correct recovery policy applied. They you can copy the key from
HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\EFS and save it as a
.reg file to send to the users either on a floppy or thru email. Sometimes
anti-virus will strip a .reg file so you may have to rename it if you sent
it thru email. Once they get this key they will need to reboot. After
reboot, they will need to run the cipher command that I had previously sent
you. You can use the cipher.exe utility in a batch file you create using
the " /U " switch. This utility is included in Windows 2000, Windows XP and
Windows 2003. If your users are Windows XP then they already have the
cipher.exe. Otherwise, you will need to send the executable to the users.
You can package this with a utility that is called IExpress that comes with
the XP operating system.
--
.:Daniel Melanchthon:.
Technologieberater - Exchange Server
http://blogs.technet.com/dmelanchthon
This posting is provided "AS IS" with no warranties, and confers no rights.
Daniel Melanchthon [MSFT]
> AFAIK kommst Du nicht herum eine Zertifizierungsstelle zu erstellen.
Das stimmt so nicht.
> Nach dem Du das getan hast, aktivierst Du den DRA in der "Default Domain
> Policy". Wenn Du jetzt auf dem Fileserver ein "cipher /u" ausführst,
> bekommen alle Dateien den neuen DRA eingetragen.
Cipher /u ist nicht zwingend erforderlich, wenn Du den private key des
alten DRA hast. Mit dem kannst Du nämlich weiter problemlos entschlüsseln.
> Das wundert mich. Ich setze kein EFS ein da es fast "unbrauchbar" ist
> und einen zu hohen administrativen Aufwand mit sich bringt.
Ich finde es ganz im Gegenteil zu Dir eine super Sache, Was ist daran
"unbrauchbar" und "hoher administrativer Aufwand"?
Frank Röder
> Frank Röder schrieb:
>
>> AFAIK kommst Du nicht herum eine Zertifizierungsstelle zu erstellen.
>
>
> Das stimmt so nicht.
>
>> Nach dem Du das getan hast, aktivierst Du den DRA in der "Default
>> Domain Policy". Wenn Du jetzt auf dem Fileserver ein "cipher /u"
>> ausführst, bekommen alle Dateien den neuen DRA eingetragen.
>
>
> Cipher /u ist nicht zwingend erforderlich, wenn Du den private key des
> alten DRA hast. Mit dem kannst Du nämlich weiter problemlos entschlüsseln.
Aber cipher /u macht das Leben einfacher und ich muss nicht mit mehreren
private keys arbeiten.
>
> Ich finde es ganz im Gegenteil zu Dir eine super Sache, Was ist daran
> "unbrauchbar" und "hoher administrativer Aufwand"?
http://support.microsoft.com/?kbid=890951&SD=tech
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q290260
http://support.microsoft.com/default.aspx?scid=kb;en-us;329741&sd=tech
Wenn ein Benutzer auf eine Datei zugreift die verschlüsselt ist, bekommt
er eine Fehlermeldung das der Zugriff verweigert wurde und nicht das die
Datei verschlüsselt wird. Das verwirrt viele User und rate mal bei wem
das Telefon klingelt.
Erkläre einen Benutzer, dass er Dateien die komprimiert sind, nicht
verschlüsseln kann.
Daniel Melanchthon [MSFT]
>> Das stimmt so nicht.
>
> Deshalb auch das AFAIK. cipher /R kannte ich noch nicht.
Deshalb der Hinweis.
> Aber cipher /u macht das Leben einfacher und ich muss nicht mit mehreren
> private keys arbeiten.
Stimmt. Komfortabler ist es. Abhängig von den Datenmengen, die Du hast und
dem Backupszenario (inkrementell oder differenziell) kannst Du Dir aber
damit auch ganz schön in den Fuß schießen. Die privaten Keys mußt Du eh
sicher aufbewahren. Ob es dann nun einer oder zwei sind, sollte eigentlich
egal sein.
>> Ich finde es ganz im Gegenteil zu Dir eine super Sache, Was ist daran
>> "unbrauchbar" und "hoher administrativer Aufwand"?
>
> http://support.microsoft.com/?kbid=890951
Stimmt. Unschönes Problem. Aber es gibt dafür einen Fix.
> http://support.microsoft.com/?kbid=290260
Das ist meines Erachtens ein Feature und kein "Problem". Man darf aus
Sicherheitsgründen nicht an die Schlüssel, wenn man Kennworte administrativ
zurücksetzt. Genau deshalb gibt es ja auch einen Disaster Recovery Agent.
> http://support.microsoft.com/?kbid=329741
Welchen Verschlüsselungsalgorithmus man nutzt und die Abwärtskompatibilität
ist eher ein Managementproblem.
> Wenn ein Benutzer auf eine Datei zugreift die verschlüsselt ist, bekommt
> er eine Fehlermeldung das der Zugriff verweigert wurde und nicht das die
> Datei verschlüsselt wird. Das verwirrt viele User und rate mal bei wem
> das Telefon klingelt.
Das ist imho Haarspalterei. Wenn der Benutzer nicht genügend Rechte auf der
Datei hat, bekommt er auch ein "Zugriff verweigert".
> Erkläre einen Benutzer, dass er Dateien die komprimiert sind, nicht
> verschlüsseln kann.
Wer benutzt denn die Softwarekomprimierung? ;-) Mal im Ernst: EFS sollte
natürlich nicht einfach von den Usern nach Lust und Laune eingesetzt
werden, sondern bedarf eines administrativen Managements. Insbesondere die
DRA Schlüsselverwaltung ist vielen Administratoren auch im Jahre 2005 noch
ein Fremdwort. Du kannst meiner Meinung nach, EFS sinnvoll eingesetzt,
einen deutlichen Sicherheitsgewinn erreichen.
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
>> http://support.microsoft.com/?kbid=290260
> Das ist meines Erachtens ein Feature und kein "Problem". Man darf aus
> Sicherheitsgründen nicht an die Schlüssel, wenn man Kennworte
> administrativ zurücksetzt. Genau deshalb gibt es ja auch einen Disaster
> Recovery Agent.
also, sorry - aber das ist eine etwas müde Rechtfertigung für einen
gravierenden Designfehler. In vielen Situationen ist es unabdingbar, das
Kennwort für einen User zu ändern. Wenn er danach nur noch mit Hilfe
eines DRA an seine verschlüsselten Daten kommt (wenn es denn man einen
gibt), macht dies das EFS in fast allen Umgebungen nahezu unbrauchbar.
Und das auch noch ohne Not - welchen sicherheitslogischen Zwang gibt es,
den Key in dieser Form an das Kennwort zu binden?
Zudem sehe ich als eine der größten Schwachstellen von EFS an, dass es
einfach mal so aktiviert ist, ohne dass man was dazu tun müsste. Du
weißt ja selbst, wie oft wir hier Hilferufe von Benutzern und Admins
lesen, die ihre Daten unbedacht ins Nirvana befördert haben. Und man
kann ihnen eigentlich kaum einen Vorwurf machen, denn EFS ist /wirklich/
kompliziert zu handhaben und nicht vernünftig direkt im System dokumentiert.
Ach ja, und dann ist EFS sinnvoll auch nur lokal einsetzbar. Eine
serverbasierte Verschlüsselung ist nicht im Programm (wenn man mal von
der nicht empfohlenen Delegation absieht).
> Du kannst meiner Meinung nach, EFS sinnvoll
> eingesetzt, einen deutlichen Sicherheitsgewinn erreichen.
Man /kann/ schon. Aber bei dem Aufwand, den man dafür betreiben muss (=
Kosten!), ist man mit einer Drittanbieterlösung besser beraten.
Gruß, Nils
--
Nils Kaczenski - MVP Windows Server
www.faq-o-matic.net
MVP-Buch gewinnen: http://www.faq-o-matic.net/content/view/195/58/
Antworten bitte nur in die Newsgroup!
PM: Vorname at Nachname .de
Frank Röder
> Moin,
>
> Daniel Melanchthon [MSFT] schrieb:
>
>>> http://support.microsoft.com/?kbid=290260
>>
>> Das ist meines Erachtens ein Feature und kein "Problem". Man darf aus
>> Sicherheitsgründen nicht an die Schlüssel, wenn man Kennworte
>> administrativ zurücksetzt. Genau deshalb gibt es ja auch einen
>> Disaster Recovery Agent.
>
>
> also, sorry - aber das ist eine etwas müde Rechtfertigung für einen
> gravierenden Designfehler. In vielen Situationen ist es unabdingbar, das
> Kennwort für einen User zu ändern. Wenn er danach nur noch mit Hilfe
> eines DRA an seine verschlüsselten Daten kommt (wenn es denn man einen
> gibt), macht dies das EFS in fast allen Umgebungen nahezu unbrauchbar.
> Und das auch noch ohne Not - welchen sicherheitslogischen Zwang gibt es,
> den Key in dieser Form an das Kennwort zu binden?
Da scheine ich ja mit meiner Meinung, nicht ganz allein da zu stehen ;-)
Daniel Melanchthon [MSFT]
> also, sorry - aber das ist eine etwas müde Rechtfertigung für einen
> gravierenden Designfehler. In vielen Situationen ist es unabdingbar, das
> Kennwort für einen User zu ändern. Wenn er danach nur noch mit Hilfe
> eines DRA an seine verschlüsselten Daten kommt (wenn es denn man einen
> gibt), macht dies das EFS in fast allen Umgebungen nahezu unbrauchbar.
Da sind wir wohl gegenteiliger Meinung. Ich weiß, daß Du EFS nicht magst -
aber die von Dir vorgetragene Kritik halte ich für wenig fundiert.
Jan Peter Stotz
> Und das auch noch ohne Not - welchen sicherheitslogischen Zwang gibt es,
> den Key in dieser Form an das Kennwort zu binden?
Dann mach doch mal Alternativvorschäge, wie der private Schlüssel geschützt
werden könnte.
> Zudem sehe ich als eine der größten Schwachstellen von EFS an, dass es
> einfach mal so aktiviert ist, ohne dass man was dazu tun müsste. Du
> weißt ja selbst, wie oft wir hier Hilferufe von Benutzern und Admins
> lesen, die ihre Daten unbedacht ins Nirvana befördert haben. Und man
> kann ihnen eigentlich kaum einen Vorwurf machen, denn EFS ist /wirklich/
> kompliziert zu handhaben und nicht vernünftig direkt im System dokumentiert.
Du meinst wohl, dass es gibt keinen Klicki-Bunti-Assistenten, der vor der
Verwendung wenigstens die wichtigsten Punkte erklärt. Die Hilfe, in der
zumindestens ab XP einiges zum Thema EFS zu finden ist wird ja heutzutage
erst gelesen, wenn es Probleme gibt, was bekanntlichermaßen bei EFS ein
wenig zu spät ist.
Jan
Frank Röder
> Dann mach doch mal Alternativvorschäge, wie der private Schlüssel geschützt
> werden könnte.
Hier ein ganz primitiver Vorschlag:
Durch eine separate Passphrase? Ich bin zwar auch ein Fan von
Einzelanmeldungen aber gerade bei dem Verschlüsseln von Dateien und
Ordnern finde ich das mit einem anderen Kennwort besser.
>>Zudem sehe ich als eine der größten Schwachstellen von EFS an, dass es
>>einfach mal so aktiviert ist, ohne dass man was dazu tun müsste. Du
>>weißt ja selbst, wie oft wir hier Hilferufe von Benutzern und Admins
>>lesen, die ihre Daten unbedacht ins Nirvana befördert haben. Und man
>>kann ihnen eigentlich kaum einen Vorwurf machen, denn EFS ist /wirklich/
>>kompliziert zu handhaben und nicht vernünftig direkt im System dokumentiert.
Ich möchte hier auch noch ein wenig meinen Senf dazugeben. EFS
verschlüsselt ja nur die Dateien und Ordner. Ich finde Lösungen schön
die mit einer Art virtuellen Disk arbeiten. Dadurch wird nicht nur die
Datei verschlüsselt sondern auch die gesamte Struktur der
verschlüsselten Daten. Das ist natürlich nur ein Schönheitsfehler aus
meiner Sicht.
> Du meinst wohl, dass es gibt keinen Klicki-Bunti-Assistenten, der vor der
> Verwendung wenigstens die wichtigsten Punkte erklärt. Die Hilfe, in der
> zumindestens ab XP einiges zum Thema EFS zu finden ist wird ja heutzutage
> erst gelesen, wenn es Probleme gibt, was bekanntlichermaßen bei EFS ein
> wenig zu spät ist.
>
> Jan
EFS ist ja bekannterweise für den Benutzer und nicht für den Admin. Ich
habe bis jetzt keinen Benutzer erlebt, der ernsthaft die Hilfe
konsultiert hat. Die erwarten einfach einen klicki bunti Assistenten der
sie durch die Aufgaben führt. Viele der Benutzer die ich kenne sind auch
absolut lern- und beratungsresistent was die Sache nicht unbedingt
einfacher macht.
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
> Ich weiß, daß Du EFS nicht magst
sagen wir: Ich habe was gegen die Designschwächen und die
Implementierungsprobleme. Und, ja, ich war damals (Ende 1999) hoch
begeistert davon, musste mich aber durch Kunden überzeugen lassen, dass
der Ansatz an manchen Stellen eben nicht praxistauglich ist.
> aber die von Dir vorgetragene Kritik halte ich für wenig fundiert.
Einigen wir uns auf: Sie überzeugt dich nicht. Das Fundament als solches
ist gegen viele Widerstände gewachsen.
Nils Kaczenski [MVP]
Jan Peter Stotz schrieb:
>>Und das auch noch ohne Not - welchen sicherheitslogischen Zwang gibt es,
>>den Key in dieser Form an das Kennwort zu binden?
> Dann mach doch mal Alternativvorschäge, wie der private Schlüssel geschützt
> werden könnte.
ich bin weder Kryptoexperte noch Betriebssystementwickler. Ich kann nur
sagen, dass die vorliegende Lösung nicht praxistauglich ist. Und ich
habe jahrelang versucht, Kunden vom EFS-Einsatz zu überzeugen.
Aus Adminsicht käme mir eine Lösung wie die von Frank vorgeschlagene in
den Sinn (separate Authentifizierung), die man ja mit einem
Cached-Credentials-Mechanismus koppeln könnte. Nach einem
Passwortwechsel muss ich mich einmalig neu für mein EFS-Zertifikat
authentifizieren, fertig.
Mag sein, dass ich da was übersehe, aber ich halte es auch nicht für
meine Aufgabe, dieses Problem zu lösen, nur weil ich auf ein Problem mit
dem vorhandenen Ansatz hinweise.
> Du meinst wohl, dass es gibt keinen Klicki-Bunti-Assistenten, der vor der
> Verwendung wenigstens die wichtigsten Punkte erklärt.
Du kannst mir gern weiter solche Dinge unterstellen. Du kannst dir aber
auch einfach überlegen, was wohl die zahlreichen Hilfesuchenden hier,
die arglos EFS eingesetzt haben, zu solchen Bemerkungen sagen. Ich habe
mir schon die Finger wundgeschrieben, um die wichtigsten Dinge zu
erläutern. Und ich musste die Voraussetzungen auch schon zertifizierten
Trainern erklären. Soviel zu Klicki-Bunti.
Es wäre doch so einfach: EFS ist standardmäßig deaktiviert und muss vor
Nutzung ausdrücklich administrativ eingeschaltet werden.
Joachim Conrad
Frank Röder schrieb:
>> also, sorry - aber das ist eine etwas müde Rechtfertigung für einen
>> gravierenden Designfehler. In vielen Situationen ist es unabdingbar,
>> das Kennwort für einen User zu ändern. Wenn er danach nur noch mit
>> Hilfe eines DRA an seine verschlüsselten Daten kommt (wenn es denn
>> man einen gibt), macht dies das EFS in fast allen Umgebungen nahezu
>> unbrauchbar. Und das auch noch ohne Not - welchen
>> sicherheitslogischen Zwang gibt es, den Key in dieser Form an das
>> Kennwort zu binden?
>
> Da scheine ich ja mit meiner Meinung, nicht ganz allein da zu stehen
> ;-)
Nein, ich möchte EFS nicht schlechter machen, als es ist, aber eine
kleine Story am Rande:
Ein Kunde rief mich an und sagte, dass seine DASI(Arcserve 2000 auf
W2K-Server))-Logs Fehler protokollierten. Als ich es mir näher
anschaute, wurde klar, dass eine Mitarbeiterin einen Teil ihrer Daten
verschlüsselt hatte und diese nicht mitgesichert wurden. Nach einem
Anruf bei CA wurde mir mitgeteilt, dass verschlüsselte Daten aus
rechtlichen Gründen nicht mitgesichert würden und dies auch nicht zu
ändern sei...
In diesem Sinne, einen "guten Rutsch"
Joachim
--
Joachim Conrad - MS-MVP Windows Networking
Antworten bitte nur in der NG
Die genannte E-Mail Adresse existiert, die Eingänge werden
allerdings automatisch gelöscht.
Jan Peter Stotz
> ich bin weder Kryptoexperte noch Betriebssystementwickler. Ich kann nur
> sagen, dass die vorliegende Lösung nicht praxistauglich ist. Und ich
> habe jahrelang versucht, Kunden vom EFS-Einsatz zu überzeugen.
Als Kryptoexperte würde ich mich auch nicht bezeichnen, als frischer
Diplom-Informatiker mit dem Schwerpunkt IT-Sicherheit habe ich mich jedoch
mit EFS und den dazugehörigen Verfahren mehr als nur ein paar Stunden
beschäftigt (sowohl theoretisch als auch praktisch).
> Aus Adminsicht käme mir eine Lösung wie die von Frank vorgeschlagene in
> den Sinn (separate Authentifizierung), die man ja mit einem
> Cached-Credentials-Mechanismus koppeln könnte.
Alles, was heute nicht mit dem Buzzword "Single-Sign-On" aufwarten kann,
wird von den Verantwortlichen gleich ad Akta gelegt.
> Nach einem
> Passwortwechsel muss ich mich einmalig neu für mein EFS-Zertifikat
> authentifizieren, fertig.
Dieses Verfahren wäre sogar mit dem bestehenden EFS-System möglich, aber
Microsoft hat es nicht implementiert, da sie anscheinend davon Ausgehen,
dass wenn ein Passwort vom Admin geändert wurde der Benutzer sein altes
nicht mehr kennt. Die Kenntnis des alten Passwortes ist jedoch zwingend
notwendig, um den privaten Schlüssel des EFS-Zertifikates zu entschlüsseln
um ihn danach mit dem neuen Passwort wieder verschlüsseln zu können.
Microsoft hat sich die Sache da einfach gemacht: jeder Benutzer ist
eigentlich "verpflichtet" ein Backup seines privaten Schlüssels
anzufertigen um ihn in einem solchen Fall wieder zurückspielen zu können,
nur teilt MS das den Benutzern nicht mit (Alternativ gibt es ja dann nur
noch den hoffentlich funktionierenden Recovery-Agent).
>> Du meinst wohl, dass es gibt keinen Klicki-Bunti-Assistenten, der vor der
>> Verwendung wenigstens die wichtigsten Punkte erklärt.
>
> Du kannst mir gern weiter solche Dinge unterstellen. Du kannst dir aber
> auch einfach überlegen, was wohl die zahlreichen Hilfesuchenden hier,
> die arglos EFS eingesetzt haben, zu solchen Bemerkungen sagen.
Ich meinte damit das Problem, dass es keinerlei Erklärungen gibt, wenn man
bei der ersten Datei den Haken "Inhalte verschlüsseln, um Daten zu
schützen". Wenn in einem solchen Fall ein Assistent aufpoppen würde, der
genau die Windows-Umgebung analysiert, ein Backup des Zertifikates anlegen
würde und die grundlegenden Eigenschaften von EFS erklären würde, hatte MS
IMHO die Zahl der Datenverluste durch den Einsatz von EFS massiv verringern
können.
> Es wäre doch so einfach: EFS ist standardmäßig deaktiviert und muss vor
> Nutzung ausdrücklich administrativ eingeschaltet werden.
Die passende GP existiert ja, nur mit den Voreinstellungen hapert es mal
wieder...
Jan
Daniel Melanchthon [MSFT]
>> Ich weiß, daß Du EFS nicht magst
>
> sagen wir: Ich habe was gegen die Designschwächen und die
> Implementierungsprobleme. Und, ja, ich war damals (Ende 1999) hoch
> begeistert davon, musste mich aber durch Kunden überzeugen lassen, dass
> der Ansatz an manchen Stellen eben nicht praxistauglich ist.
Oh je. Anscheinend wird es doch mal Zeit, das auszudiskutieren. Ich hoffe,
es stört keine, daß wir das hier in dem Thread machen.
>> aber die von Dir vorgetragene Kritik halte ich für wenig fundiert.
>
> Einigen wir uns auf: Sie überzeugt dich nicht. Das Fundament als solches
> ist gegen viele Widerstände gewachsen.
Ich gehe mal auf die einzelnen Antworten hier im Thread ein.
Daniel Melanchthon [MSFT]
> Hier ein ganz primitiver Vorschlag:
>
> Durch eine separate Passphrase? Ich bin zwar auch ein Fan von
> Einzelanmeldungen aber gerade bei dem Verschlüsseln von Dateien und
> Ordnern finde ich das mit einem anderen Kennwort besser.
Und was ist, wenn diese Passphrase vergessen wurde? Dem Benutzer mehr als
ein Paßwort zur Anmeldung aufzuzwingen, wird imho nicht mehr akzeptiert
(Stichwort Single Signon). EFS arbeitet zertifikatsbasierend.
> Ich möchte hier auch noch ein wenig meinen Senf dazugeben. EFS
> verschlüsselt ja nur die Dateien und Ordner. Ich finde Lösungen schön
> die mit einer Art virtuellen Disk arbeiten. Dadurch wird nicht nur die
> Datei verschlüsselt sondern auch die gesamte Struktur der
> verschlüsselten Daten. Das ist natürlich nur ein Schönheitsfehler aus
> meiner Sicht.
Die Nutzung von EFS erlaubt den Zugriff nicht nur lokal, sondern auch über
das Netzwerk und über andere Protoolle wie WebDAV. Mit einem
verschlüsselten Volume geht das imho nicht in dem Umfang, wie es mit EFS
möglich ist.
Daniel Melanchthon [MSFT]
> Aus Adminsicht käme mir eine Lösung wie die von Frank vorgeschlagene in
> den Sinn (separate Authentifizierung), die man ja mit einem
> Cached-Credentials-Mechanismus koppeln könnte. Nach einem
> Passwortwechsel muss ich mich einmalig neu für mein EFS-Zertifikat
> authentifizieren, fertig.
Du stellst es immer so dar, als ob der Benutzer bei jedem Passwortwechsel
mit EFS nicht mehr arbeiten kann. Das ist nicht so. Nur wenn er sein
Passwort nicht mehr weiß und man sein Passwort administrativ überschreibt
und es damit ungültig macht, ist der private EFS-Key nicht mehr zugänglich.
Genau deshalb werden bei EFS nicht die Dateien nur mit seinem Key
verschlüsselt, sondern immer auch mit einem Recovery-Agent-Key. Mit diesem
Zweitschlüssel kommt man immer an die Daten heran.
> Es wäre doch so einfach: EFS ist standardmäßig deaktiviert und muss vor
> Nutzung ausdrücklich administrativ eingeschaltet werden.
Das ist wiederum Ansichtssache. Dann würden hier die Fragen auftauchen,
wieso man die Verschlüsselung nicht nutzen kann, weil immer das Kästchen
ausgegraut ist :-) Außerdem ist es eine simple Einstellunge in den
Gruppenrichtlinen, um die Nutzung von EFS zu unterbinden.
Außerdem kann ich mich kaum an Fälle erinnern, wo jemand hier um Hilfe bar,
weil er kein DRA-Zertifikat mehr hatte *und* den Benutzer-Key verloren
hatte *und* keine Datensicherung hatte, so daß er tatsächlich einen
Datenverlust erlitt.
Die meisten Probleme hier tauchen auf, weil a) das DRA-Zertifikat
abgelaufen ist und EFS nicht mehr funktioniert oder b) weil jemand das
DRA-Zertifikat nicht gesichert hat beim Entfernen des ersten DCs und jetzt
ein neuen DRA-Zertifikat ausrollen muß.
Daniel Melanchthon [MSFT]
> Ich meinte damit das Problem, dass es keinerlei Erklärungen gibt, wenn man
> bei der ersten Datei den Haken "Inhalte verschlüsseln, um Daten zu
> schützen".
Also ich denke, daß es für die Nutzung der Verschlüsselung genügend Hilfen
gibt. Ein simple Suche nach EFS bringt Ergebnisse zu Dokumentation ohne
Ende. Sei es in der Knowledge Base:
Vorgehensweisen bei Verwendung des Verschlüsselnden Dateisystems
http://support.microsoft.com/kb/223316/de
Sichern des privaten EFS-Schlüssels für den Wiederherstellungsagenten in
Windows Server 2003, Windows 2000 und Windows XP
http://support.microsoft.com/kb/241201/de
sei es in der Windows Hilfe (hier als Beispiel der Server 2003):
Tipps zur Verwendung von EFS finden Sie unter Empfehlungen zum
verschlüsselnden Dateisystem (Encrypting File System, EFS).
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/28423d3a-b32c-44c9-8cc3-ee8ad3e01f47.mspx
Hilfe zu bestimmten Aufgaben finden Sie unter Verschlüsselndes Dateisystem:
So wird es gemacht.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/a3aa1b1f-98c9-41b3-ba05-9424e316a078.mspx
Allgemeine Hintergrundinformationen finden Sie unter Verschlüsselndes
Dateisystem (Encrypting File System, EFS) (Konzepte).
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/adfb9990-d173-4271-b118-1e13fa9d24dd.mspx
Anleitungen zum Beheben von Problemen finden Sie unter Problembehandlung
beim verschlüsselnden Dateisystem (Encrypting File System, EFS).
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/b2485418-2b3b-483e-8f70-34c3c2b9d802.mspx
sei es in TechNet-Artikeln:
Schützen von Daten durch Festplattenverschlüsselung mit EFS
http://www.microsoft.com/germany/kleinunternehmen/aufgaben/sicherheit/artikel/schuetzen-von-daten-mit-efs.mspx
Implementing the Encrypting File System in Windows 2000
http://www.microsoft.com/technet/security/prodtech/windows2000/w2kccadm/dataprot/w2kadm21.mspx
Die Wiederherstellung von verschlüsselten Daten mit EFS (Encrypting File
System) - Der 5-Minuten-Sicherheitstipp
http://www.microsoft.com/germany/technet/datenbank/articles/900941.mspx
Überall wird auf die Notwendigkeit des Sicherns der EFS-Zertifikate mit dem
privaten Schlüssel hingewiesen.
> Wenn in einem solchen Fall ein Assistent aufpoppen würde, der
> genau die Windows-Umgebung analysiert, ein Backup des Zertifikates anlegen
> würde und die grundlegenden Eigenschaften von EFS erklären würde, hatte MS
> IMHO die Zahl der Datenverluste durch den Einsatz von EFS massiv verringern
> können.
Das ist in der Tat ein guter Vorschlag, den ich einmal weitergeben werde.
Allerdings wird bei EFS immer mit einem Recovery Agent mit verschlüsselt
und dieser kann durch ein Restore auch wieder hergestellt werden. Wenn eine
Firma Daten wegen des Einsatzes von EFS verliert, weil sie a) keinen DRA
mehr hat, b) keine Datensicherung und c) den Benutzer-Key verliert, dann
wird glaube ich auch ein Assistent dagegen nichts helfen. Diese Kunden
verlieren auch auf ganz klassische Art und Weise dann Daten - deswegen sehe
ich das nicht als "Designschwäche" von EFS an.
> Die passende GP existiert ja, nur mit den Voreinstellungen hapert es mal
> wieder...
Wenn die Voreinstellung der Nutzung Steine in den Weg legen würde, kämen
die Klagen, Microsoft tut nichts, damit ein Benutzer auf einfachem Weg mehr
Datensicherheit erreichen kann. Man kann es nicht allen Recht machen. Da
Verschlüsselung eh ein Thema ist, an das die Benutzer sehr schwer
heranzuführen sind, muß meiner Meinung nach der Einsatz im laufenden
Betrieb transparent und ohne zusätzliche Hürden funktionieren, weil es
sonst nicht praktikabel ist und nicht praktiziert wird. Ich kenne viele
Rechtssanwälte, Ärzte, etc., also Berufe mit Schweigepflicht, die sich um
Verschlüsselung und damit Datenschutz nicht kümmern, weil es als zu
unkomfortabel empfunden wird, sich um Zertifikate zu kümmern. Wenn schon
die, die es müßten, es nicht machen, wird der Rest schwer folgen.
Daniel Melanchthon [MSFT]
> ich bin weder Kryptoexperte noch Betriebssystementwickler. Ich kann nur
> sagen, dass die vorliegende Lösung nicht praxistauglich ist. Und ich
> habe jahrelang versucht, Kunden vom EFS-Einsatz zu überzeugen.
Kannst Du mal posten, was exakt die Einwände Deiner Kunden sind, aus denen
Du die fehlende Praxistauglichkeit begründest? Welche Alternativen benutzen
Deine Kunden und welche Funktionen bieten die Alternativen?
Frank Röder
>
> Die Nutzung von EFS erlaubt den Zugriff nicht nur lokal, sondern auch
> über das Netzwerk und über andere Protoolle wie WebDAV. Mit einem
> verschlüsselten Volume geht das imho nicht in dem Umfang, wie es mit EFS
> möglich ist.
>
EFS über das Netz? Sprich diese super einfache und sichere Lösung mit
selektieren "Trusted for Delegation" beim Fileserver und deselektieren
von "The Account is sensitive and cannot be delegated" beim
Benutzerkonto. Ich muss also die Sicherheit heruntersetzen, um
Sicherheit zu erreichen? Das ist doch ein Widerspruch in sich selbst.
Und wenn ich nun einen NT 4.0 Fileserver einsetze? Dann habe ich auch
Pech gehabt und kann kein EFS einsetzen.
Der Einsatz eines Fileserverclusters zwingt den Admin AFAIK
servergespeicherte Benutzerprofile einzurichten. Wenn Du über das Netz
verschlüsseln willst, auf einem normalen Fileserver dann wird für jeden
Benutzer ein lokales Benutzerprofil auf dem Fileserver angelegt wenn er
kein servergespeichertes Profil nutzt. Also meiner Meinung nach, sind
das alles Punkte die nicht unbedingt akzeptabel sind.
Eine Alternative könnte z.B. sein:
"SafeGuard Easy" für das Notebook.
"SafeGuard Lan" für das LAN.
Wir haben eine Kunden der hält an seinem Steganos fest. Der Safe, so
nennt Steganos das verschlüsselte Volume ist sogar auf einem USB Stick
oder im Netz nutzbar und kann von jeden PC aus geöffnet werden, ohne das
auf dem PC eine Software installiert wird. Man benötigt halt nur das
richtige Kennwort ;-).
Und das für knapp 30€.
Uwe Weih
Daniel Melanchthon [MSFT] schrieb:
> Das ist wiederum Ansichtssache. Dann würden hier die Fragen auftauchen,
> wieso man die Verschlüsselung nicht nutzen kann, weil immer das Kästchen
> ausgegraut ist :-) Außerdem ist es eine simple Einstellunge in den
> Gruppenrichtlinen, um die Nutzung von EFS zu unterbinden.
bei uns ist der private Schlüssel des Administrators auf dem ersten DC
gesichert worden. Gestestet habe ich dann unter Windows 2000 Pro auf
einer Testinstallation, ob man damit dann eine Wiederherstellung
hinbekommt, wenn der Benutzer und sein Profil lokal gelöscht wurden.
Wie sieht das nun mit Windows XP Pro aus? Ist sicher das da auch
generell für jede mit EFS verschlüsselte Datei der öffentliche Schlüssel
des Domänenadmins mitverwendet wird. Mir fällt ein, dies nicht geprüft
zu haben?
Und wie würde man am besten EFS im ganzen Netz für die Benutzer
deaktivieren?
Ciao
Uwe
Frank Röder
> Die meisten Probleme hier tauchen auf, weil a) das DRA-Zertifikat
> abgelaufen ist und EFS nicht mehr funktioniert oder b) weil jemand das
> DRA-Zertifikat nicht gesichert hat beim Entfernen des ersten DCs und
> jetzt ein neuen DRA-Zertifikat ausrollen muß.
>
Oder "C" seine standalone Workstation neu installiert hat, seine lokale
"Datenpartition" verschlüsselt hat und jetzt alles verloren hat weil er
Arzt oder Rechtsanwalt ist (wie unten von Dir beschrieben) und es Ihm
nicht bewusst war, dass er das Zertifikat des DRA oder sein eigenes vor
der Neuinstallation sichern muss. :-(
Frank Röder
Ja, das funktioniert auch mit XP Clients.
> Und wie würde man am besten EFS im ganzen Netz für die Benutzer
> deaktivieren?
Unter W2k entfernst Du das DRA Zertifikat. Dadurch kann EFS nicht mehr
genutzt werden. Unter Windows 2003 kannst Du unter
"Computereinstellungen -> Sicherheitseinstellungen -> Richtlinien
öffentlicher Schlüssel" Rechtsklick auf "Verschlüsselndes Dateisystem"
das EFS deaktivieren.
Nils Kaczenski [MVP]
Joachim Conrad schrieb:
> Nach einem
> Anruf bei CA wurde mir mitgeteilt, dass verschlüsselte Daten aus
> rechtlichen Gründen nicht mitgesichert würden und dies auch nicht zu
> ändern sei...
wobei mir dies (zur Ehrenrettung von EFS) eher nach einer typischen
Backuphersteller-Antwort klingt als nach einem Problem mit EFS. ntbackup
sichert (meines Wissens) EFS-verschlüsselte Daten durchaus.
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
> Also ich denke, daß es für die Nutzung der Verschlüsselung genügend
> Hilfen gibt.
das ist unbestritten. Eine davon habe ich ja selbst geschrieben. ;-)
> Überall wird auf die Notwendigkeit des Sicherns der EFS-Zertifikate mit
> dem privaten Schlüssel hingewiesen.
Nur eben nicht vor dem Ersteinsatz. Du weißt doch genau, wovon hier die
Rede ist.
> Das ist in der Tat ein guter Vorschlag, den ich einmal weitergeben
> werde.
Ich finde den Vorschlag übrigens auch sehr gut.
> Allerdings wird bei EFS immer mit einem Recovery Agent mit
> verschlüsselt
No, Sir. Seit Windows XP wird kein automatischer RA mehr angelegt, wenn
der Computer standalone ist. Das Verhalten von Win2000 habe nicht dem
Wunsch von Kunden entsprochen.
> Wenn eine Firma Daten wegen des Einsatzes von EFS verliert, weil
> sie a) keinen DRA mehr hat, b) keine Datensicherung und c) den
> Benutzer-Key verliert, dann wird glaube ich auch ein Assistent dagegen
> nichts helfen. Diese Kunden verlieren auch auf ganz klassische Art und
> Weise dann Daten - deswegen sehe ich das nicht als "Designschwäche" von
> EFS an.
Falsch. EFS ist einfach da. In den meisten Firmen weiß kein Mensch in
der Administration davon, bis es zu spät ist. Auch in Firmen, die
Datensicherung sehr ernst nehmen. Ich habe schon so viele leitende
Admins schreckensbleich mit dem Hinweis auf EFS gemacht, dass ich es gar
nicht mehr zählen kann.
Und fast niemand denkt daran, dass man nach dem Aufsetzen des AD bzw.
spätestens vor dem Demoten des ersten DC vielleicht mal das Zertifikat
sichern sollte. Ich rechne es mir (ganz bescheiden) als mein Verdienst
an, dass ich in den deutschen NGs dieses Thema eingeführt habe und bei
jeder Beschreibung, die ich sehe, darauf hinweise. (Übrigens als
gebranntes Kind - mein ehemaliger Chef hat genau auf die Art seine Daten
verloren. Glücklicherweise war ich für das Netzwerk nicht
verantwortlich. Es war aber auch kein Hobby-Netzwerk, sondern das eines
langjährigen und hochkarätigen MS-Partners.)
>> Die passende GP existiert ja, nur mit den Voreinstellungen hapert es mal
>> wieder...
> Wenn die Voreinstellung der Nutzung Steine in den Weg legen würde, kämen
> die Klagen, Microsoft tut nichts, damit ein Benutzer auf einfachem Weg
> mehr Datensicherheit erreichen kann.
Nun ja. In diesem Fall sorgen die Voreinstellungen bei vielen Firmen
dafür, dass die Firmen Daten verlieren - und das ist keine
Schwarzmalerei, sondern bittere Realität. Jans Vorschlag wäre der
Königsweg. (Übrigens ist Jan bei weitem nicht der erste, der sowas
vorschlägt!)
> machen. Da Verschlüsselung eh ein Thema ist, an das die Benutzer sehr
> schwer heranzuführen sind, muß meiner Meinung nach der Einsatz im
> laufenden Betrieb transparent und ohne zusätzliche Hürden funktionieren,
> weil es sonst nicht praktikabel ist und nicht praktiziert wird.
Mein Reden, Daniel. Genau. Und genau in die Richtung müsste EFS
weiterentwickelt werden, wenn man es ernsthaft als Alternative zu
Drittanbieterlösungen positionieren will.
Zu dem Passwortproblem: Jan scheint sich mit der Implementierung ja gut
auszukennen (besser als ich). Wenn er darauf hinweist, dass das von
Frank und mir als ad-hoc-Idee vorgeschlagene Verfahren technisch sogar
vorgesehen ist, kann der Weg ja so falsch nicht sein.
Warum kein flexibles Verfahren, bei dem das EFS-Zerti auf verschiedene,
durch Nutzer bzw. Administration festgelegte Verfahren eingebunden
werden kann und etwa auf einer Smartcard oder auf einem ähnlichen Medium
liegt? Bei der ersten EFS-Nutzung in einer Session werde ich gefragt, wo
es denn liegt, und von dort wird das Zerti weiter genutzt.
> Wenn schon die, die es müßten, es nicht machen,
> wird der Rest schwer folgen.
Sicher. Aber kann das ein Argument sein, reale, berechtigte und durch
die Praxis belegte Vorbehalte einfach zu übergehen?
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
> Genau deshalb werden bei EFS nicht die
> Dateien nur mit seinem Key verschlüsselt, sondern immer auch mit einem
> Recovery-Agent-Key. Mit diesem Zweitschlüssel kommt man immer an die
> Daten heran.
seit XP eben nicht immer. Siehe anderes Posting.
> Außerdem kann ich mich kaum an Fälle erinnern, wo jemand hier um Hilfe
> bar, weil er kein DRA-Zertifikat mehr hatte *und* den Benutzer-Key
> verloren hatte *und* keine Datensicherung hatte, so daß er tatsächlich
> einen Datenverlust erlitt.
Ich kann mich an zahlreiche solcher Fälle hier in den NGs und im realen
Leben erinnern. Jedenfalls mehr als genug, um die Gefahr als eine reale
einzuschätzen.
> Die meisten Probleme hier tauchen auf, weil a) das DRA-Zertifikat
> abgelaufen ist und EFS nicht mehr funktioniert oder b) weil jemand das
> DRA-Zertifikat nicht gesichert hat beim Entfernen des ersten DCs und
> jetzt ein neuen DRA-Zertifikat ausrollen muß.
Ja. Eben. Das wäre herstellerseitig mit wenig Aufwand zu ändern, ohne
dass man EFS in die Tonne kloppen müsste.
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
> Kannst Du mal posten, was exakt die Einwände Deiner Kunden sind, aus
> denen Du die fehlende Praxistauglichkeit begründest? Welche Alternativen
> benutzen Deine Kunden und welche Funktionen bieten die Alternativen?
ist hier alles genannt worden.
Jan Peter Stotz
> Zu dem Passwortproblem: Jan scheint sich mit der Implementierung ja gut
> auszukennen (besser als ich). Wenn er darauf hinweist, dass das von
> Frank und mir als ad-hoc-Idee vorgeschlagene Verfahren technisch sogar
> vorgesehen ist, kann der Weg ja so falsch nicht sein.
Es "Vorgesehen" zu nennen, ist IMHO ein wenig übertrieben. Machbar ist es
aber definitiv, das beweisen ja unter anderem die schon verfügbaren
EFS-Recovery-Tools, die alle notwendigen Daten "von Hand" (ohne die
Unterstützung der normalerweise dafür zuständigen Win32-API-Funktionen) aus
den Dateien auslesen und zusammen mit dem Benutzer-Passwort den privaten
EFS-Schlüssel wieder auslesen können.
Im Prinzip genau so arbeitet auch die Funktion CryptUnprotectData(), die
AFAIk intern von EFS verwendet wird um den privaten Schlüssel zu
entschlüsseln, nur dass sie immer die aktuellen Anmeldedaten inkl. Passwort
verwendet und nicht erlaubt alternative Daten anzugeben.
Jan
Joachim Conrad
Nils Kaczenski [MVP] schrieb:
>> Anruf bei CA wurde mir mitgeteilt, dass verschlüsselte Daten aus
>> rechtlichen Gründen nicht mitgesichert würden und dies auch nicht zu
>> ändern sei...
>
> wobei mir dies (zur Ehrenrettung von EFS) eher nach einer typischen
> Backuphersteller-Antwort klingt als nach einem Problem mit EFS.
Ja klar, so war das auch nicht gemeint, sondern, dass es halt noch den
ein oder anderen weiteren Fallstrick geben kann.
Tschau
Daniel Melanchthon [MSFT]
>> Die Nutzung von EFS erlaubt den Zugriff nicht nur lokal, sondern auch
>> über das Netzwerk und über andere Protoolle wie WebDAV. Mit einem
>> verschlüsselten Volume geht das imho nicht in dem Umfang, wie es mit
>> EFS möglich ist.
>
> EFS über das Netz? Sprich diese super einfache und sichere Lösung mit
> selektieren "Trusted for Delegation" beim Fileserver und deselektieren
> von "The Account is sensitive and cannot be delegated" beim
> Benutzerkonto. Ich muss also die Sicherheit heruntersetzen, um
> Sicherheit zu erreichen? Das ist doch ein Widerspruch in sich selbst.
Hey, da geht es um Cluster.
> Und wenn ich nun einen NT 4.0 Fileserver einsetze? Dann habe ich auch
> Pech gehabt und kann kein EFS einsetzen.
Niemand hat behauptet, daß EFS mit Windows NT 4.0 funktioniert.
> Eine Alternative könnte z.B. sein:
> "SafeGuard Lan" für das LAN.
Dazu gleich eienmal eiene Frage: Kannst Du damit von Clents parallel mit
der gleichen und/oder mit verschiedenen Accounts read-write access über LAN
und WebDAV realisieren? Das habe ich bisher bei keiner 3rd Party Lösung
gefunden - allerdings habe ich mit Utimaco noch nichts zu tun gehabt.
> Wir haben eine Kunden der hält an seinem Steganos fest. Der Safe, so
> nennt Steganos das verschlüsselte Volume ist sogar auf einem USB Stick
> oder im Netz nutzbar und kann von jeden PC aus geöffnet werden, ohne das
> auf dem PC eine Software installiert wird. Man benötigt halt nur das
> richtige Kennwort ;-).
> Und das für knapp 30€.
Das ist wie Äpfel mit Birnen vergleichen. Oder kannst Du auf das
Steganos-Volume gleichzeitig mit verschiedenen Usern über das LAN zugreifen?
Daniel Melanchthon [MSFT]
> Oder "C" seine standalone Workstation neu installiert hat, seine lokale
> "Datenpartition" verschlüsselt hat und jetzt alles verloren hat weil er
> Arzt oder Rechtsanwalt ist (wie unten von Dir beschrieben) und es Ihm
> nicht bewusst war, dass er das Zertifikat des DRA oder sein eigenes vor
> der Neuinstallation sichern muss. :-(
Oder d) weil er mit der Windows-CD Windows neu installiert und dabei die
Festplatte löscht. Wenn der Anwender die EFS-Verschlüselungsfunktion
einsetzt, dann ist meines Erachtens es nicht zuviel verlangt, daß er
zumindest mal in die Hilfe schaut, wie das funktioniert.
Daniel Melanchthon [MSFT]
>> Genau deshalb werden bei EFS nicht die Dateien nur mit seinem Key
>> verschlüsselt, sondern immer auch mit einem Recovery-Agent-Key. Mit
>> diesem Zweitschlüssel kommt man immer an die Daten heran.
>
> seit XP eben nicht immer. Siehe anderes Posting.
Wenn XP nicht Mitglied einer Domäne ist, also als Standalone-PC arbeitet,
dann ist das nicht vorgesehen. Da gibt es ja dann auch keine zentrale
Administrationsmöglichkeit via Domäne und daher halte ich es für
vertretbar, daß man dort einen DRA selbst konfigurieren muß, wenn man ihn
haben möchte. Übrigens ist in der XP-Hilfe die erste Aufgabe zum Thema EFS
"Ändern der Wiederherstellungsrichtlinie für den lokalen Computer", wo das
Erstellen eines DRA Schritt für Schritt erläutert wird.
> Ich kann mich an zahlreiche solcher Fälle hier in den NGs und im realen
> Leben erinnern. Jedenfalls mehr als genug, um die Gefahr als eine reale
> einzuschätzen.
Ich persönlich bin sicher, daß es noch wesentlich mehr Datenverluste wegen
mangelndem Patchen, mangelnder Datensicherung, mangelnder
Administrationsfähigkeit, mangelnder Ausfallsicherheit, etc. gibt. Da
verteufelt auch niemand sofort Windows komplett. Das System wird nunmal
nicht jeden Fehler, den Benutzer im Leben machen können, auffangen können.
Deshalb finide ich die Kritik an EFS hier für maßlos überzogen. Der einzige
Punkt, dem sich zustimme, ist, daß es einen deutlichen Hinweis zum Beispiel
auf die Hilfe geben sollte, wenn man zum ersten Mal Daten verschlüsselt (da
die Hilfe eh selten gelesen wird).
Frank Röder
> Frank Röder schrieb:
>
>>> Die Nutzung von EFS erlaubt den Zugriff nicht nur lokal, sondern auch
>>> über das Netzwerk und über andere Protoolle wie WebDAV. Mit einem
>>> verschlüsselten Volume geht das imho nicht in dem Umfang, wie es mit
>>> EFS möglich ist.
>>
>>
>> EFS über das Netz? Sprich diese super einfache und sichere Lösung mit
>> selektieren "Trusted for Delegation" beim Fileserver und deselektieren
>> von "The Account is sensitive and cannot be delegated" beim
>> Benutzerkonto. Ich muss also die Sicherheit heruntersetzen, um
>> Sicherheit zu erreichen? Das ist doch ein Widerspruch in sich selbst.
>
>
> Hey, da geht es um Cluster.
Nö, da geht es nicht um Cluster sondern um ganz einfache Fileserver.
Der Server braucht ja die Impersonifizierung um an das Zertifikat und
den privaten Schlüssel des Users zu kommen.
>> Und wenn ich nun einen NT 4.0 Fileserver einsetze? Dann habe ich auch
>> Pech gehabt und kann kein EFS einsetzen.
>
>
> Niemand hat behauptet, daß EFS mit Windows NT 4.0 funktioniert.
Erkläre das mal einem GF der an einer XP Workstation sitzt und kein EFS
nutzen kann, weil er einen NT 4.0 Fileserver hat.
>> Eine Alternative könnte z.B. sein:
>> "SafeGuard Lan" für das LAN.
>
>
> Dazu gleich eienmal eiene Frage: Kannst Du damit von Clents parallel mit
> der gleichen und/oder mit verschiedenen Accounts read-write access über
> LAN und WebDAV realisieren? Das habe ich bisher bei keiner 3rd Party
> Lösung gefunden - allerdings habe ich mit Utimaco noch nichts zu tun
> gehabt.
Ja, hier kannst Du mehrere verschiedene Benutzer berechtigen auf die
Dateien zuzugreifen. Das "Safeguard Lan" arbeitet ähnlich wie EFS und
verschlüsselt die einzelnen Ordner und Dateien. Es gibt noch ein
weiteres Produkt was "SafeGuard PrivateDisk" heisst und das stellt ein
verschlüsseltes Volume bereit, auf das auch mehrere Nutzer zugreifen können.
Besonders witzig finde ich das Safeguard Easy. Dort verschlüsselst Du
die ganze Platte, wenn Du es willst. Die Performance leidet übrigens
kaum merkbar darunter. Das ist das ideale Tool für Notebookuser.
Mit EFS kann ich keine Betriebssystemdateien verschlüsseln :-(
>> Wir haben eine Kunden der hält an seinem Steganos fest. Der Safe, so
>> nennt Steganos das verschlüsselte Volume ist sogar auf einem USB Stick
>> oder im Netz nutzbar und kann von jeden PC aus geöffnet werden, ohne
>> das auf dem PC eine Software installiert wird. Man benötigt halt nur
>> das richtige Kennwort ;-).
>> Und das für knapp 30€.
>
>
> Das ist wie Äpfel mit Birnen vergleichen. Oder kannst Du auf das
> Steganos-Volume gleichzeitig mit verschiedenen Usern über das LAN
> zugreifen?
Ja das geht. Dafür gibt es eine "Stegano Safe Professional". Diese
Lösung ist sogar über das AD mit Grulis administrierbar. ;-)
--
Viele Grüße
Frank Röder
"Ex oriente lux"
Daniel Melanchthon [MSFT]
>> Hey, da geht es um Cluster.
>
> Nö, da geht es nicht um Cluster sondern um ganz einfache Fileserver.
> Der Server braucht ja die Impersonifizierung um an das Zertifikat und
> den privaten Schlüssel des Users zu kommen.
Ich mneinte den Link, den ich gepostet hatte, weil ich dachte, Du beziehst
Dich auf meinen Link.
>> Niemand hat behauptet, daß EFS mit Windows NT 4.0 funktioniert.
>
> Erkläre das mal einem GF der an einer XP Workstation sitzt und kein EFS
> nutzen kann, weil er einen NT 4.0 Fileserver hat.
Ganz einfach: "Mit Windows NT 4.0 als Fileserver können Sie kein EFS
nutzen." Wo ist das Problem ;-)
>> Dazu gleich eienmal eiene Frage: Kannst Du damit von Clents parallel
>> mit der gleichen und/oder mit verschiedenen Accounts read-write access
>> über LAN und WebDAV realisieren? Das habe ich bisher bei keiner 3rd
>> Party Lösung gefunden - allerdings habe ich mit Utimaco noch nichts zu
>> tun gehabt.
>
> Ja, hier kannst Du mehrere verschiedene Benutzer berechtigen auf die
> Dateien zuzugreifen. Das "Safeguard Lan" arbeitet ähnlich wie EFS und
> verschlüsselt die einzelnen Ordner und Dateien.
Um die Frage zu präzisieren: Ich meinte read+write. In der Dokumentation zu
dem Produkt steht: "Mehrere berechtigte Nutzer erhalten Lesezugriff auf ein
gemeinsames sicheres Laufwerk im Netzwerk." Da steht nichts von
Schreibzugriff. Ich habe den Hersteller mal angemailt und ihn direkt gefragt.
Genau das, finde ich, ist in der Praxis der Knackpunkt. Stell Dir drei GFs
und das Personalbüro vor, die mit sensitiven Daten verschlüsselt arbeiten
wollen. Da brauchst Du parallelen Schreibzugriff.
> Es gibt noch ein
> weiteres Produkt was "SafeGuard PrivateDisk" heisst und das stellt ein
> verschlüsseltes Volume bereit, auf das auch mehrere Nutzer zugreifen
> können.
Utimaco habe ich das gleiche auch mal gefragt.
> Besonders witzig finde ich das Safeguard Easy. Dort verschlüsselst Du
> die ganze Platte, wenn Du es willst. Die Performance leidet übrigens
> kaum merkbar darunter. Das ist das ideale Tool für Notebookuser.
> Mit EFS kann ich keine Betriebssystemdateien verschlüsseln :-(
Dafür ist EFS ja auch nicht da. Du kannst damit ja auch kein Kaffee kochen
;-) BTW: Drive Encryption kommt mit Vista:
http://www.microsoft.com/technet/windowsvista/library/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx
>> Das ist wie Äpfel mit Birnen vergleichen. Oder kannst Du auf das
>> Steganos-Volume gleichzeitig mit verschiedenen Usern über das LAN
>> zugreifen?
>
> Ja das geht. Dafür gibt es eine "Stegano Safe Professional". Diese
> Lösung ist sogar über das AD mit Grulis administrierbar. ;-)
Imho nur read-only. Aber ich laß mich gern vom Gegenteil überzeugen...
Frank Röder
>> Ja das geht. Dafür gibt es eine "Stegano Safe Professional". Diese
>> Lösung ist sogar über das AD mit Grulis administrierbar. ;-)
>
>
> Imho nur read-only. Aber ich laß mich gern vom Gegenteil überzeugen...
>
Wäre mal ein interessantes Thema für einen Webcast ;-)
Ich stelle mich gern freiwillig zur Verfügung um die Third Party Tools
vorzustellen.
Hier ein Titelvorschlag:
Microsoft EFS vs. Third Party Encryption
Daniel Melanchthon [MSFT]
> Hier ein Titelvorschlag:
> Microsoft EFS vs. Third Party Encryption
Das ist ja genau das, was ich nicht will. Es geht nicht um "vs.". Jedes
Tool hat seinen spezifischen Einsatzzweck. Ich wehre mich nur dagegen, EFS
grundsätzlich zu verteufeln, weil es für bestimmte Zwecke meines Erachtens
sehr gut eingesetzt werden kann. Für den, der mehr will, gibt es
Drittanbieterprodukte, die weitere Einsatzgebiete abdecken. Aus den zur
Verfügung stehenden Tools kann dann der Admin sich das heraussuchen, was
seinem Einsatzzweck am nähesten kommt.
Das mit dem Webcast behalte ich aber mal im Hinterkopf. Ich komme auf Dich
zurück (und das ist keine Drohung, sondern ein Versprechen).
Frank Röder
> Frank Röder schrieb:
>
>> Hier ein Titelvorschlag:
>> Microsoft EFS vs. Third Party Encryption
>
>
> Das ist ja genau das, was ich nicht will. Es geht nicht um "vs.". Jedes
> Tool hat seinen spezifischen Einsatzzweck. Ich wehre mich nur dagegen,
> EFS grundsätzlich zu verteufeln, weil es für bestimmte Zwecke meines
> Erachtens sehr gut eingesetzt werden kann. Für den, der mehr will, gibt
> es Drittanbieterprodukte, die weitere Einsatzgebiete abdecken. Aus den
> zur Verfügung stehenden Tools kann dann der Admin sich das heraussuchen,
> was seinem Einsatzzweck am nähesten kommt.
>
> Das mit dem Webcast behalte ich aber mal im Hinterkopf. Ich komme auf
> Dich zurück (und das ist keine Drohung, sondern ein Versprechen).
>
am 30.01.2006 in Dresden.
Nils Kaczenski [MVP]
Frank Röder schrieb:
> Erkläre das mal einem GF der an einer XP Workstation sitzt und kein EFS
> nutzen kann, weil er einen NT 4.0 Fileserver hat.
naja, das Argument zieht aber nicht so. Utimaco kann ich auch nur
nutzen, wenn ich es vorher beschafft habe.
> Besonders witzig finde ich das Safeguard Easy. Dort verschlüsselst Du
> die ganze Platte, wenn Du es willst. Die Performance leidet übrigens
> kaum merkbar darunter. Das ist das ideale Tool für Notebookuser.
Das haben wir übrigens auch im Einsatz und sind sehr zufrieden damit.
Ich habe allerdings offen gestanden keine Ahnung, wie dort das
Passwort-/Schlüsselmanagement funktioniert und ob es auch
enterprisefähig ist.
> Mit EFS kann ich keine Betriebssystemdateien verschlüsseln :-(
Naja, das alleine fände ich noch nicht spannend. Interessanter finde
ich, dass man ohne Authentifizierung gar nicht erst booten kann.
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
> Ich wehre mich nur dagegen,
> EFS grundsätzlich zu verteufeln, weil es für bestimmte Zwecke meines
> Erachtens sehr gut eingesetzt werden kann.
wenn ihr dann noch das Problem löst, dass es standardmäßig eingeschaltet
ist ... ;-)
... ach ja, und war es nicht auch so, dass ich zum Rollout von
RA-Zertifikaten einen Windows Enterprise brauche? (Ich mag mich irren,
dann korrigiert mich - falls ich aber nicht irre, wäre auch das ein zu
korrigierender Punkt, wenn man EFS als sinnvolle Lösung für
Standardzwecke positionieren will.)
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
> Wenn der Anwender die EFS-Verschlüselungsfunktion
> einsetzt, dann ist meines Erachtens es nicht zuviel verlangt, daß er
> zumindest mal in die Hilfe schaut, wie das funktioniert.
naja. Dann hätte man aber mehr machen sollen, als die Verschlüsselung
nur hinter einem "Erweitert"-Button zu verstecken. Das GUI lässt einen
einfach anderes vermuten, zumal EFS eine Clientgeschichte ist. Für einen
durchschnittlich windowstauglichen Benutzer sieht EFS nicht wilder aus
als NTFS-Berechtigungen. Es ist aber eben wesentlich wilder.
Jan Peter Stotz
> ... ach ja, und war es nicht auch so, dass ich zum Rollout von
> RA-Zertifikaten einen Windows Enterprise brauche?
Nein. Ein Rechner mit XP oder W2K3 ist ausreichend. Auf dem kann man dann
via "cipher /R" ein RA-Zertifikat erzeugen, das sich danach problemlos über
eine GP verteilen lässt. Dann muss man nur noch die Benutzer dazu bringen
"cipher /U" auszuführen...
Jan
Daniel Melanchthon [MSFT]
> .... ach ja, und war es nicht auch so, dass ich zum Rollout von
> dann korrigiert mich - falls ich aber nicht irre, wäre auch das ein zu
> korrigierender Punkt, wenn man EFS als sinnvolle Lösung für
> Standardzwecke positionieren will.)
Braucht man nicht. Man braucht noch nicht einmal eine CA als
Mindestanforderung. cipher.exe kann einen DRA-Schlüssel erstellen. Ich
schreibe gerade einen Blogartikel darüber. Oder doch gleich ein Howto auf
faq-o-matic.net?
Daniel Melanchthon [MSFT]
Daniel Melanchthon [MSFT] schrieb:
>> Wenn in einem solchen Fall ein Assistent aufpoppen würde, der
>> genau die Windows-Umgebung analysiert, ein Backup des Zertifikates
>> anlegen
>> würde und die grundlegenden Eigenschaften von EFS erklären würde,
>> hatte MS
>> IMHO die Zahl der Datenverluste durch den Einsatz von EFS massiv
>> verringern
>> können.
>
> Das ist in der Tat ein guter Vorschlag, den ich einmal weitergeben
> werde.
Die Weitergabe hat sich schon erledigt. Mit der aktuellen Beta von Vista
kan man das neue Verhalten schon ausprobieren. Bei der Erstbenutzung geht
ein Bubble neben dem System Tray auf, der darauf hinweist, daß man den
EFS-Schlüssel sichern sollte. Darauf geklickt geht es zum Sichern des Keys...
Yusuf Dikmenoglu at
> Vista kan man das neue Verhalten schon ausprobieren. Bei der
> Erstbenutzung geht ein Bubble neben dem System Tray auf, der darauf
> hinweist, daß man den EFS-Schlüssel sichern sollte. Darauf geklickt
> geht es zum Sichern des Keys...
Seehhrr Lobenswert ;-) und Danke für den Hinweis
--
Viele Grüße aus Mainz
Yusuf Dikmenoglu
The World meet`s in one Community
http://www.unterwegs-im.net
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
> Braucht man nicht.
um so besser.
> schreibe gerade einen Blogartikel darüber. Oder doch gleich ein Howto
> auf faq-o-matic.net?
Gern!
Nils Kaczenski [MVP]
Daniel Melanchthon [MSFT] schrieb:
> Bei der Erstbenutzung
> geht ein Bubble neben dem System Tray auf, der darauf hinweist, daß man
> den EFS-Schlüssel sichern sollte. Darauf geklickt geht es zum Sichern
> des Keys...
wow! Die lesen hier also mit und setzen das in bereits verteilten Betas
um! ;-))