EFS Recover Agents Unable to decrypt files

  • Thread starter Thread starter Fuente
  • Start date Start date
F

Fuente

Background:
Internal Certificate Service running in a 3 tier hierarchy. Enterprise CA,
Subordinate CA, Exchange CA
Default Domain administrator and additional domain administrator have
requested and received EFS Recovery certificates and have been setup on the
default domain policy of Security Settings | Public Key Policies | Encrypted
Data Recovery Agents

Created a test file on a workstation by a test account with Domain User
rights. Encrypted the file successfully. In order to test the ability of the
Recovery Agents I performed the process described in "Encrypting File System
for Windows 2000" white paper but this does not work. From the Windows
Explorer I get message stating ""Access is Denied" Error Message When
Encrypting or Decrypting Files or Folders". I also tried going to the users
home directory with one of the accounts and attempted to decrypt the file
and this didn't work either.

TechNet Article 264064 seemed to address the issue but after applying the
solution, the problem was not resolved. (As a matter of fact, all the
"System Volume" Folders I inspected on my domain controllers has the System
account listed but none of the permission were checked except in one place
where full was checked on the boot partition of on domain controller.)

When I use the Efsinfo.exe utility the following results are displayed on
the file in question:( I have changed the domain name and accounts from to
generic names for privacy. The "Bob.Train" account is a test account.

NOC List.txt: Encrypted
Users who can decrypt:
My DOMAIN\Bob.Train (CN=Bob Train)
Recovery Agents:
Unknown (CN=Domain Administrator)
Unknown (CN=Default Domain Administrator)

I am concerned about the "Unknown" entries and am wondering if this is the
root of the problem. It doesn't appear that the Recovery Accounts are
getting the permission necessary to perform the function.

I want to make sure that I have the ability to recover encrypted files
before implementing this across the board. I have search many articles in
this forum on the subject as well as Microsoft and have yet to find a
solution. I would like any insight anyone would have in solving this.
 
Here are a few possibilities:
- You don't have the right file permissions. You probably already checked
this yourself, but it's still worth mentioning.
- The RA's certificate and private key aren't on the machine where you're
trying to decrypt.
- The files were encrypted on XP or 2003 and you're trying to decrypt them
on Win2k, which doesn't understand the newer crypto algorithms.

"Unknown" is displayed because of a bug in the old version of efsinfo - it's
trying to display information that isn't there. It's nothing to worry
about.
 
Thanks for responding.

Have checked permissions as you stated many times. The account I am using
for decrypting the file is the original domain administrator account. The
only thing different is the account name has been changed. He has an EFS RA
certificate from our internal Subordinate CA. I even got another EFS RA just
to make sure.

I don't understand what you are saying about the private key. Whose private
key? The domain admin. Isn't this what the EFS RA is for? Whenever a file is
encrypted, a special recovery key is created with the encryption process. Is
this the key you speak of? If so, where is it kept? How do you retrieve it
by an EFS RA?

Maybe my assumptions are wrong in my testing process. Here is what I am
doing. First, I took a file by a user (which also happens to be a domain
admin and EFS RA) and encrypted a file. From there I simply copied the file
to a folder called EFS Recovery on a server where the domain admin has an
EFS RA certificate. At this point I check the properties of the file and
under encryption, deselect the option and click apply. This is where the
error message appears that I first posted.

Shouldn't this work? Is there a different process to go about this. I have
applied the white papers methods of backing up the file and then restoring
it to the same directory and the same result happens?

P.S. This is not a file encrypted on XP or 2003.


Drew Cooper said:
Here are a few possibilities:
- You don't have the right file permissions. You probably already checked
this yourself, but it's still worth mentioning.
- The RA's certificate and private key aren't on the machine where you're
trying to decrypt.
- The files were encrypted on XP or 2003 and you're trying to decrypt them
on Win2k, which doesn't understand the newer crypto algorithms.

"Unknown" is displayed because of a bug in the old version of efsinfo - it's
trying to display information that isn't there. It's nothing to worry
about.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


Fuente said:
Background:
Internal Certificate Service running in a 3 tier hierarchy. Enterprise CA,
Subordinate CA, Exchange CA
Default Domain administrator and additional domain administrator have
requested and received EFS Recovery certificates and have been setup on the
default domain policy of Security Settings | Public Key Policies | Encrypted
Data Recovery Agents

Created a test file on a workstation by a test account with Domain User
rights. Encrypted the file successfully. In order to test the ability of the
Recovery Agents I performed the process described in "Encrypting File System
for Windows 2000" white paper but this does not work. From the Windows
Explorer I get message stating ""Access is Denied" Error Message When
Encrypting or Decrypting Files or Folders". I also tried going to the users
home directory with one of the accounts and attempted to decrypt the file
and this didn't work either.

TechNet Article 264064 seemed to address the issue but after applying the
solution, the problem was not resolved. (As a matter of fact, all the
"System Volume" Folders I inspected on my domain controllers has the System
account listed but none of the permission were checked except in one place
where full was checked on the boot partition of on domain controller.)

When I use the Efsinfo.exe utility the following results are displayed on
the file in question:( I have changed the domain name and accounts from to
generic names for privacy. The "Bob.Train" account is a test account.

NOC List.txt: Encrypted
Users who can decrypt:
My DOMAIN\Bob.Train (CN=Bob Train)
Recovery Agents:
Unknown (CN=Domain Administrator)
Unknown (CN=Default Domain Administrator)

I am concerned about the "Unknown" entries and am wondering if this is the
root of the problem. It doesn't appear that the Recovery Accounts are
getting the permission necessary to perform the function.

I want to make sure that I have the ability to recover encrypted files
before implementing this across the board. I have search many articles in
this forum on the subject as well as Microsoft and have yet to find a
solution. I would like any insight anyone would have in solving this.
 
I don't know if this is the way it is suppose to work but I finally got a
file decrypted by an EFS RA. This is the method I used to do it but I would
like confirmation from someone else on this.

1. The file to be decrypted was moved to the temp folder on the SAME system
the file was created on.

2. Permissions were checked to make sure that the EFS RA had full permission
to the file.

3. The EFS RA logged onto the system where the file was originally created
as stated in step 1.

4. The EFS RA imported it's EFS RA certificate from storage in a secure
location on a home drive

5. The EFS RA imported the users key from a secure location of the user's
home drive.

Only after both of the above certificates were imported was I successful at
decrypting the file. I tried to decrypt the file after only importing the
EFS RA certificate but this failed.

I attempted to do the same thing by copying the same file to a directory on
a server called Encryption Recovery. However, even after importing both
certificates in steps 4 and 5, I was unsuccessful.

This leads me to some serious concerns about what an EFS RA can do.

1. Why isn't the EFS RA's certificate sufficient for decryption?

2. Why couldn't the file be decrypted off of the file server even when both
certificates were imported by the EFS RA?

3. In all of the documentation I have read, nothing was ever
mentioned about exporting the users EFS key so that it could be used for
decryption. Why? This appears to be an integral part at recovery

Fuente said:
Thanks for responding.

Have checked permissions as you stated many times. The account I am using
for decrypting the file is the original domain administrator account. The
only thing different is the account name has been changed. He has an EFS RA
certificate from our internal Subordinate CA. I even got another EFS RA just
to make sure.

I don't understand what you are saying about the private key. Whose private
key? The domain admin. Isn't this what the EFS RA is for? Whenever a file is
encrypted, a special recovery key is created with the encryption process. Is
this the key you speak of? If so, where is it kept? How do you retrieve it
by an EFS RA?

Maybe my assumptions are wrong in my testing process. Here is what I am
doing. First, I took a file by a user (which also happens to be a domain
admin and EFS RA) and encrypted a file. From there I simply copied the file
to a folder called EFS Recovery on a server where the domain admin has an
EFS RA certificate. At this point I check the properties of the file and
under encryption, deselect the option and click apply. This is where the
error message appears that I first posted.

Shouldn't this work? Is there a different process to go about this. I have
applied the white papers methods of backing up the file and then restoring
it to the same directory and the same result happens?

P.S. This is not a file encrypted on XP or 2003.


Drew Cooper said:
Here are a few possibilities:
- You don't have the right file permissions. You probably already checked
this yourself, but it's still worth mentioning.
- The RA's certificate and private key aren't on the machine where you're
trying to decrypt.
- The files were encrypted on XP or 2003 and you're trying to decrypt them
on Win2k, which doesn't understand the newer crypto algorithms.

"Unknown" is displayed because of a bug in the old version of efsinfo - it's
trying to display information that isn't there. It's nothing to worry
about.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


Fuente said:
Background:
Internal Certificate Service running in a 3 tier hierarchy. Enterprise CA,
Subordinate CA, Exchange CA
Default Domain administrator and additional domain administrator have
requested and received EFS Recovery certificates and have been setup
on
the
default domain policy of Security Settings | Public Key Policies | Encrypted
Data Recovery Agents

Created a test file on a workstation by a test account with Domain User
rights. Encrypted the file successfully. In order to test the ability
of
the
Recovery Agents I performed the process described in "Encrypting File System
for Windows 2000" white paper but this does not work. From the Windows
Explorer I get message stating ""Access is Denied" Error Message When
Encrypting or Decrypting Files or Folders". I also tried going to the users
home directory with one of the accounts and attempted to decrypt the file
and this didn't work either.

TechNet Article 264064 seemed to address the issue but after applying the
solution, the problem was not resolved. (As a matter of fact, all the
"System Volume" Folders I inspected on my domain controllers has the System
account listed but none of the permission were checked except in one place
where full was checked on the boot partition of on domain controller.)

When I use the Efsinfo.exe utility the following results are displayed on
the file in question:( I have changed the domain name and accounts
from
 
Sorry for late reply - was out of office.

Wherever the DRA's cert was created, export the cert. In the pfx export
wizard, select "export private key". Then wherever you import the .pfx, you
should be able to decrypt the files as the DRA.
You do not need the user's private key in addition to the DRA's.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


Fuente said:
I don't know if this is the way it is suppose to work but I finally got a
file decrypted by an EFS RA. This is the method I used to do it but I
would
like confirmation from someone else on this.

1. The file to be decrypted was moved to the temp folder on the SAME
system
the file was created on.

2. Permissions were checked to make sure that the EFS RA had full
permission
to the file.

3. The EFS RA logged onto the system where the file was originally created
as stated in step 1.

4. The EFS RA imported it's EFS RA certificate from storage in a secure
location on a home drive

5. The EFS RA imported the users key from a secure location of the user's
home drive.

Only after both of the above certificates were imported was I successful
at
decrypting the file. I tried to decrypt the file after only importing the
EFS RA certificate but this failed.

I attempted to do the same thing by copying the same file to a directory
on
a server called Encryption Recovery. However, even after importing both
certificates in steps 4 and 5, I was unsuccessful.

This leads me to some serious concerns about what an EFS RA can do.

1. Why isn't the EFS RA's certificate sufficient for decryption?

2. Why couldn't the file be decrypted off of the file server even when
both
certificates were imported by the EFS RA?

3. In all of the documentation I have read, nothing was ever
mentioned about exporting the users EFS key so that it could be used for
decryption. Why? This appears to be an integral part at recovery

Fuente said:
Thanks for responding.

Have checked permissions as you stated many times. The account I am using
for decrypting the file is the original domain administrator account. The
only thing different is the account name has been changed. He has an EFS RA
certificate from our internal Subordinate CA. I even got another EFS RA just
to make sure.

I don't understand what you are saying about the private key. Whose private
key? The domain admin. Isn't this what the EFS RA is for? Whenever a file is
encrypted, a special recovery key is created with the encryption process. Is
this the key you speak of? If so, where is it kept? How do you retrieve
it
by an EFS RA?

Maybe my assumptions are wrong in my testing process. Here is what I am
doing. First, I took a file by a user (which also happens to be a domain
admin and EFS RA) and encrypted a file. From there I simply copied the file
to a folder called EFS Recovery on a server where the domain admin has an
EFS RA certificate. At this point I check the properties of the file and
under encryption, deselect the option and click apply. This is where the
error message appears that I first posted.

Shouldn't this work? Is there a different process to go about this. I
have
applied the white papers methods of backing up the file and then
restoring
it to the same directory and the same result happens?

P.S. This is not a file encrypted on XP or 2003.


Drew Cooper said:
Here are a few possibilities:
- You don't have the right file permissions. You probably already checked
this yourself, but it's still worth mentioning.
- The RA's certificate and private key aren't on the machine where you're
trying to decrypt.
- The files were encrypted on XP or 2003 and you're trying to decrypt them
on Win2k, which doesn't understand the newer crypto algorithms.

"Unknown" is displayed because of a bug in the old version of efsinfo - it's
trying to display information that isn't there. It's nothing to worry
about.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


Background:
Internal Certificate Service running in a 3 tier hierarchy.
Enterprise CA,
Subordinate CA, Exchange CA
Default Domain administrator and additional domain administrator have
requested and received EFS Recovery certificates and have been setup on
the
default domain policy of Security Settings | Public Key Policies |
Encrypted
Data Recovery Agents

Created a test file on a workstation by a test account with Domain User
rights. Encrypted the file successfully. In order to test the ability of
the
Recovery Agents I performed the process described in "Encrypting File
System
for Windows 2000" white paper but this does not work. From the
Windows
Explorer I get message stating ""Access is Denied" Error Message When
Encrypting or Decrypting Files or Folders". I also tried going to the
users
home directory with one of the accounts and attempted to decrypt the file
and this didn't work either.

TechNet Article 264064 seemed to address the issue but after applying the
solution, the problem was not resolved. (As a matter of fact, all the
"System Volume" Folders I inspected on my domain controllers has the
System
account listed but none of the permission were checked except in one place
where full was checked on the boot partition of on domain
controller.)

When I use the Efsinfo.exe utility the following results are
displayed on
the file in question:( I have changed the domain name and accounts
from
to
generic names for privacy. The "Bob.Train" account is a test account.

NOC List.txt: Encrypted
Users who can decrypt:
My DOMAIN\Bob.Train (CN=Bob Train)
Recovery Agents:
Unknown (CN=Domain Administrator)
Unknown (CN=Default Domain Administrator)

I am concerned about the "Unknown" entries and am wondering if this
is the
root of the problem. It doesn't appear that the Recovery Accounts are
getting the permission necessary to perform the function.

I want to make sure that I have the ability to recover encrypted
files
before implementing this across the board. I have search many
articles in
this forum on the subject as well as Microsoft and have yet to find a
solution. I would like any insight anyone would have in solving this.
 
At least someone is trying to address this issue. I did as you stated but it
still doesn't work. Here is what I am doing.

On a laptop in the domain I have created a test file and encrypted it by a
user. Next I copy the file to the temp directory on the same laptop. I log
off of the laptop and log on as one of 2 designated DRA's. I then import the
certificate as you say and I still fail to decrypt the test file in the temp
directory.

I find no rhyme or reason for this behavior and do not have any confidence
in this aspect until this is resolved.

Oh, one more thing. I do have a GPO setup identifying the DRA's to the
entire domain. Any other ideas?

Drew Cooper said:
Sorry for late reply - was out of office.

Wherever the DRA's cert was created, export the cert. In the pfx export
wizard, select "export private key". Then wherever you import the .pfx, you
should be able to decrypt the files as the DRA.
You do not need the user's private key in addition to the DRA's.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


Fuente said:
I don't know if this is the way it is suppose to work but I finally got a
file decrypted by an EFS RA. This is the method I used to do it but I
would
like confirmation from someone else on this.

1. The file to be decrypted was moved to the temp folder on the SAME
system
the file was created on.

2. Permissions were checked to make sure that the EFS RA had full
permission
to the file.

3. The EFS RA logged onto the system where the file was originally created
as stated in step 1.

4. The EFS RA imported it's EFS RA certificate from storage in a secure
location on a home drive

5. The EFS RA imported the users key from a secure location of the user's
home drive.

Only after both of the above certificates were imported was I successful
at
decrypting the file. I tried to decrypt the file after only importing the
EFS RA certificate but this failed.

I attempted to do the same thing by copying the same file to a directory
on
a server called Encryption Recovery. However, even after importing both
certificates in steps 4 and 5, I was unsuccessful.

This leads me to some serious concerns about what an EFS RA can do.

1. Why isn't the EFS RA's certificate sufficient for decryption?

2. Why couldn't the file be decrypted off of the file server even when
both
certificates were imported by the EFS RA?

3. In all of the documentation I have read, nothing was ever
mentioned about exporting the users EFS key so that it could be used for
decryption. Why? This appears to be an integral part at recovery

Fuente said:
Thanks for responding.

Have checked permissions as you stated many times. The account I am using
for decrypting the file is the original domain administrator account. The
only thing different is the account name has been changed. He has an
EFS
RA
certificate from our internal Subordinate CA. I even got another EFS RA just
to make sure.

I don't understand what you are saying about the private key. Whose private
key? The domain admin. Isn't this what the EFS RA is for? Whenever a
file
is
encrypted, a special recovery key is created with the encryption
process.
Is
this the key you speak of? If so, where is it kept? How do you retrieve
it
by an EFS RA?

Maybe my assumptions are wrong in my testing process. Here is what I am
doing. First, I took a file by a user (which also happens to be a domain
admin and EFS RA) and encrypted a file. From there I simply copied the file
to a folder called EFS Recovery on a server where the domain admin has an
EFS RA certificate. At this point I check the properties of the file and
under encryption, deselect the option and click apply. This is where the
error message appears that I first posted.

Shouldn't this work? Is there a different process to go about this. I
have
applied the white papers methods of backing up the file and then
restoring
it to the same directory and the same result happens?

P.S. This is not a file encrypted on XP or 2003.


Here are a few possibilities:
- You don't have the right file permissions. You probably already checked
this yourself, but it's still worth mentioning.
- The RA's certificate and private key aren't on the machine where you're
trying to decrypt.
- The files were encrypted on XP or 2003 and you're trying to decrypt them
on Win2k, which doesn't understand the newer crypto algorithms.

"Unknown" is displayed because of a bug in the old version of efsinfo -
it's
trying to display information that isn't there. It's nothing to worry
about.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no
rights.


Background:
Internal Certificate Service running in a 3 tier hierarchy.
Enterprise
CA,
Subordinate CA, Exchange CA
Default Domain administrator and additional domain administrator have
requested and received EFS Recovery certificates and have been
setup
on
the
default domain policy of Security Settings | Public Key Policies |
Encrypted
Data Recovery Agents

Created a test file on a workstation by a test account with Domain User
rights. Encrypted the file successfully. In order to test the
ability
of
the
Recovery Agents I performed the process described in "Encrypting File
System
for Windows 2000" white paper but this does not work. From the
Windows
Explorer I get message stating ""Access is Denied" Error Message When
Encrypting or Decrypting Files or Folders". I also tried going to the
users
home directory with one of the accounts and attempted to decrypt the
file
and this didn't work either.

TechNet Article 264064 seemed to address the issue but after applying
the
solution, the problem was not resolved. (As a matter of fact, all the
"System Volume" Folders I inspected on my domain controllers has the
System
account listed but none of the permission were checked except in one
place
where full was checked on the boot partition of on domain
controller.)

When I use the Efsinfo.exe utility the following results are
displayed
on
the file in question:( I have changed the domain name and accounts from
to
generic names for privacy. The "Bob.Train" account is a test account.

NOC List.txt: Encrypted
Users who can decrypt:
My DOMAIN\Bob.Train (CN=Bob Train)
Recovery Agents:
Unknown (CN=Domain Administrator)
Unknown (CN=Default Domain Administrator)

I am concerned about the "Unknown" entries and am wondering if this
is
the
root of the problem. It doesn't appear that the Recovery Accounts are
getting the permission necessary to perform the function.

I want to make sure that I have the ability to recover encrypted
files
before implementing this across the board. I have search many
articles
in
this forum on the subject as well as Microsoft and have yet to find a
solution. I would like any insight anyone would have in solving this.
 
Back
Top