[dpapas665]

I've been trying to get an EFS encrypted file located on a user's
machine available to another user. Both machines are in the domain,
NTFS permissions are wide open, and all relevant users' EFS
certificates have been imported and show up both in the "Details"
window and in the "trusted people" store. By all accounts, the added
user should be able to open this file, but I've had no luck so far
makig this happen. Any ideas on how to proceed with troubleshooting
this issue?

Thanks,
-D.

[Pat Hoffer [MSFT]]

To be able to share encrypted files remotely, the machine account hosting the
share must be "trusted for delegation" and both users must have profile
directories on that machine. You can do this by having the second user log
onto the machine and encrypting a file so that his profile contains an EFS
certificate/key. After that the first user can add that certificate to files
for remote access by the second user. (The added certificate must be the
same certificate that's in the profile directory. Check the thumbprint in
the certificate properties.) If the second user has a roaming profile with
an EFS certificate published to AD, the first user can add that certificate
to files. In the roaming profile case, a logon is not necessary.

I hope I haven't completely confused you, but sharing encrypted files
remotely is a little tricky--but it can be done. You can read more about it
here:
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prnb_efs_hzqx.asp
Look under Ch 17 > Remote EFS Operations on File Shares and Web Folders >
Remote EFS Operations in a File Share Environment.

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


"dpapas665" wrote:

> I've been trying to get an EFS encrypted file located on a user's
> machine available to another user. Both machines are in the domain,
> NTFS permissions are wide open, and all relevant users' EFS
> certificates have been imported and show up both in the "Details"
> window and in the "trusted people" store. By all accounts, the added
> user should be able to open this file, but I've had no luck so far
> makig this happen. Any ideas on how to proceed with troubleshooting
> this issue?
>
> Thanks,
> -D.
>
>

[dpapas665]

OK, I logged locally into the machine and imported my cert (including
private key) to the remote machine and turned on "trust computer for
delegation" in AD. Thus far, that solved the problem in that, if a file
is encrypted, both users can decrypt it when logged lcoally into that
machine. However, I found I was still unable to remotely encrypt or
decrypt it. Trying to decrypt, got "access denied". Trying to encrypt,
got the error: "the requested operation requires delegation to be
enabled on the machine".

So, the remaining problem looks to be the "trust computer for
delegation". I checked the userAccountControl field for the computer
account in ADSIEdit to see if the setting had taken, and it appears to
have the value (528834) required as specified by MS KB# 305144, and the
user account doesn't have the "account is sensitive and cannot be
delegated" property set. So, at this point I'm not sure why the remote
machine won't impersonate the user as pointed out in the article you
referred me to:

Remote EFS operatons in a file share environment
6. EFS must impersonate the user to obtain access to the necessary
public or private key. This requires the following:

1. The computer must be a domain member in a domain that uses
Kerberos authentication because impersonation relies on Kerberos
authentication and delegation.
2. The computer must be trusted for delegation.
3. The user must be logged on with a domain account that can be
delegated.


Thanks again,
-D.

[Pat Hoffer [MSFT]]

It sounds like you need a fresh logon on the second machine. It's still
seeing the server as non-TFD. Try logging off and on again on that machine.

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


"dpapas665" wrote:

> OK, I logged locally into the machine and imported my cert (including
> private key) to the remote machine and turned on "trust computer for
> delegation" in AD. Thus far, that solved the problem in that, if a file
> is encrypted, both users can decrypt it when logged lcoally into that
> machine. However, I found I was still unable to remotely encrypt or
> decrypt it. Trying to decrypt, got "access denied". Trying to encrypt,
> got the error: "the requested operation requires delegation to be
> enabled on the machine".
>
> So, the remaining problem looks to be the "trust computer for
> delegation". I checked the userAccountControl field for the computer
> account in ADSIEdit to see if the setting had taken, and it appears to
> have the value (528834) required as specified by MS KB# 305144, and the
> user account doesn't have the "account is sensitive and cannot be
> delegated" property set. So, at this point I'm not sure why the remote
> machine won't impersonate the user as pointed out in the article you
> referred me to:
>
> Remote EFS operatons in a file share environment
> 6. EFS must impersonate the user to obtain access to the necessary
> public or private key. This requires the following:
>
> 1. The computer must be a domain member in a domain that uses
> Kerberos authentication because impersonation relies on Kerberos
> authentication and delegation.
> 2. The computer must be trusted for delegation.
> 3. The user must be logged on with a domain account that can be
> delegated.
>
>
> Thanks again,
> -D.
>
>

[dpapas665]

Hmm, tried restarting the remote host earlier to no effect. Pehaps
some AD replication needed to happen? Anyway, I rebooted both after I
got your reply and it seems to work fine.

Thanks again for the help!

-D.