DRA is Decrypting Files when it shouldn't be!!!

[Guest]

I setup a brand new XP install. Setup a new local user named Joe and logged
in as Joe . Created a new directory and encrypted 200 files in this
directory.

Logged off and and logged in as Administrator. Created a DRA (ex: Cipher
/r:Filename, imported certificate and private key into the local certificate
store, Ran gpedit.msc and added DRA.). After this, I tried to unencrypt the
directory while logged in as Administrator and it let me!!! Why is this? It
shouldn't allow me to decrypt 200 files that were encrypted before a DRA was
created.

I don't get this crap. Many articles state that you have to create the DRA
before encrypting the files so that the DRA can decrypt them. If you don't
then, you need to run cipher /u to update the encrypted files so that the
newly created DRA will work with older encrypted files.

In my case, I created the DRA after the files were already encrypted and
"never" ran a cipher /u. Does anybody know what could cause this?

Thanks, DJ

 

[Steven L Umbach]

Hmm. Have you tried that first exporting/deleting the user's private key
before creating the RA to see what happens or rebooting the computer before
you created the RA with cipher /R with the user's private key still on the
computer? XP is supposed to flush EFS cache at logoff. Did you remove any
old RA from the RA user certificate store via mmc snapin for certificates
and then logoff as the RA? You can use efsinfo to see what RAs are included
in a user's EFS file and examine the certificate thumbprint to see exactly
what RA certificate is being used if there are more than one available. You
might also want to post in the Microsoft.public.security.crypto
wsgroup. --- Steve

 

[Guest]

Steve, I did what you said (below) and "exported" & "deleted" the user's
private key and now it's acting correctly. Why is this?

I don't understand, please explain.

Thanks, DJ

 

[Steven L Umbach]

So what did you exactly do? Create a user, encrypt some files, remove the
user' EFS certificate private key, create an RA, and not be able to decrypt
files as RA or did you use your current configuration where the RA could
decrypt user's files, remove user's EFS certificate private key, and RA can
no longer decrypt files?? Did you look to see if RA had more then one RA
certificate?? --- Steve

 

[Guest]

Let's go over this again...

OS setup:

Installed a fresh copy of XP. Forget about extra RA's. There is only one RA
with this setup. I dedicated the Administrator's account as the RA.

Problem:

EFS is allowing the RA to decrypt 200 files that were encrypted BEFORE an RA
was actually created on the XP OS. My question is Why?

I was told by "many people" that you have to setup the RA BEFORE enabling
encryption to get the RA to decrypt encrypted files.

Steps I took:

I created a user, encrypted 200 files. Logged off and logged on as
Administrator and created a RA. Rebooted and logged in as Administrator and
decrypted the 200 files.

In this case here, I created the RA after the files were already encrypted,
so why am I ABLE to decrypt the 200 files?

Anyway, to resolve the problem, you asked me to do an experiment and told me
to "export" & "delete" the user's private key, before creating the RA. I did
this, and now the RA cannot delete the 200 files (which is the way it suppose
to work)

My question is, why did you suggest to "export" & "delete" the user's
private key, then create the RA? And also why does this work and what did I
do wrong?

Thanks, Dave

---------------------------------------------------

 

[Brian Komar [MVP]]

Answers inline:

Let's go over this again...

OS setup:

Installed a fresh copy of XP. Forget about extra RA's. There is only one RA
with this setup. I dedicated the Administrator's account as the RA.

Problem:

EFS is allowing the RA to decrypt 200 files that were encrypted BEFORE an RA
was actually created on the XP OS. My question is Why?

I was told by "many people" that you have to setup the RA BEFORE enabling
encryption to get the RA to decrypt encrypted files.

Steps I took:

I created a user, encrypted 200 files. Logged off and logged on as
Administrator and created a RA. Rebooted and logged in as Administrator and
decrypted the 200 files.

When you encrypted the files, the default RA certificate was used. The
default install will designate the first administrator account in XP as
the DRA in a non-domain environment.

In this case here, I created the RA after the files were already encrypted,
so why am I ABLE to decrypt the 200 files?

You need to check the certificate profile of the DRA user account. Run
certmgr.msc and look to see how many EFS recovery agent certificates you
have. Also, against the files, you can run EFSINFO /U /R /C which will
show you for the files what the thumbprint of the certificates that were
used during the encryption process.

Anyway, to resolve the problem, you asked me to do an experiment and told me
to "export" & "delete" the user's private key, before creating the RA. I did
this, and now the RA cannot delete the 200 files (which is the way it suppose
to work)

The goal is to not leave the RA's certificate in the user's profile. It
is kind of a break glass in case of emergency (translated = import the
certificate and private key only when needed).

My question is, why did you suggest to "export" & "delete" the user's
private key, then create the RA? And also why does this work and what did I
do wrong?

You will be able to delete and work with the files when you import the
cert and private key back into the profile. In fact, it can be imported
into any profile, as the user name has absolutely nothing to do with the
decryption process, only access to the private key of the DRA or the
user.

 

[Steven L Umbach]

I just reproduced what you did and was not able to access the files as the
RA though I rebooted the computer after encrypting the files and before
logging on as the built in administrator account to create the RA. ---
Steve

 

[Steven L Umbach]

Hi Brian.

I may be wrong but the behavior you describe for the default RA being
generated as the built in administrator account is unique to Windows 2000
and is not default behavior on an XP Pro computer. I have never seen an RA
on an XP Pro non domain workstation where a user has encrypted files unless
an administrator had taken the effort to create one and import it into Local
Security policy like the OP has done. --- Steve

 

