Files and FoldersConcepts | Windows Server 2003 in a Nutshell

Files and FoldersConcepts

This topic deals with various aspects of managing files and folders, including attributes, compression, encryption, and various ways of displaying and manipulating files and folders. For additional information, see Disks , Permissions , and Shared Folders in this chapter.

Attributes

Attributes are properties of a file or folder that indicate something about its state. The attributes you can set for files or folders depend on whether the underlying partition or volume is formatted using FAT, FAT32, or NTFS:

Read-only (NTFS and FAT): When applied to a file, this prevents the contents of the file from being modified. If applied to a folder, you can choose to make either the folder alone read-only or the folder and all its contents (including subfolders ) read-only. Making the folder alone read-only isn't very useful since new files you create in the folder don't inherit this attribute. By default, operating-system files are always marked Read-only, Hidden, and System.
Hidden (NTFS and FAT): This hides the file or folder from normal view the next time you view the parent folder's contents. By default, operating-system files are marked Read-only and Hidden. To display hidden files in Windows Explorer, select Tools Folder Options View Show hidden files and folders.
File/Folder is ready for archiving (NTFS and FAT): When marked, this indicates that the file or folder should be backed up during the next backup cycle. Once the file or folder has been backed up, the Archive attribute is automatically cleared. When a file or folder is created or its contents are modified, this attribute is automatically set.
For fast searching, allow Indexing Service to index this file/folder (NTFS only): The Indexing Service works automatically in the background to build a catalog that speeds up searching for files and folders. By default, all files and folders on NTFS volumes have this attribute marked, but the Indexing Service is not started by default on WS2003.
Compress contents to save disk space (NTFS only): This stores the file or folder in a compressed state on an NTFS volume.
Encrypt contents to secure data (NTFS only): This stores the file or folder in an encrypted state on an NTFS volume.

Compression

Files and folders stored on NTFS volumes can be compressed to minimize the amount of disk space they occupy. When these files are accessed, the operating system uncompresses them automatically so they can be read or modified; when the modified files are saved or closed, they are automatically compressed again. The whole process is transparent to the user . Both files and folders can be compressed. If a folder is compressed, the files within it don't need to be compressedor some may be and others not. When a file is copied from one place to another, it is uncompressed, copied , and then compressed again. If there is insufficient disk space to hold the uncompressed file, an error message will occur and the copy will fail.

Certain file types can be effectively compressed, resulting in significant gains in disk space, while compressing other file types shows little gain in space. For example, a compressed bitmap ( .bmp ) may need only 25% or less of its uncompressed space, while compressing a binary executable program file ( .exe ) rarely results in a significant gain in space. You should not try to compress files that are already compressed, such as WinZip ( .zip ) files. This simply results in wasted processing power.

Data that is frequently modified, such as users' work files in their home folders, generally should not be compressed due to the overhead of the compression process. In addition, if you are using disk quotas to manage how much disk space is allocated to users, these disk quotas are calculated on the basis of the uncompressed size of users' files. So it really doesn't make sense to compress frequently accessed files. Instead, compress data that is relatively static in naturefor example, archived financial records stored on disk. This is really the only practical use for compression on NTFS volumes.

Encryption

NTFS permissions provide a way of securing files and folders from unauthorized local access. For example, if two users share a computer, assigning full control for each user to their own files prevents the users from accessing each other's files. However, administrators have the right to take ownership of any files on the system, but normally, users with Administrative privileges are considered trustworthy. A problem could occur if someone illicitly gained access to a user's computer and removed the hard drive from the system. The person could then install the NTFS drive in her own computer, log on as the local Administrator for that computer, and take ownership of any files on the stolen drive. Therefore, NTFS permissions themselves can't protect data from the theft of the hard drive itself. Additionally, third-party utilities have been developed that allow users to boot their computer from a floppy disk and access NTFS partitions directly. These utilities, though of some administrative use in troubleshooting situations, nevertheless pose a security risk for sensitive data stored on physically accessible systems.

To prevent such scenarios from occurring, WS2003 includes a feature called the Encrypting File System (EFS), which allows encryption of files and folders on NTFS volumes to protect them from unauthorized local access. When these files are accessed by their associated application, the operating system decrypts them automatically so they can be opened for reading or modification. When the modified files are saved or closed, they are automatically encrypted again. The whole process is transparent to the user. Both files and folders can be encrypted or unencrypted. If a folder is encrypted, the files within it don't need to be encrypted, or some may be and others not.

When a user encrypts his datafiles, only he can decrypt these files, and no other user can read them. To share an encrypted file's contents with another user in order to collaborate on work, the user must first decrypt the file so the other user can use it. Members of the Administrators group , however, have the right to decrypt any encrypted files.

Never encrypt files in the system directory where the WS2003 boot files are located. Since the key for decrypting these files can't be accessed until the operating system has booted and a user has logged on, WS2003 will not be able to start. Of course, WS2003 safeguards against this by preventing you from encrypting files that have the System attribute set. But if you have removed the System attribute from these files using the attrib command (perhaps while troubleshooting startup problems) and failed to reset this attribute on the files afterward, the possibility of encrypting them exists.

How EFS Works

EFS is integrated into NTFS and uses private-key cryptography to ensure that data encrypted by users can be accessed only by that user (or by an administrator). For each file that a user encrypts, an associated private key called the file-encryption key is created, which can be used later to decrypt the file. This file-encryption key is itself encrypted in the form of an encryption certificate or EFS certificate, which is encrypted using both the user's public key and the public key of an authorized recovery agent (so the file can be decrypted after disaster recovery has been performed). The administrator by default is an authorized recovery agent.

To decrypt an encrypted file, the file-encryption key for the file must first itself be decrypted. This can be done using either:

The private key corresponding to the public key that belongs to the user who encrypted the file (in other words, by the user herself)
The private key of an authorized recovery agent (Administrator)

Once the file-encryption key for the encrypted file has been decrypted, the encrypted file itself can be decrypted.

Strategies for Using Encryption

Encryption is particularly useful for users with portable computers. Should your laptop be stolen while traveling, encryption provides a way of keeping your data safe from prying eyes. Otherwise, the decision to employ encryption on file servers throughout your enterprise should be weighed carefully . Since encryption results in additional overhead on file servers, a better solution might be to secure these servers physically in locked rooms.

On a system where you decide that encryption should be implemented, the following folders could be encrypted:

My Documents and any other folders where the user regularly stores work
Temp folders (such as \Winnt\Temp ), so that any temporary files that are created but not deleted by applications are encrypted

You generally should encrypt folders instead of files, since some applications create temporary files in odd locations that may not be encrypted.

Recovery Policy

By default, when an administrator logs on to the domain for the first time, a recovery policy is created to enable the administrator to perform the recovery of encrypted data during disaster recovery. Otherwise, encrypted data restored from backup media would not be decryptable if the users' private keys and the encryption certificates associated with the files happened to be lost when the disaster occurred. The recovery policy creates a special encryption certificate and private key that the recovery agent can use to decrypt files that were created and encrypted by domain users. As preparation for disaster recovery, the recovery agent should use the Export command in the Certificates console to make a copy of the recovery certificate and private key on a floppy disk and keep this in a safe location. After restoring the crashed system, this certificate and key can then be imported into the personal certificate store of the recovery agent, enabling the agent to decrypt the restored files.