I have a user whose profile became corrupted and lost EFS keys on recreation of profile. I have a valid EFS Recovery policy in the domain. I have logged on as an administrator, imported the recovery key PFX (public AND private keys both and double checked). I checked the file for recovery agents and matched the thumbprint to my key in the certificate store. They match. So my admin account has the private key imported (which seems to be the most common mistake). Yet, I still cannot decrypt the files. I get access is denied every time. I also checked NTFS permissions and those are correct. The recovery key is valid and is not revoked. The certification path is all green checkmarks. Everything seems to be in place for a recovery of the data. But it's not working. What am I missing?

Hi, Thanks for posting at Microsoft TechNet forums. Based on my understanding, if only the profile is corrupted, the encrypted file should not be affected. Please check the file again. Also, If you already setup the EFS recovery agent policy, please copy the encrypted file to the computer which your file recovery certificate and recovery key are located. Then Right-Click the file=> Advanced=> decrypt the file. The detailed information, you may refer to the following link. http://blogs.technet.com/b/asiasupp/archive/2007/04/26/efs-file-recovery.aspx Regards, Juke TechNet Subscriber support in form. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thank you for the quick reply. Unfortunatley, the steps outlined do not work for me. I have imported the EFS recovery certificate (with private key) into several different user accounts, but the result is always "access is denied." As indicated in the top post, I have verified that this is the correct recovery certificate because the thumbprint matches exactly in the properties of the encrypted file and in the certificate store. I tried copying the files to another drive so I could take it to another computer and try to decrypt there, but it didn't work either (presumably for the same reason as above). Any other ideas? EFS recovery agent thumbprint on the files: ACFBCC88A20FBA8FC69C147D4C0B7666AB639396 Thumbprint on the file recovery certificate: acfbcc88a20fba8fc69c147d4c0b7666ab639396 I checked again on the certificate in my certificate store and it says: "You have a private key that corresponds to this certificate." I'm utterly confused.

Hi, I would like to share the following document with you first. Data recovery requires preparation. Fortunately, EFS in Windows comes by default with just such preparation built in, by requiring a data recovery agent for each encrypted file. Every time you encrypt a file, Windows allows either of two keys to be used to decrypt the file again later. One of the keys belongs to the user who encrypts the file, so that the user can access the file again later. The other key belongs to the data recovery agent, and as with the user’s key, the data recovery agent’s key and certificate can be created by administrators’ actions, or will be created on first use. By default, the data recovery agent is defined to be the administrator account. On stand-alone workstations and workgroup machines, the administrator account is the local administrator; on domain-joined machines, the administrator account is the first domain controller’s administrator account. So please use the administrator account which create the recovery agent to decrypt the file. You may check which user the recovery certificate is issued to. Then log in with that user to try to access the encrypted file. The following link for your reference. http://technet.microsoft.com/en-us/library/cc512680.aspx Regards, Juke TechNet Subscriber support in form. If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

I did already try importing the certificate into the same domain account that originally created the certificate. That did not help. Same error, no matter which account holds the recovery agent private key.

Hi, If you use the originally certificate created user to decrypt the file, and the certificate thumbprinter also match, it should decrypt the file. You must use the user which the certificate "issued to" to decrypt. Please open the recovery agent certificate's properties to check who the "issued to" user is. If you still can not access the file, please export the EFS file information and post it back. Meantime, you may use the certutil to verify the certificate's status. The following links for your reference. Using Efsinfo.exe to determine information about encrypted files http://support.microsoft.com/kb/243026 Basic CRL checking with certutil http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx Certutil tasks for managing certificates http://technet.microsoft.com/en-us/library/cc772898(WS.10).aspx#BKMK_val_cert_spec Verify the certificate chain for the certificate http://technet.microsoft.com/en-us/library/bb430766.aspx Using Encrypting File System http://technet.microsoft.com/en-us/library/bb457116.aspx#EBAA In addition, Please check the security setting of the encrypted file. Regards, Juke TechNet Subscriber support in form. If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