[Guest]

now log back in as the user and go to the "details" button and view who is a
RA for that file and you will see that "Administrator is the RA.

After you verify that the Administrator is the RA, log back out of the user
account and log back in as the "Administrator" and you will be able to
decrypt it.

 

[Guest]

your right, Brian is mistaken.

Hi Brian.

I may be wrong but the behavior you describe for the default RA being
generated as the built in administrator account is unique to Windows 2000
and is not default behavior on an XP Pro computer. I have never seen an RA
on an XP Pro non domain workstation where a user has encrypted files unless
an administrator had taken the effort to create one and import it into Local
Security policy like the OP has done. --- Steve

 

[Steven L Umbach]

Well maybe we did something different as I used efsinfo to see if the newly
created RA [not by the user with cipher /R] was shown before logging onto
the user account and it was not as I expected. You indicated that the RA
could access the user's EFS files before logging on as the user after
creating the RA with the administrator account. --- Steve

 

[Guest]

you didn't go far enough, after you log in as the built-in administrator and
create the RA, don't check to see if you can decrypt a file, because your
right, you won't be able to decrypt one.

Now, log back in as the user and go to the "details" button and view who is
the RA for one of the encrypted files, you will see that "Administrator" is
the RA.
Now log back out as the user, login as as the "Administrator" and you WILL
be able to decrypt it any file you want.

Now how can that be? You explain it to me. I don't get it.

A previously encrypted file should not be able to be decrypted with a RA I
created after the fact.

-----------------------------------------------------------

 

[Guest]

If you could, write out "step by step", "word for word" and i'll try to
create the result your receiving.

i'm just trying to get an RA to not be able to open an older encrypted file
(meaning an encrypted file that was encrypted before the RA was setup.
Because all i'm getting over here is an RA that seeing everything (every
pre-RA encrypted file on my drive)

Thanks, Dave

----------------------------------------------------------

Well maybe we did something different as I used efsinfo to see if the newly
created RA [not by the user with cipher /R] was shown before logging onto
the user account and it was not as I expected. You indicated that the RA
could access the user's EFS files before logging on as the user after
creating the RA with the administrator account. --- Steve

now log back in as the user and go to the "details" button and view who is
a
RA for that file and you will see that "Administrator is the RA.

After you verify that the Administrator is the RA, log back out of the
user
account and log back in as the "Administrator" and you will be able to
decrypt it.

 

[Steven L Umbach]

Because one you logged on as the user and the RA was configured via Group
Policy then the user's EFS files can be updated automagically to reflect the
RA though that does not always reliably happen which is why it is a good
idea to use cipher /u to try to force it on all EFS for the user. This all
requires that the user has their EFS private key on the computer or the
update of the RA will fail which is why you can not create a RA after the
fact to attempt to decrypt EFS files for a user that does not have their EFS
private key due to export/delete, reinstall or corrupt user profile. ---
Steve

 

[Guest]

what?

you have a phone I can call you at, work or home, today, tomorrow, etc?

i don't think your picking up what i'm putting down. i don't know if you
tried the exact way i'm doing it, but i'm having an RA decrypting files that
are older than the RA.

 

[Guest]

The "Details button to see the RA is just that, another way to see that your
local policy is working. The problem i want to resolve is the RA decrypting
files that that are older than it.

 

[Steven L Umbach]

Nothing personal but I keep discussions only in newsgroups so everyone can
participate and benefit.

 

[Steven L Umbach]

I also meant to add that it is entirely possible for a RA to be able to
recover EFS files for a user that are older than the RA once those EFS files
have been updated with the new RA by action of the user by logging on while
their EFS private key is in their user profile which may happen
automatically or via cipher /U and the computer's security policy specifies
that the new RA is a recovery agent. Also just because a user can access an
EFS file and read it's name does not mean that they can decrypt it. The real
test is that can they open and read or execute the file. --- Steve

 

[Steven L Umbach]

As I mentioned previously it is possible for an RA to decrypt files older
than it. But my experience is that if I create a new RA and specify it in
security policy via an account that is not the user that encrypted the files
I can not use it to decrypt the user's EFS files and it does not show as a
RA in the EFS files properties until I logon as that user with the EFS
private key in the user profile. The RA is an all or nothing deal as you can
not specify which EFS files you want it to be RA for. Not that is should
matter but I am using XP SP2, the user and RA both have unique passwords,
and am using classic logon requiring control - alt -delete that does not
allow fast user switching. However you can not create a RA after the fact
to decrypt a user's past EFS files when the user's EFS private key is not
available if that is your concern as the user's EFS private key is needed to
allow the EFS files to be updated with the new RA. --- Steve

 

[Guest]

Ok, i'm understanding what your saying, but...

This is why I think you really never have to create a DRA before you start
encrypting files. You can create that DRA way after the fact (after you've
encrypted 10,000 files) and that same DRA will decrypt everyone of them with
no problems.

Because if you follow what i'm saying in a "test lab" and you encrypt files
under a user account, then create a DRA, logoff the Administrator once the
DRA is implemented, Logon as the user that encypted the files, then logoff as
the user, log back on as Administrator, you can decrypt every pre-DRA
encrypted file that was encrypted by the user.

Remember something...before the first logoff as Administrator (after the DRA
is implemented), you cannot decrypt anything, but once you logon for the
second time as Administrator, you can copy or open any pre-DRA encrypted file
that you want.

Thanks, Dave

-------------------------------------------------------------