EFS and private-key recovery

Identify what is missing

EFS encrypts file content with a symmetric file encryption key (FEK). It protects that FEK using the public keys of the authorized user and any applicable recovery agents. Decryption needs a corresponding private key. Owning the NTFS file, being a Domain Admin, or possessing the public .cer file does not by itself supply that private key. Microsoft’s EFS recovery explanation describes the user Data Decryption Field and recovery-agent Data Recovery Field.

Keep the encrypted file, its EFS metadata, available profiles and key material intact while you work out what’s missing. It might be NTFS access, the user’s key, access to that key, or a recovery path. A password reset, deleted profile or broad certificate replacement can make the original problem harder to untangle.

Inspect one file before changing a whole machine

On the machine holding the file, these are inspection commands:

cipher /c "C:\Cases\sample.txt"
cipher /y

The first shows that file’s encryption and recovery certificates. The second shows the current user’s EFS certificate, which might not be the one protecting an older file. Compare thumbprints, not friendly names. The cipher reference distinguishes inspection from key creation, rekeying and decryption.

A local encrypted-file inventory can use:

cipher /u /n

Keep /n: without it, the /u operation can update file key/recovery information. Even an inventory can be lengthy and incomplete where the caller cannot enumerate files. Retain errors and identify the machine, volumes and user context. It is not a forest-wide EFS inventory or proof that no encrypted files exist on an offline device.

For the affected user’s current store:

Get-ChildItem Cert:\CurrentUser\My |
    Where-Object {
        $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.4.1.311.10.3.4'
    } |
    Select-Object Subject,Thumbprint,NotBefore,NotAfter,HasPrivateKey

Run in the intended profile. HasPrivateKey records an association, not a successful decrypt operation. Another user, a service profile, smart card or unavailable provider can change the result. See certificate-store and key-context checks.

A DRA recovers data without recovering the user’s private key

An EFS Data Recovery Agent (DRA) uses its own private key to unwrap the file’s FEK through a recorded recovery entry. It does not need to retrieve and impersonate the user’s original private key. Publish the DRA’s public certificate in the intended EFS policy; protect the corresponding private key separately.

Check a representative old file and a new file to see which recovery certificates they actually contain. Having the policy configured isn’t enough. A replacement DRA certificate with a new private key won’t match old recovery entries. Keep earlier recovery keys for the data that depends on them, and test recovery before retiring a profile, device or custodian. Microsoft’s DRA verification example uses cipher /c to check the recorded recovery certificate; its WIP-specific deployment details apply to that deployment.

An expired or invalid DRA policy certificate can also prevent new encryption, even while the question being investigated concerns an old file. Diagnose issuance/policy health separately from possession of the private key required for existing data. See the invalid recovery-certificate failure.

A KRA recovers an archived private key

A Key Recovery Agent (KRA) participates in CA key archival and recovery. The client submits archival material during a suitable enrollment; the CA stores the protected user key in its database. A configured KRA certificate today does not prove that a key issued years earlier was archived.

Separate these prerequisites: the encryption template requires archival; the CA has appropriate KRA recipients; the request actually carried archival material; the CA retained the archived record; and someone can use a matching KRA private key. CMC can carry the protected private key; a standalone PKCS #10 request cannot provide the same archival operation. Certreq’s CMC and PrivateKeyArchive settings document that request distinction.

Read CA KRA configuration without exporting recovery blobs:

certutil -config "CA01\Contoso Issuing CA" -CAInfo kracount
certutil -config "CA01\Contoso Issuing CA" -CAInfo kraused

The counts tell you what’s configured; you still need a recovery test. Microsoft’s current key archival procedure separates certificate-manager retrieval of an encrypted blob from KRA decryption into a protected PKCS #12 file. Keep those duties separate. Multiple KRA recipients improve availability; they don’t automatically impose a multi-person cryptographic quorum.

Prove recovery against retained data

Use an approved test copy and identify its exact encrypting certificate. Try the selected DRA path or recover the matching user key, then decrypt the file in the approved context. Getting a certificate back into the store is only part of that test. Keep the original encrypted data and note what the recovery changed.

Recovered encryption keys can unlock other retained data protected by the same key, so limit where they are imported and remove temporary recovery files under the agreed handling process. Retain a new-key/re-encryption plan after suspected compromise. Recovering old encrypted data and approving further use of the old credential are separate decisions.

Include archived user keys, old KRA keys, DRA custody and recovery rehearsal in the CA recovery inventory. A CA restore can succeed while the organization still lacks the private key needed for its encrypted documents.