Can't de-crypt using same login and machine

I'm hoping somebody here can point me in the right direction. I work at a
small nonprofit where we manage our IT needs with the equivalent know-how of
chewing gum and duct tape.

A couple months ago, someone in our office encrypted a bunch of Excel
spreadsheets and a couple folders using the right-click, Properties,
Advanced. Encrypt function. Now nobody, including that person, can access or
de-crypt them.

The encryption was done directly on our mainserver logged in as
Administrator. The same login on the same machine is now denied access to the
files. Stranger still is that when I try looking at Advanced Attributes
Properties, about half the files pop up the error message "EFSADU - Unable to
find the user information for the file." The following screen lists no data
for Encryption Details. (The other half of files do list a User Name and
Recovery Agent Name, but again no login is allowed access.)

This has got me baffled, even after spending most of my day searching for an
answer in the related kb articles. Any suggestions are greatly appreciated.

Addendum: We just figured out that the person was not logged in as
Administrator when they encrypted the files. Using their personal login
solves the problem for half of them. The other half (the ones with no User or
Recovery Agent info) are still locked though. I'm also still really confused
about why Administrator couldn't access them, even though it was designated
as a Recovery Agent.

In news:B0B7F3DE-176B-4890-914F-D152EAB418D7@microsoft.com,
Jason <Jason@discussions.microsoft.com> had this to say:

My reply is at the bottom of your sent message:

> Addendum: We just figured out that the person was not logged in as
> Administrator when they encrypted the files. Using their personal
> login solves the problem for half of them. The other half (the ones
> with no User or Recovery Agent info) are still locked though. I'm
> also still really confused about why Administrator couldn't access
> them, even though it was designated as a Recovery Agent.

The RA might not have had the key? I have no idea how you're setup there or
what you're doing. Anyhow, the trick here would be to lock that function
down (if possible or not needed) and to rely on ownership and groups. Now
that you have the files - decrypt them. EFS in a duct-tape environment is
NOT going to be a good idea without best practices being followed, exporting
keys etc...

--
Galen - MS MVP - Windows (Shell/User & IE)
http://dts-l.org/
http://kgiii.info/

"We approached the case, you remember, with an absolutely blank mind,
which is always an advantage. We had formed no theories. We were simply
there to observe and to draw inferences from our observations." -
Sherlock Holmes

Yeah, it was quickly apparent that EFS was a bad idea. (It was done as a
knee-jerk reaction to indications from our firewall that someone may have
been trying to hack the server.) Our staff is only ten people though, and
everyone already knows not to try that again.

I've de-crypted everything we were able to gain access to, but we still
can't get at those files which pop up the error message "EFSADU - Unable to
find the user information for the file." The following screen lists no data
for User or Recovery Agent in the Encryption Details.

So if anyone knows a way around this, again it's much appreciated.


> The RA might not have had the key? I have no idea how you're setup there or
> what you're doing. Anyhow, the trick here would be to lock that function
> down (if possible or not needed) and to rely on ownership and groups. Now
> that you have the files - decrypt them. EFS in a duct-tape environment is
> NOT going to be a good idea without best practices being followed, exporting
> keys etc...
>
> --
> Galen - MS MVP - Windows (Shell/User & IE)
> http://dts-l.org/
> http://kgiii.info/
>
> "We approached the case, you remember, with an absolutely blank mind,
> which is always an advantage. We had formed no theories. We were simply
> there to observe and to draw inferences from our observations." -
> Sherlock Holmes
>
>
>

Try using efsinfo to see what is shows for what user can potentially access
those files and the name of the Recovery Agent if any. Efsinfo has a bug
that may not display the name of the RA but it still should show the
certificate thumbprint info if one exists. If you find the user and the user
is a domain user you can reset the user's password and logon as the user to
access the files if the user account still exists. If he is not a domain
user you can try to crack his password with a free program such as Cain &
Abel which may not be that hard unless you enforce complex passwords. Also
run Check Disk on that server and make sure the user and administrator have
full control permissions to the folder/files as lack of needed permissions
can prevent the legitimate user from decrypting their EFS files. --- Steve

http://support.microsoft.com/?kbid=243026 --- you may need to install the
support tools for the proper operating system
http://www.oxid.it/cain.html --- Cain & Abel


