Re: EFS and DRA. Admin unable to decrypt
From: drunkardswalk@earthlink.net
Date: 02/14/03
- Next message: drunkardswalk@earthlink.net: "Re: REGISTRY AND POLICIES"
- Previous message: Jupiter Jones: "Re: Roll XP Retail licences to Volume license?"
- In reply to: Ellen: "Re: EFS and DRA. Admin unable to decrypt"
- Next in thread: yoggie: "Re: EFS and DRA. Admin unable to decrypt"
- Reply: yoggie: "Re: EFS and DRA. Admin unable to decrypt"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: drunkardswalk@earthlink.net Date: Fri, 14 Feb 2003 15:58:04 -0700
On Fri, 14 Feb 2003 17:31:56 +0100, "Ellen" <pan.01@arcor.de> wrote:
>Hi yoggie,
>everything you told me is ok and I understand it, but i still have
>the problem.
>
>Itīs clear that the DRA and his certificate (.cer and .pfx ) must
>be the first thing on the machine, after that I log in as a user and encrypt
>a file.
>
>I also imported the .pfx file in the personal-store of the certificate
>snap-in. I checked it and I can see in the properties that the certificate
>has a private key, so i am sure he has taken the .pfx file.
>
>When I import the .pfx file in the personal-store he shows me in the
>properies
>that the certificate is not trusted. But I think this is also ok, I have
>read that he makes a
>self-signed certificate (which is always not trusted) when you are on a
>stand-alone PC
>and EFS accepts it for valid.
>
>(By the way I made a test and imported it in the trusted people store
>too.The properties tell
>me that now I have a trustet certificate but the effect is just the same.
>I am not able to decrypt.)
>
>In your first answer to me you wrote that I should also try to import the
>.pfx file in the local
>group policies. Thatīs not impossible, the Import-wizzard gives me only the
>possibility to import .cer files, no other
>extensions are available. I donīt know another way how I could import the
>.pfx file in the local group
>policies without an wizzard. Do you?
>
>But I donīt think that there is something wrong with the certificate itself,
>because when I log in as a user and look at
>the properties of the encrypted file I see that the DRA is listed and I see
>the thumbprint of the DRA. The thumbprint
>is exactly the same as shown in the properties of the certificate of the DRA
>when I am logged in as DRA.
>When the thumbprint is identical then I should be able to decrypt the file.
>But it doesnīt work.
>
>Slowly but clearly I get mad about this.
>
>regards
>Ellen
I can understand how aggravating it all is. The only fault here,
though, is possibly in MS' weak documentation. Even the Platform SDK
doesn't tell you everything you really need to know to work with this
stuff.
However, the problems you're running up against are in the nature of
the encryption algorithms. If it were possible to just add a recovery
authority to an encrypted file after the fact, you'd have no security
at all, since that would mean than all anyone would have to do to
decrypt a file encrypted by someone else would be to put it on their
own machine and declare an RA for it. You surely don't want that.
Were that the way it worked, thee'd be no point in even using EFS.
The whole point of encryption is to keep people you don't want to see
your files from seeing them. That means that the mechanism that
allows you to assign a recovery authority has to be in place *before*
a file is encrypted which that RA might have to decrypt. Again, it's
because the RA's certificate becomes part of the encryption key.
Likewise for encrypted files shared with other users; all the
certificates are used to generate encryption keys.
There are a few more gotchas you need to watch out for. Since you're
having problems, I'll mention them now, and maybe save you some grief
later. If I miss something or get something wrong, I'm sure someone
will jump in and correct me.
First, once you do create an RA, *don't* kill the RA from the system
if you can help it, because you won't be able to modify any encrypted
files until a user with a private key for the file (usually the one
who originally encrypted it) accesses it in such a way as to cause it
to update. So long as *someone* has a private key to all the
encrypted files, you're okay, but it's still a mess.
Second, although MS recommends encrypting your temp directories, do it
with great caution. *NEVER* encrypt the Local System account's temp
directory (%WINDIR%\temp by default), because then the system can only
run when the account that encrypted its temp directory is the one
logged in. You can encrypt your personal temp directory
(%USERPROFILE%\Local Settings\Temp by default), but you'll have to
unencrypt it to do several things without problems. For instance,
it's not a good idea to hit the MS update site for automatic updates
with this directory encrypted, as it can cause some installations to
fail (I forget the knowledgebase article number for this, but it's in
there if you look for it). Likewise, some software uses the user temp
directory for a place to drop stuff during install. Unfortunately, it
can end up installing encrypted software. And some programs that use
the temp dir for other things don't deal gracefully with the
encryption. Just as an example, install BlackICE Defender with an
encrypted temp directory and you'll end up with BlackICE's INI files
encrypted in its own installation directory, which prevents them from
being modified, even if you're the 500 admin.
Third, as I mentioned in an earlier post, export the RA key and
certificate to an offline medium (in duplicate, in different
locations!) and delete the recovery key (but not the RA certificate)
from the system. The purpose of the RA account is emergency recovery,
so such a powerful key shouldn't be on the system until it's needed.
When it is, import it, use it to decrypt what you have to, and delete
it again.
Fourth, and possibly most important, always keep multiple backups
stored in different, secure physical locations of *all* your user
certificates. This means any RA certificates and keys, as well as any
certificates and keys you may have installed, and certainly the EFS
certificates and keys for your user accounts. Unless you installed
specific EFS certificates, W2K and XP automatically generate
self-signed certificates for a user the first time he encrypts a file.
Make sure you export and save the PFX file with *both* the certificate
and the key; the certificate alone can't do anything except encrypt or
verify. It can't decrypt on its own. Side note: while you're doing
that, it's a good time to go the Users Control Panel tool and save off
password recovery information for each account. Keep it all stored
together, and you'll save yourself worlds of grief.
Oh, one last thing. MS recommends that you create a separate account
for the RA, and use it *only* for RA purposes. Good idea, because it
keeps the main admin account from becoming too powerful, in the event
of a system compromise. I suppose it should also go without saying
that all the EFS stuff in the world is moot in the absence of good
security policies regarding all the other issues, like login security,
physically securing the machine, having appropriate file and registry
permissions, and so on. Else, you're just wasting clock cycles
encrypting and decrypting files on a machine with no security anyway.
Gee, that turned into something of a short-short-story <g>. And I'm
not even being paid by the word. Good thing I type 90 wpm <g>.
Reid the Verbose and Occasionally Obtuse (and Alliterative <g>)
- Next message: drunkardswalk@earthlink.net: "Re: REGISTRY AND POLICIES"
- Previous message: Jupiter Jones: "Re: Roll XP Retail licences to Volume license?"
- In reply to: Ellen: "Re: EFS and DRA. Admin unable to decrypt"
- Next in thread: yoggie: "Re: EFS and DRA. Admin unable to decrypt"
- Reply: yoggie: "Re: EFS and DRA. Admin unable to decrypt"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
