News reader software failure. The EFS question in a nutshell.
From: M. Jennings (mjennings_at_-NOTthis-or-dashes-myrealbox.com)
Date: 03/20/05
- Next message: BAR: "RE: "Installer Mode".."
- Previous message: Shenan Stanley: "Re: warning your computer is at risk"
- In reply to: Pat Hoffer [MSFT]: "RE: Deleting the certificate does not stop decryption!"
- Next in thread: Admiral Q: "Re: Doesn't Micrososoft have anything better?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 20 Mar 2005 05:56:12 -0300
Pat,
My newsreader software failed, and posted three copies of my previous message.
The EFS question: In numerous places, readers are told that they can recover
encrypted files if they have the .PFX file. Sometimes they are told that only
a .CER file (apparently with no private key) is sufficient for recovery. Yet
you seem to indicate below that is not true, and my tests show it is not true.
My tests show that I cannot read files from an account with the same user name
and the same user name password on another computer. Encrypted data seems to
be tied to Windows and a particular Windows installation. Users seem to be
losing control of their data in a way they would never accept if they understood.
What then is the minimum required to recover encrypted files? I need an
understanding and step-by-step instructions so I can do it myself. The
instructions cannot involve a domain, since there are numerous instances in
which someone traveling may need to recover data without involvement with a
home office, particularly in less-developed foreign countries.
Thank you,
Michael
__________________________
Pat Hoffer [MSFT] wrote:
> Yes, the data is very domain-oriented, theoretical, and lengthy (and needs to
> be addressed). The KB articles tend to be more specific, so I thought those
> might be helpful to look through. EFS was designed with a domain environment
> in mind. Domains have the default EFS recovery policy (a File Recovery
> certificate and key stored on the DC), that can be used to recover users'
> encrypted files when issues arise. That is why there is so much
> documentation in that direction.
>
> The reality is that many non-domain users are using EFS, also. The best
> "recovery policy" for non-domain users is to back up their EFS
> certificates/keys. This has not been well-addressed in documentation, which
> is why I keep promoting "cipher /x" on this newsgroup. (WS2003 actually
> shipped with a backup UI for this.)
>
> You said you can still decrypt your files even though you have deleted your
> EFS certificate. EFS keeps your private key in cache until you log off. Try
> logging off and then on again, and you should get access denied to those
> files. As for moving encrypted files between standalone machines, EFS was
> not designed in WinXP to do that. (Win2K was a different story.)
>
> The "password change" issue was caused by another Windows component that
> encrypts your EFS private key with your password to keep it secure. When you
> log on and then access an encrypted file, this component decrypts your EFS
> key (using your password) and hands it to EFS. In a domain environment, the
> component had to be able to reach the DC to confirm that the new password is
> correct before it can decrypt your key. This caused a problem for domain
> users who were disconnected from their networks when they tried to access
> encrypted files for the first time after a password change. This issue has
> been fixed in the service packs for WinXP and in SP4 for Win2K.
>
> The bottom line is that if you back up your EFS certificate/key, your bases
> are covered. Do this: encrypt a new file (EFS will create a new certificate
> since you've deleted the original), run "cipher /x" at command line to create
> a .pfx file, delete your new EFS certificate, log off and on, try to open the
> new file (you shouldn't), run or double-click the .pfx file to import the
> certificate (select to make the key exportable), and try to open the new file
> again (you should).
>
> That's probably more than you ever wanted to know, but I hope it helps.
> Thanks for your comments regarding the documentation. I'll pass that on.
>
> Thanks.
> Pat
>
> "M. Jennings" wrote:
>
>
>>Pat,
>>
>>Thanks for your reply.
>>
>>If you read all of Microsoft's documentation carefully, you will find that the
>>explanation just is not there. There are plenty of "overviews" that cover the
>>same information.
>>
>>Only if I can move the files between different accounts on different
>>stand-alone computers will I know I understand how EFS works. I have been
>>unable to do that.
>>
>>I deleted my personal certificate, but the files in a test directory are still
>>automatically decrypted. This also shows that I don't understand EFS.
>>
>>I need to be able to change my logon password without losing my encrypted files.
>>
>>I don't understand why they say "Recovery Certificate", when supposedly the
>>Recovery Certificate does not include the private key. With no private key, it
>>is impossible to decrypt files.
>>
>>Pat, do a search on EFS in the newsgroups. People are having a very difficult
>>time with encryption. They are losing files. It is easy to encrypt, and
>>difficult to know how the encryption works.
>>
>>Two people have advised me to use non-Microsoft products. People are directing
>>other people to poorly written and formatted non-Microsoft web pages.
>>
>>Part of the confusion is obvious from the fact that there are so many web
>>Microsoft web pages devoted to the same incomplete explanations. EFS is
>>different between Windows 2000 and Windows XP, but often the web pages refer
>>to both seemingly indiscriminately. Those who did the writing were confused
>>about the differences between EFS when connected to a domain, and EFS on a
>>stand-alone computer.
>>
>>Michael
>>
>>_________________________
>>
>>Pat Hoffer [MSFT] wrote:
>>
>>>Here's a Microsoft site with information about EFS:
>>>
>>>http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx
>>>
>>>Thanks.
>>>Pat
>>>
>>>"M. Jennings" wrote:
>>>
>>>
>>>
>>>>I'm wanting to understand the same issues. Many, many people lose their
>>>>encrypted files, partly because Microsoft's explanation is so poor.
>>>>
>>>>The web site you referenced is very poorly written and formatted. Doesn't
>>>>Micrososoft have anything better? I notice that that web site is mentioned a lot.
>>>>
>>>>Thanks, Michael
>>>>
>>>>___________________________
>>>>
>>>>Torgeir Bakken (MVP) wrote:
>>>>
>>>>
>>>>>NewComrMSNETFam wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>Dont ask, I realy don't know but it look like that I cannot open my
>>>>>>encrypted files.
>>>>>>This is to say that the assicated user key of the account with the
>>>>>>problem are misplaced or lost.
>>>>>>
>>>>>>Q1) If the key is not lost but missplaced, who can I locate it and
>>>>>>place it back at the right place?
>>>>>>Q2) If the key is lost, I have a data and system backup of my machine
>>>>>>using the "Backup" program. How can I locate and extract from the
>>>>>>backup the missing key?
>>>>>
>>>>>Hi
>>>>>
>>>>>If you can restore the user profile folders for the user that
>>>>>encrypted the files and if you remember the password for the user
>>>>>when the backup was taken, you might be able to save the files.
>>>>>
>>>>>Take a look at this site for more details:
>>>>>
>>>>>http://www.beginningtoseethelight.org/efsrecovery/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
- Next message: BAR: "RE: "Installer Mode".."
- Previous message: Shenan Stanley: "Re: warning your computer is at risk"
- In reply to: Pat Hoffer [MSFT]: "RE: Deleting the certificate does not stop decryption!"
- Next in thread: Admiral Q: "Re: Doesn't Micrososoft have anything better?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
