NTFS encryption problem

[Karl Levinson [x y] MVP]

"DevilsPGD" <spammelikeiwa...@crazyhat.net> wrote in message
news:r57nruka2oj0k3j0u...@4ax.com...
> First of all, I'm not sure if this is the most appropriate group, if
> not, somebody please redirect me to the appropriate place.
>
> I've run into a minor problem with NTFS encryption. Long story short, I
> had an IDE controller started acting up, I lost some data before I was
> able to troubleshoot. I ended up replacing the motherboard and hard
> drive. I have the old hard drive hooked up at the moment until I have
> migrated all my data over.
>
> I had a number of files with NTFS encryption enabled, which I appear to
> be unable to access at this point -- I had backups scheduled, but the
> recent copies are corrupt, so I'm trying to recover the actual data from
> the drive.
>
> The system is running W2K Server+SP3, connected to an active directory
> network. The machine was used as a workstation, but since I needed IIS
> and DNS services I ended up running Server rather then Pro. I am using
> the same (active directory based) user account as I used on the previous
> system, and have full administrative privileges.
>
> The file permissions are presently set to Everyone - Full control, but I
> am receiving access denied errors when attempting to access the files in
> question. I'm suspecting it's relating to encryption, but I'm not 100%
> sure where to go from here.

In AD, the domain Administrator account is the default EFS recovery agent.
Try logging in as domain admin and following the instructions for doing EFS
recovery. And back up your encryption keys ASAP, because without them, your
files are out of luck. Information on how to do both of these is available
by searching either this newsgroup for "EFS" or www.microsoft.com/support
for "EFS recovery"

[David Cross [MS]]

Keys are stored in your profile (which may or may not be roaming). Keys are
not automatically roamed in a domain scenario and only if you have a roaming
profile enabled. Despite what username is on the file, you still must have
the certificate and private key referenced on the file with efsinfo.exe to
decrypt the file.

--

David B. Cross [MS]

--
This posting is provided "AS IS" with no warranties, and confers no rights.

http://support.microsoft.com

"DevilsPGD" <spammelikeiwa...@crazyhat.net> wrote in message