The "issued to" is the same user as the one I am trying to decrypt with. Due to corporate disclosure policies, I can't tell you the username and I will be unable to post some supporting evidence to this open forum. The recovery agent is the built-in default administrator account on the domain. It is renamed from default (ie, it's not Administrator) but the username in the Issued To matches the current username of the account and was assigned to that user after the username renaming occurred. In other words, if the administrator user was "Domain\Admin" then the Issued To says "Domain\Admin" and they are the same identical account too. Not just the same username, but the same SID. And, yes, I agree it should be working. Clearly the issue on this PC is deeper than a simple recovery certificate error. Something isn't working right in EFS. Obfuscated EFSINFO information: EFSINFO.EXE <filename> RoboFormDataHere.txt: Encrypted Users who can decrypt: DOMAIN\user (FirstName LastName(email@domain.com)) EFSINFO.EXE /R <filename> RoboFormDataHere.txt: Encrypted Recovery Agents: Unknown (System Administrator(adminuser@domain.com)) Unknown (System Administrator(adminuser@domain.com)) You'll notice that there are two recovery agents. Both are the same user, but one of the certificates in question is an expired certificate. Not sure if this matters. I don't see why because the other one is valid. CERTUTIL -f -urlfetch -verify <cert> Verified Issuance Policies: None Verified Application Policies: 1.3.6.1.4.1.311.10.3.4.1 File Recovery Leaf certificate revocation check passed CertUtil: -verify command completed successfully.

Run the following command: certutil -v -user -store My <THUMBPRINT> Where <THUMBPRINT> is the thumbprint of the DRA certificate. When certutil reaches the private key signing test, it may prompt you either with a dialog box or with a password prompt.If either of these occur, then the customer has enabled Strong Private Key Protection on the private key.EFS cannot use any keys where Strong Private Key Protection has been enabled because it cannot display the dialog boxes to the user. To resolve, this problem, re-import the certificate and private key from the PFX file but do not select the option for Strong Private Key Protection.Ketan Thakkar | Microsoft Online Community Support

Hi, Any update?Ketan Thakkar | Microsoft Online Community Support

Hi. Sorry for the delay in response. I got busy with some other projects and this fell off my radar for a bit. CertUtil did not prompt me for a password. It says "encryption test passed." I tried deleting all the certificates from the recovery agent's certificate store. I then re-imported the recovery certificate, made ABSOLUTELY sure that "Strong Private Key Protection" was NOT checked and I have the same failure results. Just for the sake of completeness, I also imported the entire certificate chain into "Personal" and every other recovery agent certificate the company has ever had (they are all stored in the same folder). No luck. Same failure.

Based on what has transpired we suspect the following has occurred - The first domain controller in a domain contains the built-in Administrator profile that contains the public certificate and the private key for the default recovery agent of the domain. The public certificate is imported to the Default Domain Policy and is applied to domain clients by using Group Policy. "If the Administrator profile or if the first domain controller is no longer available, the private key that is used to decrypt the encrypted files is lost, and files cannot be recovered through that recovery agent. " 241201 How to back up the recovery agent Encrypting File System (EFS) private key in Windows Server 2003, in Windows 2000, and in Windows XP http://support.microsoft.com/default.aspx?scid=kb;EN-US;241201 Review the aforementioned article. Use the CIPHER.exe tool to decrypt all the encrypted files on the affected PC. cipher /a /d /s "path to encrypted data folder" http://support.microsoft.com/kb/298009 Re- encrypt using a new EFS certificate. If further troubleshooting is required, we suggest opening a paid support case with Microsoft support.Ketan Thakkar | Microsoft Online Community Support

No, that is not the problem. As previously stated in the very first post, I have a recovery policy in the domain for which a recovery agent is defined. This recovery agent's key is a part of that policy. The recovery agent's public and private keys were backed up. I have verified that the recovery certificate defined on the target files matches the recovery key I have backed up and restored (both public and private) and used to attempt recovery.

It looks like you truly have NO permissions to the encrypted files. The only thing left to try is to take ownership of all the encrypted files. After you have taken ownership, then try to decrypt using the recovery agent. Or Use Cipher.exe to decrypt.Ketan Thakkar | Microsoft Online Community Support

As stated in the top post, it is not an NTFS permission problem. The administrator has permissions on the files (Administrators have Full Control). For completeness, I did try taking ownership. That did not help. I'm currently working with professional support to resolve this issue. The current line of thinking is that there is something wrong with the workstation. I was told to run a backup and restore the encrypted files to another workstation to attempt to decrypt the files there. I will add a comment to this post after I try that on Monday.