Re: EFS on crashed OS

From: Vanguard \(NPI\) (vanguard.code_at_comcastNIX.com)
Date: 09/29/05


Date: Thu, 29 Sep 2005 14:28:27 -0500


"E. James" <EJames@discussions.microsoft.com> wrote in message
news:870BCB0D-4933-4BAA-A601-42B58314CA86@microsoft.com...
>I have a somewhat similar question regarding encrypted files. Clinet had
> multiple partitions on the workstation withthe OS isolated on the primary
> partition. Data files were maintained on a separate partition and even a
> separate HDD. The first HDD crashed, which contained the OS. No recovery
> method was successful due to hardware damage. New hardware was installed
> an
> a fresh OS was installed, using the same user information in the same
> domain.
> The original files exist and even specify that the encryption key holder
> is
> DOMAIN/user account. However, when the client logs on (user account was
> NOT
> modified in the domain during the downtime) the user can not access the
> encrypted files.
>
> What is the methodology to retreive these files since it is the same user
> account in the domain? Keep in mind that since it was a hardware crash,
> there was no possibility to export the keys after the crash.
>
> TIA,
>

Under the new instance of Windows, import the EFS certificate that should've
been exported when it was created under the old instance of Windows.
Without that private key, your customer won't be getting into their files.

Accounts are identified by a security identifier (SID) which is unique when
you create an account - except for some global Windows accounts, like
Administrator. After importing the EFS certificate, your customer may still
not be able to access the old files. They got a new SID in the new instance
of Windows. If you look at the permissions for the encrypted files, you'll
probably see a SID listed which looks like "S-<alphnumericstring>". That
SID isn't defined in the new instance of Windows. That is the user's old
SID from the old instance of Windows. Delete that old and now unknown SID
and add the user's account to give them permissions to those files. You can
use the Administrator account to take ownership and then give ownership
and/or permissions to the user (because the same SID for Administrator is
used for every Windows instance, so the old SID for Administrator from the
old instance of Windows is the same SID for Administrator in the new
instance of Windows). If the user had removed Administrator or reduced its
privileges, or removed the Administrators group from having privileges,
you're screwed because the user deliberately chose to take administrators
out of the loop.

-- 
__________________________________________________
E-mail: Remove "NIX" and add "#LAH" to Subject.
__________________________________________________ 


Relevant Pages