"Jason" <Jason@discussions.microsoft.com> wrote in message
news:F8531849-D91C-4A76-AFD5-64A4A5F325AB@microsoft.com...
> Yeah, it was quickly apparent that EFS was a bad idea. (It was done as a
> knee-jerk reaction to indications from our firewall that someone may have
> been trying to hack the server.) Our staff is only ten people though, and
> everyone already knows not to try that again.
>
> I've de-crypted everything we were able to gain access to, but we still
> can't get at those files which pop up the error message "EFSADU - Unable
> to
> find the user information for the file." The following screen lists no
> data
> for User or Recovery Agent in the Encryption Details.
>
> So if anyone knows a way around this, again it's much appreciated.
>
>
>> The RA might not have had the key? I have no idea how you're setup there
>> or
>> what you're doing. Anyhow, the trick here would be to lock that function
>> down (if possible or not needed) and to rely on ownership and groups. Now
>> that you have the files - decrypt them. EFS in a duct-tape environment is
>> NOT going to be a good idea without best practices being followed,
>> exporting
>> keys etc...
>>
>> --
>> Galen - MS MVP - Windows (Shell/User & IE)
>> http://dts-l.org/
>> http://kgiii.info/
>>
>> "We approached the case, you remember, with an absolutely blank mind,
>> which is always an advantage. We had formed no theories. We were simply
>> there to observe and to draw inferences from our observations." -
>> Sherlock Holmes
>>
>>
>>

Steven,

Thanks for your input. I should have mentioned that our workstations run Win
XP Pro SP2, and the machine where the files were encrypted from is Win Server
2003 Standard SP1.

And according to the kb articles I've been reading, the efsinfo command
should work with those operating systems. But it doesn't. I keep getting the
message "'efsinfo' is not recognized as an internal or external command,
operable program or batch file."

I've tried using cipher /d /a on the affected folders, but that's fruitless.
Without access to who the user, recovery agent, or thumbprint used to encrypt
the files was, all I can do is relieve stress by squeezing my squishy blue
balls. (The promo items from an MSDN event, what did you think...)


"Steven L Umbach" wrote:

> Try using efsinfo to see what is shows for what user can potentially access
> those files and the name of the Recovery Agent if any. Efsinfo has a bug
> that may not display the name of the RA but it still should show the
> certificate thumbprint info if one exists. If you find the user and the user
> is a domain user you can reset the user's password and logon as the user to
> access the files if the user account still exists. If he is not a domain
> user you can try to crack his password with a free program such as Cain &
> Abel which may not be that hard unless you enforce complex passwords. Also
> run Check Disk on that server and make sure the user and administrator have
> full control permissions to the folder/files as lack of needed permissions
> can prevent the legitimate user from decrypting their EFS files. --- Steve
>
> http://support.microsoft.com/?kbid=243026 --- you may need to install the
> support tools for the proper operating system
> http://www.oxid.it/cain.html --- Cain & Abel
>
>
> "Jason" <Jason@discussions.microsoft.com> wrote in message
> news:F8531849-D91C-4A76-AFD5-64A4A5F325AB@microsoft.com...
> > Yeah, it was quickly apparent that EFS was a bad idea. (It was done as a
> > knee-jerk reaction to indications from our firewall that someone may have
> > been trying to hack the server.) Our staff is only ten people though, and
> > everyone already knows not to try that again.
> >
> > I've de-crypted everything we were able to gain access to, but we still
> > can't get at those files which pop up the error message "EFSADU - Unable
> > to
> > find the user information for the file." The following screen lists no
> > data
> > for User or Recovery Agent in the Encryption Details.
> >
> > So if anyone knows a way around this, again it's much appreciated.
> >
> >
> >> The RA might not have had the key? I have no idea how you're setup there
> >> or
> >> what you're doing. Anyhow, the trick here would be to lock that function
> >> down (if possible or not needed) and to rely on ownership and groups. Now
> >> that you have the files - decrypt them. EFS in a duct-tape environment is
> >> NOT going to be a good idea without best practices being followed,
> >> exporting
> >> keys etc...
> >>
> >> --
> >> Galen - MS MVP - Windows (Shell/User & IE)
> >> http://dts-l.org/
> >> http://kgiii.info/
> >>
> >> "We approached the case, you remember, with an absolutely blank mind,
> >> which is always an advantage. We had formed no theories. We were simply
> >> there to observe and to draw inferences from our observations." -
> >> Sherlock Holmes
> >>
> >>
> >>
>
>
>

Efsinfo should work. First see if it is on the computer by searching for it
and if not install the support tools from the W2003 from the W2003 install
disk in the support/tools folder or download from the link below. Try using
the full path to efsinfo to execute it or copying it to the \windows folder
to get it to run. --- Steve

http://www.microsoft.com/downloads/d...displaylang=en

