Exam 70-124: Objective 5.4: User Operations
|
|
The Encrypting File System adds more security to the Windows operating system than ever. This built-in encryption allows any user to protect sensitive data against unauthorized use. This much-needed security feature can be used immediately after operating system installation. The only requirement for EFS is an NTFS partition. No new administrative tasks involving installation and configuration of EFS need to be completed in order for it to work. The user operations that use file encryption are:
-
Encrypting a file or folder
-
Accessing an encrypted file
-
Copying an encrypted file
-
Preventing files from being encrypted on a server
-
Moving or renaming an encrypted file
-
Sharing an encrypted file (in Windows XP/.NET)
-
Decrypting a file
-
Using the Cipher Utility (in Windows 2000)
-
Encrypting a directory
-
Employing recovery operations
Encrypting a File or Folder
EFS uses a public key pair and a secret key in the encryption and decryption process. When a user attempts to encrypt a file, the EFS must first determine whether a key pair exists for the user or whether one must be created. If a key pair needs to be created, the generation will occur on a domain controller or on the local computer, depending on the environment, unnoticed by the user.
Other tasks completed by EFS include creating the actual ciphertext file, ciphering the FEK, creating a log, creating a backup file, and deleting the log and backup file used in the encryption process. A great deal of activity takes place in the background, but the user is unaware of it.
In order to manage encrypted file resources, you must first identify the data that needs to be protected and then use one of two methods to let the operating system know where EFS should be implemented. Your choices are:
-
The Windows Explorer interface
-
The Cipher command-line utility
Encrypting a File or Folder on the Local Computer
An owner can encrypt any folder or file as long as it is stored on an NTFS partition. The easiest way to maintain encrypted files is to first create an encrypted folder in which you plan to store all sensitive data. Marking a directory for encryption has no effect on the listing of the files in the directory when you use the Explorer interface.
You can easily encrypt a folder using the graphical interface. When a folder is created, go to the Advanced Attributes and check Encrypt contents to secure data, as shown in Figure 5.4. This sets the encryption bit on the folder.
Figure 5.4: Enabling Encryption
After this bit is set, the directory is marked for encryption. Any newly created file or subdirectory stored in the marked directory from this point on will be encrypted automatically. This makes it easy to encrypt files simply by creating them in or moving them to this folder.
If the directory is marked for encryption and it already contains files and subdirectories, you will receive a dialog box (as shown in Figure 5.5) that allows you to specify how far down in the directory structure encryption should be set.
Figure 5.5: Confirming Attribute Changes
You will see the message box shown in Figure 5.6 while encryption takes place. This message box shows the estimated time required to complete the encryption process.
Figure 5.6: Applying Attributes
| Test Day Tip | If you create an encrypted folder and another user creates a document in that folder, it will be encrypted using the creator or owner's private key. This means you will not be able to access the document unless (in Windows XP/.NET) the creator/owner has enabled sharing of the encrypted file and added your account to the user access list. |
Compressed or system files cannot be encrypted by EFS. Note that EFS encryption is not available until the boot process is completed, which is efficient, considering the complexity of the encryption/decryption process. For this reason, you cannot encrypt the files that are used in the boot process.
The EFS process will fail if you try to encrypt a file that has the system bit set. An attempt to encrypt a system file—that is, a file in which the system attribute is set—produces the message, "An error occurred applying attributes to the file. Access is denied." EFS also will fail if you try to encrypt a file on the root. Encryption can be implemented at both the directory level and the file level. To encrypt a single file on an NTFS partition, follow the steps in Exercise 5.01.
Exercise 5.01: Encrypting Files with EFS Encryption
 |
