Section 2.4: Configuring File Systems
Windows Server 2003 supports the FAT, FAT32 and NTFS file systems. A computer can contain a combination of file systems but each file system must be located on a separate partition or volume.
Note: MS-DOS, Windows 95, Windows 98 and Windows Millennium Edition cannot access data on NTFS formatted disks.
The NTFS file system used by Windows 2000 and Windows Server 2003 is version 5. This version of NTFS has features that were not available in NTFS version 4 used by Windows NT 4.0. Windows NT 4.0 cannot therefore fully support all the features of NTFS version 5. NTFS version 5 offers a number of benefits that include:
• File compression
• File and folder level security
• File encryption using Encrypting File System (EFS)
• Disk quotas
• NTFS permissions r "HDD"
Note: You can convert a disk from the FAT and FAT32 file to NTFS at any time without data loss by using the convert command from a command prompt and using the fs:/ntfs switch. When you format the data on the disk is lost.
2.4.1: Encrypting File System (EFS)
Windows Server 2003 supports Encrypting File System (EFS) which allows users to encrypt their files and folders. In Windows Server 2003, users can encrypt files and folders on the local computer and across the network. In addition, users can also encrypt offline files. However, EFS is only supported on NTFS volumes.
When a user encrypts a file, only that user will be able to use the file. They can use the encrypted file without having to decrypt the file first. EFS can be implemented from Windows Explorer or from the command prompt using the Cipher command. The syntax for the cipher command is:
cipher [/e | /d] [/s:folder_name] [/a] [/i] [/f] [/q] [/h] [/k] [file_name [...]]
For a list of Cipher command switches see Table 2.1.
• EFS is only supported on NTFS version 5
• Compressed files cannot be encrypted using EFS
• System files cannot be encrypted
• Encrypted files cannot be shared
or volumes that are not formatted with
have the necessary access permissions enabled on the network computer.
• Encrypted flies or folders that are moved or copied to partitions the NTFS file system will become decrypted
• Files and folders on network computers can be encrypted if you to the network computer's NTFS volume and if file encryption is
Table 2.1: Command-line Switches for the Cipher Command
| Switch | Description |
|---|---|
| /e | Encrypts the specified folders and marks them so that files that are added later will be encrypted. |
| /d | Decrypts the specified folders. Files that are added to the folder will no longer be encrypted. |
| /s:folder | Performs the specified operation on folders in the given folder and all subfolders |
| /a | Performs the specified operation on files and folders. |
| /i | Continues performing the specified operation even after errors have occurred. |
| /f | Forces the encryption operation on all specified files, even those that are already encrypted. |
| /q | Reports only the most essential information. |
| /h | Displays files with the hidden or system attributes. |
| /k | Creates a new file encryption key. |
| file_name | Specifies a pattern, file, or folder. |
Windows 2003 also supports encryption of offline files. This enables users to use offline file storage while retaining the ability to protect their files with encryption.
2.4.1.1: Encrypting Files Across the Network
File encryption and decryption requires the presence of EFS keys on the local computer where the files reside. When a user encrypts a file on a local desktop or laptop, EFS works with the Microsoft Crypto Provider to create EFS keys and to place those keys in the user's local profile. If the user attempts to encrypt a file across the network, EFS running at the server looks for the user's local profile at the server. EFS cannot access keys at a user's desktop because it does not have a security context anywhere except at the machine where it's running. This means that the server must have a local profile for the user that contains both the EFS public key to encrypt the file and the EFS private key to open the encrypted file. To build the local private key, the Protected Storage service at the server must have a copy of the user's password hash so it can encrypt the Master key that protects the user's private key. It obtains this information by "user impersonation". This requires obtaining a Kerberos session ticket on behalf of the user to present when requesting the user's security credentials from a domain controller. A server has two ways of obtaining this session ticket:
• It can ask the Kerberos client at the user's desktop to obtain the session ticket and pass it over to the server. Such a ticket would be marked as forwardable; or
• The server can ask the Kerberos client for a ticket-granting ticket (TGT) that it can use to obtain its own session tickets as if the server were the user. The TGT would be flagged as proxiable.
However, before a server submitting forwardable and proxiable Kerberos tickets and TGTs to create encrypted files for network users, it must be Trusted For Delegation. This option is configured in the server's Computer object in Active Directory.
2.4.1.2: Encrypted File Recovery
If a user leaves the company or goes on vacation, the administrator can access the user's encrypted files by resetting the user's password in Active Directory and then logging on as the user. Windows Server 2003 will build a new encryption key with the new password hash to re-encrypt the private keys. Alternatively, you can open the user's encrypted files using the credentials of the Data Recovery Agent (DRA). The default DRA is the domain Administrator account.
2.4.2: Volume Mounting
The Disk Management snap-in can be used to mount local drives to an empty folder on an NTFS volume. This empty folder becomes the mount point. When a physical disk is mounted to a folder, it is assigned a drive path rather than a drive letter. The Administrator can identify and manage volume mount points by using the mountvol.exe command-line tool. To mount a drive:
• Open MY COMPUTER
• Open CONTROL PANEL
• Open ADMINISTRATIVE TOOLS
• Click on the COMPUTER MANAGEMENT
• Expand STORAGE
• Open DISK MANAGEMENT
• Right-click the partition or volume you want to mount
• Click CHANGE DRIVE LETTER AND PATH
• Click ADD
• Type the path to the empty folder on which you want to mount the partition or volume
2.4.3: File Compression
Windows Server 2003 supports file and folder level compression. Compressed files can be read and written to by any Windows-based or MS-DOS-based application without first having to be uncompressed by another program. When you access a file via a Windows-based or MS-DOS-based application, NTFS automatically uncompresses the file. When you save or close the file again, NTFS compresses it again. Therefore NTFS allocates disk space based on the uncompressed file size and not on the compressed file size.
2.4.3.1: Copying and Moving Compressed Files and Folders
When copying a file within an NTFS volume, the file inherits the compression state of the target folder.
• When moving a file or folder within an NTFS volume, the file or folder retains its original compression state.
• When copying a file or folder to another NTFS volume, the file or folder inherits the compression state of the target folder.
• When moving a file or folder to another NTFS volume, the file or folder inherits the compression state of the target folder. Because Windows Server 2003 treats a move as a copy and then a delete, the files inherit the compression state of the target folder.
• When moving or copying a file or folder to a FAT volume, Windows Server 2003 automatically uncompresses the file or folder. This is because Windows Server 2003 only supports file and folder compression on NTFS volumes.
• When moving or copying a compressed file or folder to a floppy disk, Windows Server 2003 automatically uncompresses the file or folder, as floppy disks are formatted with the FAT file system. Floppy disks cannot support the NTFS file system.