Solved Encryption suddenly denied

[mormegil27]

I'm using the file encryption (required by my work) on Win 7 Pro 64 bit.

I suddenly am being denied access to my files. It happened after my admin changed my password from within the admin account, which is not the same account associated with the encryption. My best thought is that the encryption key (password) was not changed when the admin changed the password from their side.

The certificates are all on the computer, I can access them, but it doesn't help. I have a backup of the encryption certificates, but it is not accepting what we definitely believe the password (key) to be. So something very odd is going on.

Note that when I log on to my account, the process lsass.exe uses 50% cpu usage for about 30 seconds, which does not usually happen at logon. So I assume that it is looking for some kind of encryption info, but not finding it.

Is there some way to find out what lsass.exe is doing, and thus try to troubleshoot what info it doesn't have?

I have already tried running "dpapimig.exe" in CMD, which is supposed to update the encryption to the current password, but this doesn't help.

 

[mormegil27]

Also, when I go into any of my files, it does say that I'm the owner. But clearly the encryption certificate is corrupt.

If I go into the certmgr, and then try to export the certificates that are there in, for example, "Trusted People", it tells me I can't export the private key because the private key can't be found. Why would this be? What could have corrupted the private keys? Where are they normally stored? Perhaps I can go there and look at that file location?

 

[mormegil27]

I found a website that suggested the location of the private key storage in Win 7:


C:\users\ [ACCNT NAME] \AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-… (many numbers)

There are keys in this folder that were created on the same day as my encryption certificates that supposedly have no key associated with them. Is there some way to re-associate the keys with the certificates?

 

[mormegil27]

I now suspect that the problem stems not from the change of the password, but rather some other permissions change that prevents the encryption certificates from being linked to the private keys in the MACHINEKEYS folder (ie \RSA\S-1-5-...). I attempted to troubleshoot using the following method:

How to correct 'The associated private key cannot be found' error message

but the \RSA\MACHINEKEYS folder already claims that SYSTEM and local administrators have full control over the folder (in addition to my user account). I can change the ownership, it was already set to "administrators". However, I can't change the Full Control settings in the Allow column, all check marks are grayed out - but they are all checked, which makes me think they are all active? Unclear.

I also tried repairing the certificate using the following command with its serial number:

certutil -repairstore my "SerialNumber"
How to assign a private key to a new certificate after you use the Certificates snap-in to delete the original certificate in Internet Information Services

but it failed. However, I do have a folder full of private keys, so there must be some way to repair this problem and force the certificates to locate such keys. I really need help from a Win 7 programming expert.

Any such person out there?

 

[Layback Bear]

The only thing I can think of is going to the Administrator that changed your password and ask for help.

Your post #1

I suddenly am being denied access to my files. It happened after my admin changed my password from within the admin account, which is not the same account associated with the encryption. My best thought is that the encryption key (password) was not changed when the admin changed the password from their side.

 

[mormegil27]

Ah, thanks, I agree that seems the obvious thing to do. I did do that when it first happened, the problem is that my administrator is not a Win 7 programming expert either, and they have no idea why I lost control of the encryption after the password change. So I am left to try to rescue my files on my own.

We did try changing the password back to various older passwords, but it didn't solve the problem. I'm trying hard to understand how the encryption system in Windows works - and again it seems at this point there is a problem with linking the private keys, which I have located, to the certificates, which I have also located.

 

[mormegil27]

For example, I can view the properties of the encrypted files, and they have a "thumb print" associated with them that links them to a particular certificate. I have 5 certificates for some reason that could be associated with the encryption, but only one of them matches the thumb print of the encrypted files. And I know the date on which that certificate was created. If I go into the private keys folder (ie MACHINEKEYS, which is apparently a number specific to your computer), I find that there is also exactly one private key file that was created on the same date as the matched certificate.

So I'm pretty sure I know exactly which certificate and private key go together - but I can't seem to get the Win7 file system to link them up.

 

[mormegil27]

I also note that lsass.exe uses significant resources whenever I attempt to access anything in my user account.

 

[cluberti]

lsass == Local Security Authority Subsystem Service, and as such is responsible for handling permissions, auth, etc. on the system. Not surprising it's consuming resources in a situation where there are permission lookups or account lookups being done.

If your password was changed by the administrator, and you're using Encrypting File System (EFS) to encrypt data (and given your post, I'd wager this is exactly what's happening), this problem you're seeing is *expected behavior* and the admin was warned of this when he reset your password and apparently ignored the very, very obvious warning before he clicked "yes" a second time. The only way you get that back is to have the admin use the recovery keys stored in Active Directory for EFS done under your user account (they did do that, didn't they???), or import/re-associate keys that were backed up under your account previously (you did do that, didn't you???). The last method would be to try to brute force the key with 3rd party software, but that can be expensive and you can end up with corrupt files on the other end if it fails.

In essence, if the encryption keys weren't backed up manually or recovery keys backed up to Active Directory during the encryption configured by the admin, those encrypted files are locked and gone for all intents and purposes.

 

[mormegil27]

cluberti - thanks for the post. I doubt that the admin knows what "active directory" is, otherwise they would have tried this, but I have definitely backed up windows and can restore to a previous state. I'm attempting to recover lost work since the last backup.

But I think you are suggesting that the keys can be restored from the previous backup, and only the keys (ie don't overwrite everything?). I'll see if we can do this.

I'll also research Active Directory - is this located with the back-up under windows backup?

Thanks again!

 

[mormegil27]

For anyone who comes upon this thread in need of help, Active Directory is explained here:

Protecting Data by Using EFS to Encrypt Hard Drives

One issue we have is that we did back up the certificate/keys to external media and wrote down the password, but the password does not work. So it was either typed wrong or written down wrong, or perhaps the certificate file is corrupt.

 

[mormegil27]

Hang on - I think you are suggesting that the keys must be backed up themselves, not just restored through backup. However, couldn't we restore the backup to a different computer, export the keys, and then import them to the original computer?

 

[cluberti]

You could try, for sure, but no guarantees it would work. You could definitely give the backup to another PC option a shot though.

 

[mormegil27]

Excellent! The restore of the backup to an alternate location did allow me to access and export my certificates / keys, and then importing them back into the laptop (not the restored backup) allowed me to access the files again!

So everything is up and running. Thanks again to everyone for all of the suggestions.