Assuming you completed the steps described in the previous installment of this article and encrypted a file, you will likely to test it. The easiest way to make sure that an encrypted file is inaccessible to other users is by trying to access it under another user account. For proper testing, make sure that another user has the share and NTFS permissions necessary to access the file. Log onto the computer using an account other than the one you were logged in with when you encrypted the file. When you browse to the file and open it, you will receive an access denied message. If you are successful in opening the file, verify that you did not grant the user account access to the encrypted file.

Keep in mind that the user who cannot open the encrypted file, may still be able to delete the file. You might be confused as to how this is possible. Here’s the answer: The user has full-share and NTFS permissions to the file. These permissions include reading, modifying, and deleting the file. If the user doesn’t try to open the file, the EFS subsystem isn’t required. If the user tries to open the file, the EFS subsystem intervenes and denies access. But users can simply select the file and press the delete button, which they have rights to do as defined by the NTFS permissions. Remember, file encryption is used to protect the contents of a file from prying eyes. It is not designed to protect the file itself. That’s why a properly designed share and NTFS structure is still critical even when using EFS.

Another point to remember when implementing EFS is that when an encrypted file is moved or copied from its original location to a new location, it is first decrypted. But this isn’t a hole in the security scheme. To copy or move an encrypted file, you must have the ability to open the encrypted file. In fact, even if a user has NTFS rights but doesn’t have rights to decrypt the file, he or she will be greeted with the access denied error message.

[tags]windows, vista, efs[/tags]