"Jason" <Jason@discussions.microsoft.com> wrote in message
news:0FF05270-90B8-4B9B-B136-413E93F0B7B1@microsoft.com...
> Steven,
>
> Thanks for your input. I should have mentioned that our workstations run
> Win
> XP Pro SP2, and the machine where the files were encrypted from is Win
> Server
> 2003 Standard SP1.
>
> And according to the kb articles I've been reading, the efsinfo command
> should work with those operating systems. But it doesn't. I keep getting
> the
> message "'efsinfo' is not recognized as an internal or external command,
> operable program or batch file."
>
> I've tried using cipher /d /a on the affected folders, but that's
> fruitless.
> Without access to who the user, recovery agent, or thumbprint used to
> encrypt
> the files was, all I can do is relieve stress by squeezing my squishy blue
> balls. (The promo items from an MSDN event, what did you think...)
>
>
> "Steven L Umbach" wrote:
>
>> Try using efsinfo to see what is shows for what user can potentially
>> access
>> those files and the name of the Recovery Agent if any. Efsinfo has a bug
>> that may not display the name of the RA but it still should show the
>> certificate thumbprint info if one exists. If you find the user and the
>> user
>> is a domain user you can reset the user's password and logon as the user
>> to
>> access the files if the user account still exists. If he is not a domain
>> user you can try to crack his password with a free program such as Cain &
>> Abel which may not be that hard unless you enforce complex passwords.
>> Also
>> run Check Disk on that server and make sure the user and administrator
>> have
>> full control permissions to the folder/files as lack of needed
>> permissions
>> can prevent the legitimate user from decrypting their EFS files. ---
>> Steve
>>
>> http://support.microsoft.com/?kbid=243026 --- you may need to install
>> the
>> support tools for the proper operating system
>> http://www.oxid.it/cain.html --- Cain & Abel
>>
>>
>> "Jason" <Jason@discussions.microsoft.com> wrote in message
>> news:F8531849-D91C-4A76-AFD5-64A4A5F325AB@microsoft.com...
>> > Yeah, it was quickly apparent that EFS was a bad idea. (It was done as
>> > a
>> > knee-jerk reaction to indications from our firewall that someone may
>> > have
>> > been trying to hack the server.) Our staff is only ten people though,
>> > and
>> > everyone already knows not to try that again.
>> >
>> > I've de-crypted everything we were able to gain access to, but we still
>> > can't get at those files which pop up the error message "EFSADU -
>> > Unable
>> > to
>> > find the user information for the file." The following screen lists no
>> > data
>> > for User or Recovery Agent in the Encryption Details.
>> >
>> > So if anyone knows a way around this, again it's much appreciated.
>> >
>> >
>> >> The RA might not have had the key? I have no idea how you're setup
>> >> there
>> >> or
>> >> what you're doing. Anyhow, the trick here would be to lock that
>> >> function
>> >> down (if possible or not needed) and to rely on ownership and groups.
>> >> Now
>> >> that you have the files - decrypt them. EFS in a duct-tape environment
>> >> is
>> >> NOT going to be a good idea without best practices being followed,
>> >> exporting
>> >> keys etc...
>> >>
>> >> --
>> >> Galen - MS MVP - Windows (Shell/User & IE)
>> >> http://dts-l.org/
>> >> http://kgiii.info/
>> >>
>> >> "We approached the case, you remember, with an absolutely blank mind,
>> >> which is always an advantage. We had formed no theories. We were
>> >> simply
>> >> there to observe and to draw inferences from our observations." -
>> >> Sherlock Holmes
>> >>
>> >>
>> >>
>>
>>
>>

Steven,

Thanks again for your guidance. Efsinfo was on the machine but not installed
until I followed your instructions. After loading it, I went into the command
prompt to use it on the affected folders. Unfortunately, that did not solve
our problem.