-
In Windows Explorer, select the file you want to encrypt.
-
Right-click to bring up the Context menu, and then select Properties.
-
Click Advanced on the General tab.
-
In the Advanced Attributes dialog box, select the check box Encrypt contents to secure data, then click OK.
-
On the General tab, click OK or Apply to mark the file as encrypted.
|
Later in this chapter, in the section "Using the Cipher Utility in Windows 2000," we discuss how to use the command-line interface to encrypt and decrypt files and directories.
Encrypting a File or Folder on a Remote Computer
You can encrypt a file or folder on a remote computer that is running NTFS. If the computer is in a domain, however, remote encryption must be enabled by making the remote computer trusted for delegation. Follow the steps in Exercise 5.02 to encrypt a file on a remote machine.
Exercise 5.02: Encrypting Remote Files with EFS Encryption
|
-
Connect to the remote computer through a mapped network drive.
-
Select the file or folder you want to encrypt and right-click it.
-
Click Properties in the right context menu.
-
Select the General tab, then click the Advanced button.
-
Check the Encrypt contents to secure data check box.
-
Click OK.
|
Accessing an Encrypted File
Accessing an encrypted file involves no special action by a user. There is no need to explicitly decrypt a file before using it. When the operating system verifies that a user has an acceptable private key, the system automatically decrypts the file so the user can read and/or modify it. The stored file is still encrypted on the disk. When the bytes are moved from the disk into the user's working set, the bytes go through the decryption process. When the user saves the file back to the disk, the file is encrypted again. The encryption and decryption processes are transparent to users.
| Test Day Tip | If an unauthorized user attempts to open an encrypted file, he or she will receive a message stating that access is denied. An unauthorized user also will not be able to copy or move an encrypted file to a different location on the disk. These events can also indicate that a problem has occurred with an authorized user's certificate, such as certificate expiration or the inability to locate the certificate (logged on locally instead of to the domain or vice versa). |
Backing up your encrypted files is important, as with any critical data. In the Windows 2000 and XP/.NET operating systems, just as in earlier versions of Windows NT, a file owner can control access to a file through the use of access permissions. If owners want to remove all access except their own, they can do so by setting NTFS permissions. The fact that only the owner has permission to access a file does not prevent system administrators from backing up the file on a regular basis. Furthermore, any user who belongs to the Backup Operators group has the ability to execute the Backup Utility and back up the file. The Backup Operators group is tied to the Backup Files and Directories user right, which, when it runs the Backup Utility, allows the file to be opened and read. The Backup Files and Directories right contains code that will bypass the normal access control list (ACL).
EFS also provides backup utilities with the ability to back up and restore files in ciphertext format. The backup process will not be able to decrypt the sensitive information nor will it have to decrypt and encrypt during the backing-up operation. The ADVAPI32.DLL library will provide the EFS APIs necessary for access to the encrypted data.
When Windows Backup backs up encrypted files, no special configuration is needed. Members of the Backup Operators group will not have a private key to decrypt the files, so there is no risk that they can read the sensitive data that you have encrypted. Encrypted data is backed up during a backup operation as it exists on disk. The Backup Utility reads and records the ciphertext file without decryption.
Copying an Encrypted File
The copy command has been extended in Windows 2000 and later operating systems with two new switches to allow you to export or import an encrypted file. When an encrypted file is copied, the encryption attribute always takes precedence. If either the file you want to copy or the destination directory is encrypted, the resulting new file will be encrypted. This differs from copying files in other circumstances, in which a file always inherits the attributes of the target parent directory. Table 5.2 lists various copying situations and the status of the resulting created files.
| Starting Encryption | Copied to | New File Status |
|---|---|---|
| Both the directory and file are encrypted | A directory that is not encrypted | Encrypted |
| Both the directory and file are encrypted | A directory that is encrypted | Encrypted |
| The directory is encrypted, but the file is not encrypted | A directory that is encrypted | Encrypted |
| The directory encrypted, but the file is not encrypted | A directory that is not encrypted | Unencrypted |
| Both the directory and file are unencrypted | A directory that is encrypted | Encrypted |
| Both the directory and file are unencrypted | A directory that is unencrypted | Unencrypted |
|
Encryption Does Not Apply to Diskettes
Be aware that if you copy a file that is encrypted on your hard disk to a medium such as a diskette, which does not support NTFS (or other media formatted in FAT or CDFS, such as a FAT partition on your hard disk or a CD-ROM), the encryption attribute will be lost and the file will be in an unencrypted state on the FAT-formatted media. This can pose a serious security risk. There is no warning message that the encryption will be lost when you copy the file. The file is decrypted to make the copy, but this is completely transparent to users.
This can be a problem for users who travel with removable media containing sensitive information. An attacker doesn't even have to brute-force his or her way into a stolen portable computer if they have managed to acquire the diskette or CD that was with it. There are third-party solutions to this problem, such as Pretty Good Privacy (PGP), which can be enacted on files or across an entire disk. Check out PGP at www.pgp.com for more information.
|
If you copy an encrypted file to a different computer, you'll need to export your EFS certificate and private key to the other computer in order to be able to open the file on the other computer.
Preventing Files from Being Encrypted on a Server
In some circumstances, administrators do not want users to be able to store encrypted files on a file server. A Registry edit can be done on the server to prevent files on the server from being encrypted with EFS. This edit can also prevent encrypted files on a user's local hard disk from being copied to the server in an encrypted state. If a user copies encrypted files to a server that's configured not to store encrypted files, the files will be stored as unencrypted files.
To edit the Registry so that files can't be encrypted on a server, perform the steps of Exercise 5.03.
Exercise 5.03: Preventing EFS Use on a Server
|
-
On the Start menu, click Run.
-
In the Run box, type regedit. Click OK.
-
Navigate to the following Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
-
Expand this key and locate the NtfsEncryptionService value.
-
Delete this value.
|
You need to reboot the server before the change takes effect. After you complete the Registry edit, users can only copy their encrypted files to the server in an unencrypted state.
| Note | Microsoft recommends that you always back up the Registry before making changes to it. See article Q256986 in the Microsoft Knowledge Base for information about how to back up, restore, and edit the Registry. Remember that Registry changes take place immediately; that is, there is no way to undo a change after you've made it (although many changes won't actually take effect until you reboot because that's when the Registry values are loaded by the operating system and/or applications). |
Moving or Renaming an Encrypted File
Renaming an encrypted file is no different from renaming a compressed file. The operating system changes the filename but makes no modification to any other fields in the file's header. The fact that the file is encrypted sets an encryption bit in the file's header. Renaming changes the file's name but does not touch the encryption attribute.
When an encrypted file is moved, it retains its encrypted status, regardless of the destination folder if on the same Windows 2000 system and an NTFS partition. When an encrypted file is moved on the same partition, there is no difference to the file other than the resident directory of the file. This is because only the pointer to the file is changed; the file and its attributes are completely untouched.
When the encrypted file is moved to a different NTFS partition, the file is first decrypted and then encrypted before being stored at the new location. When a file or folder is moved to a partition that is not formatted in NTFS, the file or folder loses all NTFS attributes, including the encryption attribute, and is decrypted.
Commonly, users get new workstations due to hardware upgrades, change physical locations in a company, and so forth. In these cases, users' local files are often transferred to new computers. If encrypted files or folders are moved to a new computer, you must export the user's keys and EFS certificate from the old computer and import them to the new computer; otherwise, the user won't be able to access the encrypted files.
Sharing an Encrypted File in Windows XP/.NET
Users of EFS in Windows 2000 found that the feature had a major drawback in some circumstances—specifically, only the user who encrypted a file could access it. It was not possible to allow others to access an encrypted file without the original user having to decrypt it and share it with others in a decrypted state. A major improvement to EFS in Windows XP/.NET is the ability to share access to encrypted files.
In Windows XP/.NET, the original user who encrypts a file can add other user accounts to the list of those who can access the file in its encrypted state. This makes for a higher level of security. Additionally, members of the Administrators group can also add users to the encrypted file.
To allow others to access an encrypted file, follow the steps of Exercise 5.04.
Exercise 5.04: Adding Multiple Users to an Encrypted File in Windows XP
|
-
In Windows Explorer, right-click the encrypted file that you want to share.
-
Click Properties, select the General tab, and click Advanced.
-
Click Details, then click the Add button.
-
From the list of users, select the user account with which you want to share access. Click OK.
-
Add additional users if you want.
-
Click OK to close each dialog box.
|
Of course, any users that you add to the encrypted file's access list must also have the proper NTFS permissions required to access the file. Encryption and decryption occur transparently, as though the added user were the owner. In addition, remember that you cannot perform this action (adding users) to a folder, only to a file or files.
Decrypting a File
Users never need to explicitly request that a file be decrypted as long as only that user needs to access the file (in Windows 2000) or as long as other users who are to have access have been added to the file's properties (in Windows XP/.NET). That does not mean that the decryption process will never occur. The decryption process does occur in two instances:
-
EFS goes through the decryption process whenever the file is accessed, but this processing is transparent to the user.
-
Decryption occurs when a file's owner decides that the added security method is no longer needed and chooses to set the file's attributes to unencrypted.
When a user wants to read and/or modify the contents of an encrypted file, the operating system decrypts the file as it is moved from the hard drive into physical memory. The file's decryption for use is completely transparent to the user, and the ciphered or encrypted form of the file is still stored on the hard drive. The user does not have to decrypt the file manually before each use. The user works with encrypted files just as he or she works with normal, unencrypted files.
EFS must have the user's private key in order to decrypt the file. If the user does not have a valid private key to the file, the system message "Access is denied" appears, just as when the user does not have the proper permission.
Decryption also occurs if and when a user decides that the encrypted data is no longer sensitive and therefore does not have to be encrypted. The user can then implement the decryption process at the file or directory level. The user can use the Windows Explorer interface to clear the encryption bit, or the user can use the Cipher Utility and execute the appropriate command. When an individual file is selected for decryption, only that file is affected. When the user requests decryption at the directory level, a dialog box appears asking whether the user wants to decrypt all files and subdirectories found within this directory, as shown in Figure 5.7.
Figure 5.7: The Confirm Attribute Changes Dialog Box
The decryption process at the directory level is exactly like the process for changing permissions at the directory level. To decrypt a file, perform Exercise 5.05.
Exercise 5.05: Decrypting a File
|
-
Using Explorer, select the encrypted file that you want to now be stored as an unencrypted file.
-
Right-click to bring up the Context menu, and select Properties.
-
Click Advanced on the General tab.
-
In the Advanced Attributes dialog box, clear the check box to Encrypt contents to secure data.
-
Click OK.
-
On the General tab, click OK or Apply to mark the file as unencrypted.
|
Using the Cipher Utility in Windows 2000
Windows 2000 allows users to use file encryption from the command prompt. This can be faster than using the graphical interface when a large number of files are to be encrypted. The command-line utility also provides added functionality (such as the ability to view at one time the encryption status of all files or subdirectories in a specified directory, the ability to force encryption on files that are already encrypted, and so on).
The general format of the Cipher Utility is:
cipher [ /e ] [ /d ] [ /s [dir]] [ /a ] [ /i ] [ /f ] [ /q ] [filename]
When the cipher command is executed with no switches or filename, the result is a display of the encryption status of the current directory and any files in the directory. This is useful because users might not readily know which files have been encrypted, since the process during access is transparent. (Another way to determine encryption status is to check the properties of each individual file, but that can be cumbersome.) Table 5.3 identifies each switch of the cipher command.
| Switch | Function |
|---|---|
| /e | Encrypts the specified files. The directory is marked for encryption, so any files or subdirectories created and placed here will be encrypted. |
| /d | Decrypts the specified files. The directory will be cleared of the encryption attribute so that files added here will not be encrypted. |
| /a | Performs the specified operation for files and directories. |
| /s :<dir> | Performs the specified operation on the files in the specified directory and on all subdirectories. |
| /i | Continues to perform the cipher command, even if errors occur, thereby overriding the default behavior in which the cipher command stops if an error occurs. |
| /f | Forces encryption to occur on all specified files, even those that are already encrypted, thereby overriding the default behavior of not encrypting already encrypted files. |
| /q | Reports only the most essential information. |
The filename can be replaced with a filename or directory. The filename specification allows for wildcard use, thus allowing multiple listings to be affected with a single command execution.
| Exam Warning | Be sure you know and understand the function of each of the available switches for the cipher command. You should expect to be asked at least one question, which could be a bit tricky in its wording, about using cipher to work with EFS encrypted files. |
Figure 5.8 shows a cipher command that was executed with no switches at the root level of the directory structure. Every existing directory is listed, and you can see whether the directory is marked for encryption. The E attribute indicates encryption, so, in this example, you can see that Security Files is encrypted. U indicates that a directory is unencrypted.
Figure 5.8: Executing the Cipher Command with No Switches
Figure 5.9 shows the result of executing the cipher command at the directory level. The directory is marked for encryption, and any new objects stored there will be encrypted. All files and subdirectories are shown, along with their current encryption status. As you might expect, all files in this directory are encrypted. However, a directory could be marked for encryption that contains unencrypted files, as discussed in the next section.
Figure 5.9: Executing the Cipher Command at the Directory Level
Encrypting a Directory
As mentioned earlier in this chapter, EFS allows encryption to be set at the directory and file levels. When a directory is selected for encryption, what really happens is that any new object placed in the directory—including files and subdirectories—is encrypted. Any current existing file and subdirectory will not be encrypted unless the owner manually sets the encryption bit on the existing object. The best practice is to create a directory, mark it for encryption, and then store all sensitive data in that directory when you work with EFS.
When you modify a directory's attribute to include encryption, the directory itself is not technically encrypted; rather, the directory is marked for encryption. This encryption mark controls all the new objects becoming encrypted.
You can also explicitly unencrypt a file in an encrypted directory by unchecking the encryption attribute in its properties or using the cipher command.
Employing Recovery Operations
Earlier in the chapter, we mentioned the Encrypted Data Recovery Policy (EDRP). EDRP is part of the local security policy in a workgroup environment or part of the domain security policy for Windows domains. The Security Subsystem in user mode is responsible for enforcing this policy. Users can use file encryption offline, and the Security Subsystem is responsible for caching the EFS policy, much the way logon information is cached on the local machine.
The recovery policy must first be set up by the system administrator. The operating system contains a Recovery Agent Wizard, in which recovery agents are assigned along with their corresponding key pairs. The Microsoft Base Cryptographic Provider is used to create a data recovery file for each recovery agent.
|
Watch the Recovery Agents!
Once you start to think about the power of the data recovery agent in Windows 2000, you soon start to realize the importance of planning a good data recovery policy for your organization. Having too many or too few data recovery agents can lead to troubles you would do well to avoid. The worst-case scenario revolves around having more data recovery agents than you need. Let's examine that situation.
Assume that your organization employs EFS on a rather large scale, requiring all users to encrypt all documents. Furthermore, all documents are stored on central file servers that have been delegated for trust. This makes performing backups easier, because all critical files are located on a few centralized file servers. You have three shifts manning your network operations center (NOC) Monday through Friday, with an on-call administrator for the weekends. Since your organization relies so strongly on EFS, you have three data recovery agents per shift, for a total of nine data recovery agents, plus the built-in data recovery agent, which has never been removed. Your organization believes strongly in the diligent use of EFS, but you haven't been able to sell them on strong password requirements or the need for network traffic protection (such as IPSec).
Over the weekend, a member of the cleaning crew has clandestinely planted a rogue wireless access point on your network, connected directly to the network backbone. Your organization does not currently use wireless networking, and thus the existence of the access point goes unnoticed, since it has been cleverly hidden in an out-of-the-way place.
Now the attacker sits in your parking lot (or even further away, depending on the power output of the access point and the gain on his receiving antenna) and sniffs your wired network without any notice by you or your other administrators. Three days later, the attacker manages to capture an administrative username and password from sniffing the network. It just so happens that this administrator has data recovery capability. Now, not only can this attacker gain access to your network (unnoticed most likely until it is too late), he or she can freely decrypt files located on your network file servers and inspect their contents. What's more, the attacker has also been intercepting all EFS-encrypted documents traveling to and from the server, because they have been traveling across the network in cleartext!
A month later, your largest competitor releases a product almost identical to the one you had slated for the following week and dominates the market, shutting your product out of contention for consumer dollars. Coincidence or bad planning?
|
The default domain recovery policy is configured so that the domain administrator account is the only recovery agent. We recommend that you change this configuration, for two reasons:
-
No one should be logging on with the Administrator account (it should be renamed and not in use).
-
You need more than one recovery agent for fault-tolerance purposes.
The next two exercises demonstrate the process of adding recovery agents in Windows 2000. Exercise 5.06 walks you through the process of adding a recovery agent for an account that does not already have an EFS recovery certificate. Exercise 5.07 walks you through the process of adding a recovery agent for an account that has an EFS recovery certificate.
Exercise 5.06: Creating a New EFS Recovery Agent
|
-
Open Active Directory Users and Computers (select Start | Programs | Administrative Tools | Active Directory Users and Computers), as shown in Figure 5.10.
Figure 5.10: Active Directory Users and Computers -
Right-click your domain, and choose Properties. You will see the window shown in Figure 5.11.
Figure 5.11: The Group Policy Tab of a Domain's Properties -
Click the Group Policy tab.
-
Select Default Domain Policy, and click Edit. You will see the window shown in Figure 5.12.
Figure 5.12: Editing the Group Policy Object -
Expand Computer Configuration | Windows Settings | Security Settings | Public Key Policies.
-
Right-click Encrypted Data Recovery Agents, and choose Create. This step starts the wizard shown in Figure 5.13.
Figure 5.13: Welcome to the Certificate Request Wizard -
Click Next to continue the wizard.
-
Figure 5.14 shows the Certificate Template window. This is where you select the type of certificate that you want. Select EFS Recovery Agent, and click Next. You will see the screen shown in Figure 5.15.
Figure 5.14: The Certificate Template Window
Figure 5.15: The Description Window -
Enter a name and description for the certificate, and click Next.
-
The Completing the Certificate Request Wizard window displays (see Figure 5.16). Click Finish to complete the request process and start installing the new certificate.
Figure 5.16: Completing the Certificate Request Wizard -
After requesting the certificate and completing the wizard, you will see the message box shown in Figure 5.17. Click View Certificate to look at the new certificate before you install it.
Figure 5.17: Viewing or Installing a Certificate -
Figure 5.18 shows the certificate. Verify that it is for File Recovery. Once the user account has a recovery certificate, that user can be added as a recovery agent. Note that the certification authority must be configured to issue recovery agent certificates, and the user must have permission to request the certificate.
Figure 5.18: Viewing an EFS Recovery Certificate -
Click OK to return to the window shown earlier in Figure 5.17.
-
Click Install Certificate. You'll see the message box shown in Figure 5.19, indicating that the certificate was installed successfully.
Figure 5.19: The Certificate Request Successful Message Box
|
Once you've created a new recovery agent certificate, you can complete the process to link the certificate to the user account that you have designated to be the recovery agent by performing the steps outlined in Exercise 5.07. This user should normally be a trusted administrator. Additionally, you will not want to have too many recovery agents—perhaps two per location or site.
Exercise 5.07: Adding an EFS Recovery Agent
|
-
Open Active Directory Users and Computers (select Start | Programs | Administrative Tools | Active Directory Users and Computers), as shown earlier in Figure 5.10.
-
Right-click your domain, and choose Properties, as shown earlier in Figure 5.11.
-
Click the Group Policy tab.
-
Select Default Domain Policy, and click Edit to open the Group Policy Editor, as shown earlier in Figure 5.12.
-
Expand Computer Configuration | Windows Settings | Security Settings | Public Key Policies.
-
Right-click Encrypted Data Recovery Agents, and choose Add. The Add Recovery Agent Wizard shown in Figure 5.20 starts.
Figure 5.20: Welcome to the Add Recovery Agent Wizard -
Click Next to continue the wizard and open the Select Recovery Agents window shown in Figure 5.21.
Figure 5.21: The Select Recovery Agents Window -
In the Select Recovery Agents window, click Browse Directory to search Active Directory for recovery agents (see Figure 5.22). Optionally, you could click Browse Folders to search for the certificate of your recovery agent.
Figure 5.22: Finding Users to Be Recovery Agents -
After choosing Browse Directory, you need to select the users you want to designate as recovery agents. Type the name of the user, and choose Find Now. Alternatively, you can click Find Now without typing a name to see all users, then select the user from the list and click OK to return to the Select Recovery Agents window shown in Figure 5.21.
-
Click Next to continue. You will see the Completing the Add Recovery Agent Wizard window shown in Figure 5.23.
Figure 5.23: Completing the Add Recovery Agent Wizard -
Click Finish to complete the wizard.
|
The recommended steps in the recovery of an encrypted file that an owner cannot manipulate are performed by a recovery agent as follows:
-
Assuming that you are the person who will be doing the recovery—that is, you're the recovery agent—use a backup utility to restore a copy of the user's ciphertext file on the computer that has the recovery certificates.
-
Using Explorer, display the encrypted file's properties.
-
On the General tab, click Advanced.
-
Clear the Encrypt contents to secure date check box, which will use your private key to decrypt the file. The decrypted file should now be backed up and restored to the user.
Another method of recovery is to export the recovery agent's recovery certificate to a disk and then import the disk's contents onto the machine that has the encrypted file.
The Windows 2000 operating system also provides a command-line utility, named EfsRecvr, which can be used to recover an encrypted file. If you use the EfsRecvr utility, the same steps should be applied in order to back up the file and restore it on the computer that contains the recovery keys.
The EfsRecvr command-line utility uses this general format:
EFSRECVR [ /S [:dir] ] [ /I ] [ /Q ] [ filename […] ]
Table 5.4 summarizes each of the items in the EfsRecvr command line.
| Item | Function |
|---|---|
| /S | Recovers the files in the given directory and all subdirectories. The default directory is the current directory. |
| /I | The recovery process will continue, even if an error occurs. The default behavior is to immediately stop the recovery process if an error occurs. |
| /Q | Limits the reporting to only essential information needed to load the appropriate keys. |
| Filename | Specifies a file, directory, or pattern. |
| Exam Warning | Ensure that you know and understand the different ways that you can perform EFS recovery operations as detailed in this chapter. They are, for your review:
|
|
|
EAN: 2147483647
Pages: 162