EFS in a domain expires after three years – Tales from the Crypto

EFS in a domain expires after three years

I enjoyed the research for writing my article on EFS, for the Technet Security Newsletter, but there’s always something experience will teach you.

Here’s an issue I experienced just last week, with EFS. It shouldn’t have been a surprise, given what I already know, and if I put the two facts together, you’ll probably spot it straight away:

  • EFS certificates are automatically issued, and expire after three years if you use the default EFS template.
  • When you create a domain, the administrator account on the first domain controller is automatically given an EFS certificate, so he can become the domain’s default DRA.

You’ve spotted it already (and the title helped you, right?) – after three years, the administrator’s EFS certificate expires.

His certificate may get renewed, so he can encrypt more documents, and of course his old private key still allows him to read files that were encrypted while the certificate was still valid.

That assumes, though, that the administrator’s account is an actively used one.

Whether it’s used or not, though, the fact remains that the DRA certificate does not get updated in the default Group Policy Object – and as a result, even if the administrator renews his EFS certificate, EFS will be effectively disabled throughout the domain.

Here’s the dialog you get:


For those of you using search engines, that dialog says “Error Applying Attributes”, “An error occurred applying attributes to the file:”, and “Recovery policy configured for this system contains invalid recovery certificate.”

Pretty much your only good choice here is “Cancel”, until you can generate a new certificate and add it to the default domain policy, being sure to remove the old expired cert.


[That old private key can be used to recover anything that was encrypted using EFS before the key expired. Always hold PFX files on keys that can be used to decrypt information – always, always, always.]

There’s no easy way to put the new certificate into the default domain policy, so you have to do it by hand. You might as well also generate the certificate by hand, and make sure that it’s not associated with a particular user account (why should it be? it’s just a key with a purpose, and that purpose is not associated with a user.)

How do you do this best?

A simple command line is easiest, in my opinion:

C:\>cipher /R:EFS_DRA_20070324
Please type in the password to protect your .PFX file:
Please type in the password to protect your .PFX file:

Your .CER file was created successfully.
Your .PFX file was created successfully.

That generates two files – EFS_DRA_20070324.PFX, and EFS_DRA_20070324.CER. As hinted at in the output, the PFX file is protected by a password (as they all should be) – move this immediately to a floppy disk and lock it in a cabinet, along with documentation of the password you used (or segregate the two, whatever your certificate handling policies dictate). Or maybe you expect to have frequent requests to recover EFS-encrypted files, so you want the Service Desk to own the PFX file.

Then, go through whatever change management nightmares you have to do in order to edit the default domain policy, delete the old expired certificate, and import the one you just created.

Now, encrypt away, knowing that your encrypted files can be recovered using the PFX file you just created.

12 Responses to EFS in a domain expires after three years

Leave a Reply

Your email address will not be published. Required fields are marked *