Technology is key, don't you think?   If you are searching for a laptop pc, then search no further! Our gadget shop has anything you need! Take a glimpse at a hp laser printer along with our cheapest deals on a hp toner you will find!

Working With NTFS Encryption

By: Brien M. Posey, MCSE

  You’ve probably heard that the version of the NTFS file system that’s included with Windows 2000 is different from the version included with prior versions of Windows NT. This new version of NTFS supports new features such as disk quotas and file level encryption. In this article, I’ll discuss NTFS level encryption. As I do, I’ll discuss some of the issues that you’ll face over time if you decide to implement NTFS encryption.

In Windows 2000, file encryption is applied through an NTFS attribute in the same way that you would apply an attribute to compress a file. However, Windows 2000 doesn’t allow you to use compression and encryption at the same time. In fact, there are a lot of strange rules that apply to NTFS encryption. Often times, unless you’re unfamiliar with the rules, you can end up with totally unexpected results when you encrypt files or folders. Therefore, I strongly recommend familiarizing yourself with the NTFS encryption behavior patterns and rules before you try to implement NTFS encryption in your organization.

The essence of NTFS encryption is that it’s designed so that only the creator of a file can view the file’s contents. To the creator, an encrypted file appears as any other file would. The file’s creator doesn’t have to go through any special decryption procedure to view the file’s contents. The decryption process is completely automatic. Likewise, applications that try to read the file can do so without having to go through any special procedures. However, any one else who tries to view an encrypted file will see gibberish (assuming that they can even gain access to the file to try looking at it).

I mentioned that the creator of an encrypted file could access the file, but that everyone else would see gibberish. The fact of the matter is that under normal circumstances the file’s creator is the only one who can view the file, because the creator is the user that encrypted the file. Not even the administrator can view an encrypted file, although in an emergency an administrator can decrypt a file. Even if you change a file’s ownership, the new owner won’t be able to read an encrypted file, because they weren’t the one who originally created (encrypted) the file. While the fact that administrators and in some cases, the owner of an encrypted file can’t view the file’s contents may seem a little harsh, Windows is specifically designed this way for security reasons. For example, how many times have you heard stories of administrators who sold copies of sensitive files to other companies or to rival employees within the same company? Encryption keeps administrators and others from being able to distribute sensitive files.

Of course before an employee can use NTFS encryption effectively, they need to understand its behavior. For example, one might assume that once a file has been encrypted, it’s always encrypted unless someone decrypts it. However, this isn’t necessarily the case. Remember that the encryption process is attribute based. Therefore, if an encrypted file is copied or moved to a medium that doesn’t support this attribute, such as a floppy disk, a FAT partition, or even an older NTFS partition, the encryption is removed. This means that if a user encrypted a file and then copied the file to a floppy, the copy on the hard disk would remain encrypted, but the copy on the floppy would be accessible to anyone because floppy disks don’t support NTFS version 5 partitions.

Windows 2000 allows you to encrypt both files and folders. While encrypting files is an easy process with a relatively simple set of rules applying to it, you have to be a lot more careful when you encrypt folders. When you encrypt a folder, Windows 2000 behaves differently depending on whether or not the folder currently has anything in it. Suppose for a moment that a user creates a new folder and encrypts the folder before placing any files in the folder. In such a case, any files that are placed into the folder are encrypted. However, the files in the folder are available only to the user who created the file (or moved it into the folder). This means that if User A created an encrypted folder and User B placed a file into it, only User B would be able to view the encrypted file. The fact that User A assigned the encryption is irrelevant.

Now suppose that a user decided to encrypt a folder that already contained files. In this situation, Windows 2000 behaves totally differently. At the time of the encryption, Windows 2000 gives the user who’s performing the encryption a choice of whether or not to encrypt the files contained in the folder. If the user who’s encrypting the folder chooses not to encrypt the existing files, the files will remain unencrypted and accessible to everyone with rights to the folder. Users accessing these files can read and modify the files without the files becoming encrypted. However, if a user renames an existing file then the file will become encrypted.

Now, let’s suppose that the user who encrypted the folder decided to encrypt all of the files contained within the folder. In this case, the files would become accessible only to the user who encrypted them. Even files owned by a different user would only be accessible to the user who implemented the encryption.

I’ve stated that you can encrypt files and folders as long as they exist on NTFS version 5 partitions. However, there are some exceptions to this. For starters, you can’t encrypt files that are a part of the Windows 2000 operating system. Another exception is that you can’t encrypt a system’s root directory. It stands to reason that you can’t encrypt the root directory on your active partition since the root directory would contain some of the Windows 2000 system files. However, the root directory restriction applies to every partition in your system. You can only encrypt folders that reside beneath the root level.

Encrypting Files

Before I begin discussing all of the issues that you’ll face when working with encryption, let’s take a brief look at the actual encryption process. To encrypt a file on an NTFS version 5 partition, select the file or folder that you want to encrypt. Next, right click on the folder select the Properties command from the resulting context menu. When you see the folder’s properties sheet, select the General tab and click the Advanced button. On the following dialog box, select the Encrypt Contents to Secure Data check box and click OK twice. At this point, if you’re encrypting a folder, you’ll see a dialog box that asks if you want to encrypt only the folder that you’ve selected or the folder, all sub folders and the files that they contain. Make your selection, click OK and the files or folders will be encrypted.

 Decrypting Files

As you’ve seen, encryption can cause some undesirable side effects. So what happens if a user encrypts a file and then decides that the encryption was a mistake? The user who encrypted a file or folder can easily decrypt it by right clicking on the file or folder and selecting the Properties command from the resulting context menu. On the file or folder’s properties sheet, select the General tab and click the Advanced button. Windows will now display a dialog box that contains a check box called Encrypt Contents To Secure Data. Simply remove the check mark from this check box and click OK twice. If the user is decrypting a folder, Windows will ask the user if they want to decrypt the files and subfolders contained within the folder or just the folder itself. After the user makes their selection, Windows will decrypt the appropriate files and folders.

Disgruntled Users

You’ve seen some of the problems that can be caused by encryption, so you may be wondering what would happen if a disgruntled user were to encrypt a bunch of folders and files that were heavily used by multiple people and then walk off of the job. What you’ll have to go through to decrypt the files depends a lot on how your network is setup and on how smart the disgruntled user is.

The easiest thing to do in such a situation is to log on as an administrator and then change the user’s password. Once you’ve changed the user’s password, login as the user and decrypt the files. However, there are situations in which this process simply won’t work. The file encryption process is based on key public key and symmetric key encryption. Therefore, if a user were to delete their keys before leaving, then simply logging on as the user to decrypt the files wouldn’t work. In such a situation, you’d have to resort to a more complicated method of recovery.

One solution might be to restore the files and folders from a backup that was made before the user quit. However, this may not be an option because you’d lose any file updates that were made after the time of that backup. If you simply want to decrypt the files, you’ll have to use something called a recovery agent certificate. The actual recovery process is complicated, but it involves adding the certificate to the Active Directory’s recovery policy. The recovery agent certificate is based on the public key infrastructure. This means that the certificate contains the necessary data to decrypt the file.

As you can see, there’s a lot of issues to take into consideration before you decide to permit file level encryption on your network. Before you allow users to encrypt files and folders, you should make sure that they understand the repercussions of doing so. You should also develop a file recovery plan in advance just in case a user were to encrypt files and then quit the company.

If you've found this article helpful then please consider making a donation to help with the cost of keeping this site going. To make a donation, please click on the PayPal link below.