news:vnqorus8jjhu4hqtm...@4ax.com...
> In message <<3DBC5EA0...@istar.ca>> "Michel Gallant (MVP)"
> <neu...@istar.ca> did ramble:
>
> >This *might* be an issue with EFS dormancy?
> >
> >"Maintaining Archives of Recovery Keys For EFS encrypted files, the
> >recovery agent information is refreshed every time the file system
performs
> >an operation on the file (for example, when the file is opened, moved, or
copied).
> >However, if an encrypted file is dormant for a long time, the recovery
agents
> >expire. To ensure that dormant encrypted files can be recovered ,
> >maintain archives of the recovery agent certificates and private keys.
> >To create an archive, export the certificate and its private key to a
secure medium
> >and store it in a safe location. "
> >
> >(from Win2000 ResKit:
> > http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?
> > url=/windows2000/techinfo/reskit/en-us/prork/prdd_sec_lukz.asp
>
> Some files in that directory go back to '96, and aside from being
> encrypted, probably haven't been touched since '99 or so when I picked
> up the hard drive in question. However, all of the truely important
> ones have been accessed and likely updated within the last 2-3 weeks
>
> That being said, the EFSINFO I posted was from a file which has not been
> touched in years.
>
> I did a EFSINFO /u /r on a more recently accessed file, and got the
> below response:
>
> events.bak: Encrypted
> Users who can decrypt:
> NTDOMAIN\devilspgd (OU=EFS File Encryption Certificate, L=EFS,
> CN=DevilsPGD)
>
> Recovery Agents:
> NTDOMAIN\devilspgd (OU=EFS File Encryption Certificate, L=EFS,
> CN=DevilsPGD)
>
> Doesn't that mean that I should be able to decrypt it, being that I'm
> logged in as NTDOMAIN\devilspgd -- I'm assuming that keys are stored at
> the domain level, rather then the individual PC, is that a bad
> assumption?
>
> --
> Whenever I feel blue, I start breathing again.

[DevilsPGD]

In message <<OWvdxoafCHA.2592@tkmsftngp09>> "Karl Levinson [x y] MVP"
<jamescag...@excite.com> did ramble:

>In AD, the domain Administrator account is the default EFS recovery agent.
>Try logging in as domain admin and following the instructions for doing EFS
>recovery. And back up your encryption keys ASAP, because without them, your
>files are out of luck. Information on how to do both of these is available
>by searching either this newsgroup for "EFS" or www.microsoft.com/support
>for "EFS recovery"

One more thing I tried, I was able to get into lockup this morning to
get my W2K resource kit, and I ran EFSINFO.EXE and got the following
output:

Users who can decrypt:
NTDOMAIN\devilspgd (OU=EFS File Encryption Certificate, L=EFS,
CN=DevilsPGD)

Recovery Agents:
Unknown (OU=EFS File Encryption Certificate, L=EFS,
CN=Administrator)

I am logged on as NTDOMAIN\devilspgd right now, so shouldn't that give
me rights to decrypt? -- Failing that, should I try
NTDOMAIN\Administrator?

[DevilsPGD]

In message <<OrCjHvgfCHA.2116@tkmsftngp08>> "David Cross [MS]"
<dcr...@online.microsoft.com> did ramble:

>Keys are stored in your profile (which may or may not be roaming). Keys are
>not automatically roamed in a domain scenario and only if you have a roaming
>profile enabled. Despite what username is on the file, you still must have
>the certificate and private key referenced on the file with efsinfo.exe to
>decrypt the file.

Ahhh, okay... That makes more sense, I didn't have a roaming profile
enabled before. Given that my account alone is listed under "Users who
can decrypt:" and "Recovery Agents" then I assume I will need to get the
old drive to boot in order to export the keys? -- Is there any way to
extract the key from the files on the drive without booting the old
drive?

I looked and I don't see a private key exported anywhere, I was always
under the (obviously mistake) impression that keys were stored on the
domain controller, so I didn't worry about local backups.

Also, thanks to everyone who has provided assistance, it's greatly
appreciated.

[DevilsPGD]

In message <<3DBC5EA0...@istar.ca>> "Michel Gallant (MVP)"
<neu...@istar.ca> did ramble:

>This *might* be an issue with EFS dormancy?
>
>"Maintaining Archives of Recovery Keys For EFS encrypted files, the
>recovery agent information is refreshed every time the file system performs
>an operation on the file (for example, when the file is opened, moved, or copied).
>However, if an encrypted file is dormant for a long time, the recovery agents
>expire. To ensure that dormant encrypted files can be recovered ,
>maintain archives of the recovery agent certificates and private keys.
>To create an archive, export the certificate and its private key to a secure medium
>and store it in a safe location. "
>
>(from Win2000 ResKit:
> http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?
> url=/windows2000/techinfo/reskit/en-us/prork/prdd_sec_lukz.asp

Some files in that directory go back to '96, and aside from being
encrypted, probably haven't been touched since '99 or so when I picked
up the hard drive in question. However, all of the truely important
ones have been accessed and likely updated within the last 2-3 weeks

That being said, the EFSINFO I posted was from a file which has not been
touched in years.

I did a EFSINFO /u /r on a more recently accessed file, and got the
below response:

events.bak: Encrypted

Users who can decrypt:
NTDOMAIN\devilspgd (OU=EFS File Encryption Certificate, L=EFS,
CN=DevilsPGD)

Recovery Agents:
NTDOMAIN\devilspgd (OU=EFS File Encryption Certificate, L=EFS,
CN=DevilsPGD)

Doesn't that mean that I should be able to decrypt it, being that I'm

logged in as NTDOMAIN\devilspgd -- I'm assuming that keys are stored at
the domain level, rather then the individual PC, is that a bad
assumption?

--

[Michel Gallant (MVP)]

This *might* be an issue with EFS dormancy?

"Maintaining Archives of Recovery Keys For EFS encrypted files, the
recovery agent information is refreshed every time the file system performs
an operation on the file (for example, when the file is opened, moved, or copied).
However, if an encrypted file is dormant for a long time, the recovery agents
expire. To ensure that dormant encrypted files can be recovered ,
maintain archives of the recovery agent certificates and private keys.
To create an archive, export the certificate and its private key to a secure medium
and store it in a safe location. "

(from Win2000 ResKit:
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?
url=/windows2000/techinfo/reskit/en-us/prork/prdd_sec_lukz.asp

- Michel Gallant
MVP Security

[DevilsPGD]

In message <<ddtoru4oubs5tt4dv...@4ax.com>> DevilsPGD
<spammelikeiwa...@crazyhat.net> did ramble:

>Ahhh, okay... That makes more sense, I didn't have a roaming profile
>enabled before. Given that my account alone is listed under "Users who
>can decrypt:" and "Recovery Agents" then I assume I will need to get the
>old drive to boot in order to export the keys? -- Is there any way to
>extract the key from the files on the drive without booting the old
>drive?

I was able to get the old drive to boot, but I'm not able to export the
keys, I got a wack of DLL errors when I tried. Is there any other
option?