EFS encrypted data cannot be moved to another standalone computer?

From: M. Jennings (mjennings_at_-NOTthis-or-dashes-myrealbox.com)
Date: 03/20/05


Date: Sat, 19 Mar 2005 21:25:03 -0300

Pat,

First, I want to say that your reply is very, very much appreciated.

You said below: "As for moving encrypted files between standalone machines,
EFS was not designed in WinXP to do that. (Win2K was a different story.)"

Wow! There is nothing in the documentation that hints at this!

Do I understand you correctly? There is no way whatsoever to decrypt an EFS
encrypted file on a computer other than the one on which it was encrypted,
unless the computer is attached to a domain?

This means that the encrypted data is, basically, owned by Windows 2003?

Do I understand correctly that Microsoft made a change between EFS in Windows
2000 and EFS in Windows 2003/XP, without adequately notifying users?

You said, '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.'

You also say below: "The bottom line is that if you back up your EFS
certificate/key, your bases are covered."

I don't understand how backing up my .PFX and .CER files helps me, if I cannot
use them on a different computer. What would happen if a user with a single
computer lost his or her computer because of theft? Would there be no way to
recover the information, even if he or she had backups?

I tried reading my EFS encrypted test data on a second computer with the same
account name and password, and it would not decrypt.

What about the computer on which I originally EFS encrypt is unique, so that I
cannot transport my encrypted data elsewhere? When is a backup of .CER and
.PFX files not a real backup for the data?

If I understand this correctly, it strikes me as cruel. I saw one newsgroup
posting in which a man said he had lost 11 years of research. EFS works in a
way that is counter-intuitive and not documented.

You said, "That's probably more than you ever wanted to know, but I hope it
helps."

It's not more than I wanted to know. It does help, a lot.

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



Relevant Pages

  • RE: EFS File Share Help
    ... And your roaming profile cannot work properly. ... If user tries to encrypt a remote file/folder stored ... user, and subsequently requests, or generates a self-signed EFS ... The certificate and private key are loaded in a local profile ...
    (microsoft.public.windows.server.sbs)
  • EFS Trouble - External Drive
    ... I exported my EFS certificate AND private key from machine A and successfully imported it onto machine B. I can see the certificate AND private key of machine A in machine B's certificate store. ... Now, when I encrypt files on the USB drive using machine A, machine B cannot read them. ... I have spent more than three hours reading every technet article regarding EFS as well as other people's problems posted on various boards and in this group. ...
    (microsoft.public.windowsxp.security_admin)
  • RE: EFS Trouble - External Drive
    ... successfully imported it onto machine B. I can see the certificate AND ... private key of machine A in machine B's certificate store. ... Now, when I encrypt files on the USB drive using machine A, machine B ... regarding EFS as well as other people's problems posted on various ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Certificates, Keys, Mobile Users, Intended Usage
    ... Option that you think about uses self signed EFS certificates. ... Better then exporting user's private key as backup is to setup DRA (Data ... there is no EFS certificate and it will generate a new one. ... Mobile computer users benefit from encrypting sensitive ...
    (microsoft.public.win2000.security)
  • Re: EFS Errors
    ... Disabling DFS can disrupt your Group Policy propagation which may be causing ... your EFS errors if you have changed your Recovery Agent Certificate. ... I am able to encrypt on the server but noone is able to encrypt ...
    (microsoft.public.security)

Quantcast