1

I have two servers, both on domain, both Windows Server 2008 R2, to my eye almost identically configured.

Server1 allows to copy encrypted files to his network shares, Server2 gives error when trying to copy encrypted file: "You are copying the file to a destination that does not support encryption" (preferred action).

Both servers have registry entry NtfsDisableEncryption set to 0.

I've reviewed GPO and can't see anything related to EFS. Nor I recall setting.

Where I can find option responsible for this behaviour?

How/where I can find difference between those server that determines this behaviour?

  • Just to be sure, are both shares on NTFS? Can you encrypt files locally on the share that does not allow encryption? – Ale Oct 5 '14 at 19:57
2

I didn't know the answer to this, but it looked interesting so I'd thought I'd try and replicate the problem.

With a default install of 2012 R2 (didn't have 2008 R2 to hand) I got the same error when trying to copy an EFS encrypted file from one domain joined machine to a share on another.

Google eventually lead me to this article;

http://technet.microsoft.com/en-us/library/bb457116.aspx#EHAA

Answer

In Active Directory Users & Computers, locate the machine account for the failing server. Open the properties window, on the Delegation tab tick "Trust this computer for delegation to any service (Kerberos only)".

Reboot the server.

You should now be able to copy EFS encrypted files to the file share remotely.

That solved it for me; hopefully it will for you too.

The clue that eventually lead me to this was to try encrypting an existing remote file; this also fails, but the error message is far more useful "The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation."

The reason (as I understand it) that this is required is because of the way the file copy works over the network. When transmitting the file of CIFS/SMB the file is decrypted on the source machine, transmitted in plain-text, and re-encrypted on the destination. In order for the remote file server to re-encrypt the file on arrival the EFS service must impersonate the user account of the user who initiated the file copy.

It should be noted that there are a number of other issues that must be taken into account if you will allow EFS files to be stored on remote file shares; the link I posted above outlines a number of these in some detail - the article is well worth a read.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.