For all of the same files that I couldn't get Windows to display data for a
User, Recovery Agent, or Thumbprint ("EFSADU - Unable to find the user
information for the file."), the Efsinfo command line brings up the error
message: "Overlapped I/O Operation is in Progress." So it was a good try, but
the same result: No encryption data available, hence no way to decrypt.

I did a little more poking around the server, and noticed another odd thing.
When I went into Administrative Tools, Certificate Services, this error
message popped up: "Cannot manage Certificate Services; The specified service
does not exist as an installed service 0x424 (WIN32: 1060)." Based on the
amount of information about CS in the kb I suspect it's important, but do not
quite grasp it. Most importantly, I need to know if Certificate Services not
being installed at the time these files were encrypted is causing the error
message, and if so is there any fix for the situation?

One other thing which may have caused a problem. Around the time these files
were encrypted, the Administrator password on the server was changed. (The
person who did both can't remember which came first.) Could this be a factor,
and would changing the password back help?

Once again, to Steven and anyone else reading this who knows more than I,
thank you in advance. Your advice is appreciated.


"Steven L Umbach" wrote:

> Efsinfo should work. First see if it is on the computer by searching for it
> and if not install the support tools from the W2003 from the W2003 install
> disk in the support/tools folder or download from the link below. Try using
> the full path to efsinfo to execute it or copying it to the \windows folder
> to get it to run. --- Steve
>
> http://www.microsoft.com/downloads/d...displaylang=en

Yikes. I have never seen efsinfo do that. What I would try is to use efsinfo
on some freshly encrypted test files to see if it does the same thing or not
to try and determine if the problem is using efsino in general or just for
the files you can not access. If you have not done so yet run Check Disk on
that computer selecting to fix file errors automatically.

Certificate Services will not work unless the computer is a Certificate
Authority and that is not needed for EFS nor I seriously doubt it is a
related problem. The command certutil -TCAinfo will dump a lot of
information if the computer is a CA. Changing the administrator password
should not make any difference unless the administrator was the user that
encrypted the files or was the Recovery Agent in that case if the password
was "reset" using Local User and Computers versus being changed like a user
normally would with control-alt-delete or when prompted to then that will
deny access to EFS files that the administrator encrypted and changing it
back could allow access assuming again that the administrator encrypted the
files and the EFS private key is still in the administrator's profile. ---
Steve


"Jason" <Jason@discussions.microsoft.com> wrote in message
news:5EB2FCE7-C70E-43E4-9BF7-F1C9773356F3@microsoft.com...
> Steven,
>
> Thanks again for your guidance. Efsinfo was on the machine but not
> installed
> until I followed your instructions. After loading it, I went into the
> command
> prompt to use it on the affected folders. Unfortunately, that did not
> solve
> our problem.
>
> For all of the same files that I couldn't get Windows to display data for
> a
> User, Recovery Agent, or Thumbprint ("EFSADU - Unable to find the user
> information for the file."), the Efsinfo command line brings up the error
> message: "Overlapped I/O Operation is in Progress." So it was a good try,
> but
> the same result: No encryption data available, hence no way to decrypt.
>
> I did a little more poking around the server, and noticed another odd
> thing.
> When I went into Administrative Tools, Certificate Services, this error
> message popped up: "Cannot manage Certificate Services; The specified
> service
> does not exist as an installed service 0x424 (WIN32: 1060)." Based on the
> amount of information about CS in the kb I suspect it's important, but do
> not
> quite grasp it. Most importantly, I need to know if Certificate Services
> not
> being installed at the time these files were encrypted is causing the
> error
> message, and if so is there any fix for the situation?
>
> One other thing which may have caused a problem. Around the time these
> files
> were encrypted, the Administrator password on the server was changed. (The
> person who did both can't remember which came first.) Could this be a
> factor,
> and would changing the password back help?
>
> Once again, to Steven and anyone else reading this who knows more than I,
> thank you in advance. Your advice is appreciated.
>
>
> "Steven L Umbach" wrote:
>
>> Efsinfo should work. First see if it is on the computer by searching for
>> it
>> and if not install the support tools from the W2003 from the W2003
>> install
>> disk in the support/tools folder or download from the link below. Try
>> using
>> the full path to efsinfo to execute it or copying it to the \windows
>> folder
>> to get it to run. --- Steve
>>
>> http://www.microsoft.com/downloads/d...displaylang=en
>

Test files work just fine. We'll try the rest of this when the office is open
again on Tuesday, and I'll post the results then.

Thanks again for all your advice. Happy new year!

"Steven L Umbach" wrote:

> Yikes. I have never seen efsinfo do that. What I would try is to use efsinfo
> on some freshly encrypted test files to see if it does the same thing or not
> to try and determine if the problem is using efsino in general or just for
> the files you can not access. If you have not done so yet run Check Disk on
> that computer selecting to fix file errors automatically.
>
> Certificate Services will not work unless the computer is a Certificate
> Authority and that is not needed for EFS nor I seriously doubt it is a
> related problem. The command certutil -TCAinfo will dump a lot of
> information if the computer is a CA. Changing the administrator password
> should not make any difference unless the administrator was the user that
> encrypted the files or was the Recovery Agent in that case if the password
> was "reset" using Local User and Computers versus being changed like a user
> normally would with control-alt-delete or when prompted to then that will
> deny access to EFS files that the administrator encrypted and changing it
> back could allow access assuming again that the administrator encrypted the
> files and the EFS private key is still in the administrator's profile. ---
> Steve
>