Deciding What to Audit
Avoid auditing if you don't need it. Security audits, like tax audits, can be time-consuming and can waste a lot of resources. When you enable auditing, the system must write an event record to the Security log for each audit check the system performs. This activity can degrade your computer's performance, so you'll want to be selective about which events you choose to monitor. In addition, indiscriminate auditing adds to the log many events that might be of little value to you, thereby making the real security issues more difficult to find. And because the Security log has a fixed size, filling it with unimportant events could displace other, more significant events.
Here are some suggestions for what you should consider auditing:
Audit failed logon attempts, which might indicate that someone is trying to log on with various invalid passwords.
If you're concerned about someone using a stolen password to log on, audit successful logon events.
To detect use of sensitive files (such as a payroll data file, for example) by unauthorized users, audit successful read and write access as well as failed attempts to use the file by suspected users or groups.
If you use your computer as a Web server, you'll want to know whether an attacker has defaced your Web pages. By auditing write access to the files that make up the Web pages, you'll know whether your site has been vandalized.
Logging printer failures quickly identifies people who attempt to access a printer for which they don't have permission. You might also want to log successes (at least for users or groups suspected of abusing the privilege) to determine, for example, who's using all the expensive color ink cartridges.
To detect virus activity, audit successful write access to program files (files with .exe, .com, and .dll file name extensions).
If you're concerned that someone is misusing administrative privileges, audit successful incidents of privilege use, account management, policy changes, and system events.
Troubleshooting
--------------------------------------------------------------------------------
No security event is recorded for some logon failures.
If you audit account logon failures, you might discover that certain failed logon attempts don't appear in the Security log. In particular, if an account is locked out because of too many incorrect password entries, the user's next attempt should generate an event with ID 642 and the description "account locked out." Although this works as expected with domain-based accounts, failed logon attempts using a locked-out local user account don't generate the error. This is a bug in Windows 2000, and a patch is available. For details, see Microsoft Knowledge Base article Q314786.
mercredi 30 janvier 2008
Configuring Auditing of Access to Files, Printers, and Registry Keys
Configuring Auditing of Access to Files, Printers, and Registry Keys
If you want to audit use or attempted use of certain files, folders, printers, registry keys, or other objects, you must select Success, Failure, or both options in the Audit Object Access policy, as described in the preceding section. Then you must set auditing options for the particular objects you want to monitor, as described in the following paragraphs. (In general, it's best to select both Success and Failure in the Audit Object Access policy, and then be more selective when you configure auditing options for each object.)
NOTE
--------------------------------------------------------------------------------
Because you can't make Audit Object Access policy settings in Windows XP Home Edition, you won't be able to audit access to files, printers, and other objects. Even if you know the trick to bypass Simple File Sharing (boot into Safe Mode), which would allow you to make audit settings for an object, those settings have no effect without the high-level policy in place.
Windows can audit a variety of events and can audit different events for different users. You must be logged on as a member of the Administrators group (or the Manage Auditing And Security Log right must have been assigned to your logon account) to set up auditing of objects.
NOTE
--------------------------------------------------------------------------------
If you want to audit access to files or folders, those objects must be stored on an NTFS volume; FAT volumes do not support auditing.
Use the Security tab in the properties dialog box for a file, folder, printer, or registry key to display the audit settings for that object. You can specify the users and groups whose access to the selected object you want to audit; and for each user and group, you can specify which types of access should generate entries in the Security log. You should audit the minimum number of accesses necessary to accomplish your logging goal. For instance, if you want to audit changes to permissions, the only access you need to audit is Write Permissions.
To set up auditing for object access, follow these steps:
If you haven't done so already, visit Local Security Settings to enable auditing. Be sure to set the Audit Object Access policy to track both success and failure. (See the preceding section, Enabling Security Auditing.)
If you use Windows XP Professional and your computer is not a member of a domain, choose Tools, Folder Options in Windows Explorer. Click the View tab and then clear the Use Simple File Sharing (Recommended) check box. Click OK. Disabling Simple File Sharing allows the Security tab to appear when you look at the properties dialog box for a file, folder, or printer. (You can skip this step if you're configuring auditing for a registry key.)
NOTE
--------------------------------------------------------------------------------
After you make the appropriate audit settings for various objects (as described in the following steps), you can restore Simple File Sharing by returning to Folder Options and selecting the same check box. Although the Security tab will no longer be visible in the properties dialog box for files, folders, and printers, the audit settings you have made remain in effect.
Display the Security tab for the object, as follows:
For a file or folder, right-click the object in Windows Explorer and choose Properties. In the properties dialog box, click the Security tab.
For a printer, right-click the printer in the Printers folder (in Control Panel) and choose Properties. In the properties dialog box, click the Security tab.
For a registry key in Windows XP, right-click the key in Registry Editor (that is, a folder icon in the tree pane—not a registry value in the right pane) and choose Permissions.
For a registry key in Windows 2000, open Regedt32.exe (not Regedit.exe), select the key, and choose Security, Permissions.
Click the Advanced button to open the Advanced Security Settings dialog box (in Windows 2000, the Access Control Settings dialog box).
Click the Auditing tab. For each object, you can specify different audit settings for different users.
Click Add to add a new user or group, or select an existing user or group and then click Edit to change its audit settings.
If you click Add, the Select User Or Group dialog box appears. You enter the names of user accounts or security groups the same way you do on the Security tab. (For details, see Setting NTFS Permissions Through Windows Explorer.) Click OK.
In the Auditing Entry dialog box, select the types of access you want to audit for the selected user or group.
The types of access you can audit for success or failure are the same types of access for which you can set permissions; specifically, the list of auditing permissions matches the object's list of special permissions. Figure 20-2 shows the options for different object types.
For information about special permissions for files and folders, see Basic and Advanced Permissions.
If you select the Successful check box for a specific type of access, Windows generates a Security log record containing (among other information) the date and time of each successful use of the specified file or folder by the specified user or group. Similarly, if you select the Failed check box, Windows generates a Security log record each time the specified user or group unsuccessfully attempts to access the specified file or folder.
Figure 20-2. The types of access you can audit are the same as those for which you can set permissions. For each type of access, you can audit successful accesses, failed attempts, or both.
If you're making audit settings for an object other than a file, select the scope of the objects you want to audit from the Apply Onto list. Click OK.
On the Auditing tab of the Advanced Security Settings dialog box, you can select inheritance options. These options work exactly like (but independent of) the comparable options on the Permissions tab. For more information, see Applying Permissions to Subfolders Through Inheritance.
TIP
--------------------------------------------------------------------------------
Change audit settings for multiple objects in one fell swoop
You can change audit settings for multiple files or folders (but not printers or registry keys) simultaneously. If you select more than one file or folder in Windows Explorer before you click the Security tab in the properties dialog box, the changes you make affect all the selected files or folders. If the existing security settings are not the same for all the items in your selection, a message appears, asking whether you want to reset the audit settings for the entire selection.
If you want to audit use or attempted use of certain files, folders, printers, registry keys, or other objects, you must select Success, Failure, or both options in the Audit Object Access policy, as described in the preceding section. Then you must set auditing options for the particular objects you want to monitor, as described in the following paragraphs. (In general, it's best to select both Success and Failure in the Audit Object Access policy, and then be more selective when you configure auditing options for each object.)
NOTE
--------------------------------------------------------------------------------
Because you can't make Audit Object Access policy settings in Windows XP Home Edition, you won't be able to audit access to files, printers, and other objects. Even if you know the trick to bypass Simple File Sharing (boot into Safe Mode), which would allow you to make audit settings for an object, those settings have no effect without the high-level policy in place.
Windows can audit a variety of events and can audit different events for different users. You must be logged on as a member of the Administrators group (or the Manage Auditing And Security Log right must have been assigned to your logon account) to set up auditing of objects.
NOTE
--------------------------------------------------------------------------------
If you want to audit access to files or folders, those objects must be stored on an NTFS volume; FAT volumes do not support auditing.
Use the Security tab in the properties dialog box for a file, folder, printer, or registry key to display the audit settings for that object. You can specify the users and groups whose access to the selected object you want to audit; and for each user and group, you can specify which types of access should generate entries in the Security log. You should audit the minimum number of accesses necessary to accomplish your logging goal. For instance, if you want to audit changes to permissions, the only access you need to audit is Write Permissions.
To set up auditing for object access, follow these steps:
If you haven't done so already, visit Local Security Settings to enable auditing. Be sure to set the Audit Object Access policy to track both success and failure. (See the preceding section, Enabling Security Auditing.)
If you use Windows XP Professional and your computer is not a member of a domain, choose Tools, Folder Options in Windows Explorer. Click the View tab and then clear the Use Simple File Sharing (Recommended) check box. Click OK. Disabling Simple File Sharing allows the Security tab to appear when you look at the properties dialog box for a file, folder, or printer. (You can skip this step if you're configuring auditing for a registry key.)
NOTE
--------------------------------------------------------------------------------
After you make the appropriate audit settings for various objects (as described in the following steps), you can restore Simple File Sharing by returning to Folder Options and selecting the same check box. Although the Security tab will no longer be visible in the properties dialog box for files, folders, and printers, the audit settings you have made remain in effect.
Display the Security tab for the object, as follows:
For a file or folder, right-click the object in Windows Explorer and choose Properties. In the properties dialog box, click the Security tab.
For a printer, right-click the printer in the Printers folder (in Control Panel) and choose Properties. In the properties dialog box, click the Security tab.
For a registry key in Windows XP, right-click the key in Registry Editor (that is, a folder icon in the tree pane—not a registry value in the right pane) and choose Permissions.
For a registry key in Windows 2000, open Regedt32.exe (not Regedit.exe), select the key, and choose Security, Permissions.
Click the Advanced button to open the Advanced Security Settings dialog box (in Windows 2000, the Access Control Settings dialog box).
Click the Auditing tab. For each object, you can specify different audit settings for different users.
Click Add to add a new user or group, or select an existing user or group and then click Edit to change its audit settings.
If you click Add, the Select User Or Group dialog box appears. You enter the names of user accounts or security groups the same way you do on the Security tab. (For details, see Setting NTFS Permissions Through Windows Explorer.) Click OK.
In the Auditing Entry dialog box, select the types of access you want to audit for the selected user or group.
The types of access you can audit for success or failure are the same types of access for which you can set permissions; specifically, the list of auditing permissions matches the object's list of special permissions. Figure 20-2 shows the options for different object types.
For information about special permissions for files and folders, see Basic and Advanced Permissions.
If you select the Successful check box for a specific type of access, Windows generates a Security log record containing (among other information) the date and time of each successful use of the specified file or folder by the specified user or group. Similarly, if you select the Failed check box, Windows generates a Security log record each time the specified user or group unsuccessfully attempts to access the specified file or folder.
Figure 20-2. The types of access you can audit are the same as those for which you can set permissions. For each type of access, you can audit successful accesses, failed attempts, or both.
If you're making audit settings for an object other than a file, select the scope of the objects you want to audit from the Apply Onto list. Click OK.
On the Auditing tab of the Advanced Security Settings dialog box, you can select inheritance options. These options work exactly like (but independent of) the comparable options on the Permissions tab. For more information, see Applying Permissions to Subfolders Through Inheritance.
TIP
--------------------------------------------------------------------------------
Change audit settings for multiple objects in one fell swoop
You can change audit settings for multiple files or folders (but not printers or registry keys) simultaneously. If you select more than one file or folder in Windows Explorer before you click the Security tab in the properties dialog box, the changes you make affect all the selected files or folders. If the existing security settings are not the same for all the items in your selection, a message appears, asking whether you want to reset the audit settings for the entire selection.
Enabling Security Auditing
Enabling Security Auditing
Unlike the other logs that appear in Event Viewer, the Security log is disabled by default in Windows XP Professional and Windows 2000. No events are written to the Security log until you enable auditing, which you do via Local Security Settings. (In Windows XP Home Edition, security auditing is enabled for certain events. Because Home Edition doesn't include Local Security Settings, you cannot change which events are audited unless you use a tool like Auditpol.exe, which is included in the Windows 2000 Resource Kit.) Even if you set up auditing for files, folders, or printers, as explained later in this chapter, the events you specify aren't recorded unless you also enable auditing by setting a high-level audit policy in Local Security Settings.
NOTE
--------------------------------------------------------------------------------
To enable auditing, you must be logged on with an account that has the Manage Auditing And Security Log privilege. By default, only members of the Administrators group have this privilege. For information about privileges, see Exploring User Rights.
To enable auditing, follow these steps:
In Control Panel, open Administrative Tools, Local Security Policy. (If you use Category view in Windows XP, you'll find Administrative Tools under Performance And Maintenance.) Alternatively, you can type secpol.msc at a command prompt.
In the console tree, select Security Settings\Local Policies\Audit Policy.
Double-click each policy for which you want to enable auditing, and then select Success, Failure, or both. Figure 20-1 shows the properties dialog box for an audit policy.
Figure 20-1. You enable auditing using the Local Security Settings console.
Figure 20-1 also shows the types of activities you can audit. Some, such as account management and policy change, provide an audit trail for administrative changes. Others, such as logon events and object access, help you monitor who is attempting to use your system. Still others, including system events and process tracking, can assist you in locating problems with your system. Table 20-1 provides more details.
Table 20-1. Audit Policies for Security Events
Policy Description
Audit account logon events
Account logon events occur when a user attempts to log on or log off across the network, authenticating to a local user account.
Audit account management
Account management events occur when a user account or security group is created, changed, or deleted; when a user account is renamed, enabled, or disabled; or when a password is set or changed.
Audit directory service access
Directory service access events occur when a user attempts to access an Active Directory object. (If your computer is not part of a Windows domain, these events won't occur.)
Audit logon events
Logon events occur when a user attempts to log on or log off a workstation interactively.
Audit object access
Object access events occur when a user attempts to access a file, folder, printer, registry key, or other object that is set for auditing.
Audit policy change
Policy change events occur when a change is made to user rights assignment policies, audit policies, trust policies, or password policies.
Audit privilege use
Privilege use events occur when a user exercises a user right (other than logon, logoff, and network access rights, which trigger other types of events).
Audit process tracking
Process tracking includes events such as program activation, handle duplication, indirect object access, and process exit. Although this policy generates a large number of events to wade through, it can provide useful information, such as which program a user used to access an object.
Audit system events
System events occur when a user restarts or shuts down the computer or when an event affects the system security or the Security log.
NOTE
--------------------------------------------------------------------------------
In Windows XP Home Edition, account logon, account management, logon, policy change, and system events are audited for both successful incidents and failed attempts. You cannot enable auditing for directory service access, object access, privilege use, or process tracking events, or disable the categories that are already enabled, without additional tools.
Local Security Settings has some additional policies that affect auditing, but they're not in the Audit Policy folder. Instead, look to the Security Settings\Local Policies\ Security Options folder for these policies:
Audit: Audit the user of Backup and Restore privilege. Enable this policy if you want to know when someone uses a backup program to back up or restore files. To make this policy effective, you must also enable Audit Privilege Use in the Audit Policy folder.
Audit: Shut down system immediately if unable to log security audits. For details about this extreme security policy, see the sidebar Ensuring That You Don't Miss Any Security Events.
Audit: Audit the access of global system objects. This policy affects auditing of obscure objects (mutexes and semaphores, for example) that aren't used in most home and small business networks; you can safely ignore it.
NOTE
--------------------------------------------------------------------------------
In Windows 2000, the word "Audit:" does not precede the policy names.
Unlike the other logs that appear in Event Viewer, the Security log is disabled by default in Windows XP Professional and Windows 2000. No events are written to the Security log until you enable auditing, which you do via Local Security Settings. (In Windows XP Home Edition, security auditing is enabled for certain events. Because Home Edition doesn't include Local Security Settings, you cannot change which events are audited unless you use a tool like Auditpol.exe, which is included in the Windows 2000 Resource Kit.) Even if you set up auditing for files, folders, or printers, as explained later in this chapter, the events you specify aren't recorded unless you also enable auditing by setting a high-level audit policy in Local Security Settings.
NOTE
--------------------------------------------------------------------------------
To enable auditing, you must be logged on with an account that has the Manage Auditing And Security Log privilege. By default, only members of the Administrators group have this privilege. For information about privileges, see Exploring User Rights.
To enable auditing, follow these steps:
In Control Panel, open Administrative Tools, Local Security Policy. (If you use Category view in Windows XP, you'll find Administrative Tools under Performance And Maintenance.) Alternatively, you can type secpol.msc at a command prompt.
In the console tree, select Security Settings\Local Policies\Audit Policy.
Double-click each policy for which you want to enable auditing, and then select Success, Failure, or both. Figure 20-1 shows the properties dialog box for an audit policy.
Figure 20-1. You enable auditing using the Local Security Settings console.
Figure 20-1 also shows the types of activities you can audit. Some, such as account management and policy change, provide an audit trail for administrative changes. Others, such as logon events and object access, help you monitor who is attempting to use your system. Still others, including system events and process tracking, can assist you in locating problems with your system. Table 20-1 provides more details.
Table 20-1. Audit Policies for Security Events
Policy Description
Audit account logon events
Account logon events occur when a user attempts to log on or log off across the network, authenticating to a local user account.
Audit account management
Account management events occur when a user account or security group is created, changed, or deleted; when a user account is renamed, enabled, or disabled; or when a password is set or changed.
Audit directory service access
Directory service access events occur when a user attempts to access an Active Directory object. (If your computer is not part of a Windows domain, these events won't occur.)
Audit logon events
Logon events occur when a user attempts to log on or log off a workstation interactively.
Audit object access
Object access events occur when a user attempts to access a file, folder, printer, registry key, or other object that is set for auditing.
Audit policy change
Policy change events occur when a change is made to user rights assignment policies, audit policies, trust policies, or password policies.
Audit privilege use
Privilege use events occur when a user exercises a user right (other than logon, logoff, and network access rights, which trigger other types of events).
Audit process tracking
Process tracking includes events such as program activation, handle duplication, indirect object access, and process exit. Although this policy generates a large number of events to wade through, it can provide useful information, such as which program a user used to access an object.
Audit system events
System events occur when a user restarts or shuts down the computer or when an event affects the system security or the Security log.
NOTE
--------------------------------------------------------------------------------
In Windows XP Home Edition, account logon, account management, logon, policy change, and system events are audited for both successful incidents and failed attempts. You cannot enable auditing for directory service access, object access, privilege use, or process tracking events, or disable the categories that are already enabled, without additional tools.
Local Security Settings has some additional policies that affect auditing, but they're not in the Audit Policy folder. Instead, look to the Security Settings\Local Policies\ Security Options folder for these policies:
Audit: Audit the user of Backup and Restore privilege. Enable this policy if you want to know when someone uses a backup program to back up or restore files. To make this policy effective, you must also enable Audit Privilege Use in the Audit Policy folder.
Audit: Shut down system immediately if unable to log security audits. For details about this extreme security policy, see the sidebar Ensuring That You Don't Miss Any Security Events.
Audit: Audit the access of global system objects. This policy affects auditing of obscure objects (mutexes and semaphores, for example) that aren't used in most home and small business networks; you can safely ignore it.
NOTE
--------------------------------------------------------------------------------
In Windows 2000, the word "Audit:" does not precede the policy names.
Auditing Security Events
Auditing Security Events
Auditing tracks the activities of users and security-sensitive changes to the system by recording in the Security log the events that you specify. For example, you can choose to audit failed logon attempts, which might indicate that someone is trying to log on with an invalid password (perhaps using a program to automate the attack). Or you might want to monitor the use of a particularly sensitive file. You can also choose to monitor changes to user accounts and passwords, changes to security policies, and use of privileges that might reveal that someone is trying to "administer" your computer—perhaps not with your best interests in mind.
Auditing tracks the activities of users and security-sensitive changes to the system by recording in the Security log the events that you specify. For example, you can choose to audit failed logon attempts, which might indicate that someone is trying to log on with an invalid password (perhaps using a program to automate the attack). Or you might want to monitor the use of a particularly sensitive file. You can also choose to monitor changes to user accounts and passwords, changes to security policies, and use of privileges that might reveal that someone is trying to "administer" your computer—perhaps not with your best interests in mind.
Monitoring Security Events
Monitoring Security Events
You can't keep an eye on your computer—let alone all the other computers on your network—all the time. Although you might have put in place all the proper safeguards to protect your data from unauthorized access (such as strong passwords, appropriate permissions, and a firewall), you can't be sure that those safeguards are always working properly. By taking advantage of improper settings inadvertently made by a user or simply by making a determined effort, an attacker might still gain access to resources that should be off limits.
Fortunately, Microsoft Windows XP Professional and Microsoft Windows 2000 provide the ability to audit your security setup, by recording attempts to access objects on the system, and by recording security-sensitive changes to the system's configuration. When properly configured, Windows monitors usage of a computer, allowing you to spot any unauthorized events or other security lapses. Using this information, you can plug any security holes to prevent a recurrence.
Windows records security events in the Security log, one of three logs that you can peruse in Event Viewer. (The others are the Application log and the System log. Computers running Microsoft Windows 2000 Server might have additional logs, including Directory Service, DNS Server, and File Replication Service.) In this chapter, we explain how to configure your system to audit security events, offer some suggestions on which events to audit, and show you how to work with the Security log in Event Viewer.
You can't keep an eye on your computer—let alone all the other computers on your network—all the time. Although you might have put in place all the proper safeguards to protect your data from unauthorized access (such as strong passwords, appropriate permissions, and a firewall), you can't be sure that those safeguards are always working properly. By taking advantage of improper settings inadvertently made by a user or simply by making a determined effort, an attacker might still gain access to resources that should be off limits.
Fortunately, Microsoft Windows XP Professional and Microsoft Windows 2000 provide the ability to audit your security setup, by recording attempts to access objects on the system, and by recording security-sensitive changes to the system's configuration. When properly configured, Windows monitors usage of a computer, allowing you to spot any unauthorized events or other security lapses. Using this information, you can plug any security holes to prevent a recurrence.
Windows records security events in the Security log, one of three logs that you can peruse in Event Viewer. (The others are the Application log and the System log. Computers running Microsoft Windows 2000 Server might have additional logs, including Directory Service, DNS Server, and File Replication Service.) In this chapter, we explain how to configure your system to audit security events, offer some suggestions on which events to audit, and show you how to work with the Security log in Event Viewer.
Managing Security Through Group Policy and Security Templates
Managing Security Through Group Policy and Security Templates
Group Policy is a feature of Microsoft Windows XP Professional and Microsoft Windows 2000 that lets an administrator configure a computer and, optionally, prevent users from changing that configuration. Administrators can use Group Policy to set standard desktop configurations; restrict what settings users are allowed to change; specify scripts to run at startup, shutdown, logon, and logoff; redirect users' special folders (such as My Documents) to network drives; and more. In addition—and more pertinent to the topic of this book—administrators can use Group Policy to control a number of security settings.
NOTE
--------------------------------------------------------------------------------
To manage Group Policy in Windows XP Professional or Windows 2000, you must be logged on as a member of the Administrators group. Group Policy is not available in Windows XP Home Edition.
The ideal environment for using Group Policy is a Microsoft Windows .NET Server or Microsoft Windows 2000 Server domain, in which administrators can centrally configure computers throughout sites, domains, or organizational units. In a domain environment, administrators can specify unique policies for different computers, users, or security groups. Managing Group Policy in an Active Directory domain environment is well documented in a number of books about administering Windows servers; two good examples are Microsoft Windows 2000 Server Administrator's Companion by Charlie Russel and Sharon Crawford (Microsoft Press, 2000) and Microsoft Windows 2000 Server Resource Kit (Microsoft, 2000).
In this book, however, we focus on using Group Policy to make settings on a computer running Windows XP Professional or Windows 2000 in a workgroup environment. We further narrow our focus by concentrating on security-related policy settings. Our earlier book, Microsoft Windows XP Inside Out (Microsoft Press, 2001), provides more general information about using Group Policy in a workgroup environment.
In this chapter, we first examine the security settings you can make through Group Policy and explain how to apply these settings using Microsoft Management Console (MMC) snap-ins. In a workgroup, you must make Group Policy settings on each computer where you want such restrictions imposed; you can't apply Group Policy settings to all computers, users, or groups on the network in a single operation, as you can in a domain. However, by using security templates—another subject covered in this chapter—you can store all your security-related settings in a file that you can then use to apply the settings on each computer. The final topic of this chapter is Security Configuration And Analysis, an MMC snap-in that allows you to compare your current security settings with those of a security template and apply the template settings if you choose.
Security Checklist: Group Policy and Security Templates
--------------------------------------------------------------------------------
Although the default configuration for Windows is reasonably secure for most situations, you should consider taking the following steps to tighten your computer's security:
Learn about the available security-related policies.
Use Group Policy to apply settings in the Administrative Templates folders.
For a one-time configuration of a single computer, use Local Security Settings (or Group Policy) to apply security settings.
Consider making different security settings for different groups of users. (Using a workaround described in this chapter, you can do that even on computers that are not part of an Active Directory domain.)
Modify or create a security template to incorporate the security settings you want to apply to multiple computers (or multiple times to a single computer).
Perform a security analysis to see how your current security settings compare with those in your security template.
Apply the settings from your security template.
Group Policy is a feature of Microsoft Windows XP Professional and Microsoft Windows 2000 that lets an administrator configure a computer and, optionally, prevent users from changing that configuration. Administrators can use Group Policy to set standard desktop configurations; restrict what settings users are allowed to change; specify scripts to run at startup, shutdown, logon, and logoff; redirect users' special folders (such as My Documents) to network drives; and more. In addition—and more pertinent to the topic of this book—administrators can use Group Policy to control a number of security settings.
NOTE
--------------------------------------------------------------------------------
To manage Group Policy in Windows XP Professional or Windows 2000, you must be logged on as a member of the Administrators group. Group Policy is not available in Windows XP Home Edition.
The ideal environment for using Group Policy is a Microsoft Windows .NET Server or Microsoft Windows 2000 Server domain, in which administrators can centrally configure computers throughout sites, domains, or organizational units. In a domain environment, administrators can specify unique policies for different computers, users, or security groups. Managing Group Policy in an Active Directory domain environment is well documented in a number of books about administering Windows servers; two good examples are Microsoft Windows 2000 Server Administrator's Companion by Charlie Russel and Sharon Crawford (Microsoft Press, 2000) and Microsoft Windows 2000 Server Resource Kit (Microsoft, 2000).
In this book, however, we focus on using Group Policy to make settings on a computer running Windows XP Professional or Windows 2000 in a workgroup environment. We further narrow our focus by concentrating on security-related policy settings. Our earlier book, Microsoft Windows XP Inside Out (Microsoft Press, 2001), provides more general information about using Group Policy in a workgroup environment.
In this chapter, we first examine the security settings you can make through Group Policy and explain how to apply these settings using Microsoft Management Console (MMC) snap-ins. In a workgroup, you must make Group Policy settings on each computer where you want such restrictions imposed; you can't apply Group Policy settings to all computers, users, or groups on the network in a single operation, as you can in a domain. However, by using security templates—another subject covered in this chapter—you can store all your security-related settings in a file that you can then use to apply the settings on each computer. The final topic of this chapter is Security Configuration And Analysis, an MMC snap-in that allows you to compare your current security settings with those of a security template and apply the template settings if you choose.
Security Checklist: Group Policy and Security Templates
--------------------------------------------------------------------------------
Although the default configuration for Windows is reasonably secure for most situations, you should consider taking the following steps to tighten your computer's security:
Learn about the available security-related policies.
Use Group Policy to apply settings in the Administrative Templates folders.
For a one-time configuration of a single computer, use Local Security Settings (or Group Policy) to apply security settings.
Consider making different security settings for different groups of users. (Using a workaround described in this chapter, you can do that even on computers that are not part of an Active Directory domain.)
Modify or create a security template to incorporate the security settings you want to apply to multiple computers (or multiple times to a single computer).
Perform a security analysis to see how your current security settings compare with those in your security template.
Apply the settings from your security template.
Creating a New Personal Encryption Certificate
Creating a New Personal Encryption Certificate
If you lose your personal encryption certificate, you can create a new one using Cipher.exe, the command-line encryption utility. At a command prompt, simply type cipher /k to create a new personal encryption certificate for the user running Cipher. (By using the RunAs command to launch Cipher, you can create certificates for other users.) Of course, you can't use the new certificate to decrypt files that were encrypted using the public key from your old certificate.
If you lose your personal encryption certificate, you can create a new one using Cipher.exe, the command-line encryption utility. At a command prompt, simply type cipher /k to create a new personal encryption certificate for the user running Cipher. (By using the RunAs command to launch Cipher, you can create certificates for other users.) Of course, you can't use the new certificate to decrypt files that were encrypted using the public key from your old certificate.
Importing a Personal Encryption Certificate
Importing a Personal Encryption Certificate
You will need to import your personal certificate—one that you exported to disk using the procedure in the preceding section—in either of the following situations:
You want to use your encrypted files on a different computer.
Your original personal certificate is accidentally lost or becomes corrupt.
To import a personal encryption certificate, follow these steps:
In Internet Explorer, choose Tools, Internet Options. On the Content tab of the Internet Options dialog box, click Certificates to open the Certificates dialog box.
Click Import to launch the Certificate Import Wizard, and then click Next.
Enter the path and file name of the encryption certificate (a .pfx file) you exported, and then click Next. If you click Browse, you need to select Personal Information Exchange in the Files Of Type box to see .pfx files.
Enter the password, select other options if you want, and then click Next.
Select Place All Certificates In The Following Store, click Browse, and then select Personal. Click OK, Next, and then Finish.
TIP
--------------------------------------------------------------------------------
As a quick alternative to the first three steps of the preceding procedure, you can simply double-click the encryption certificate file in Windows Explorer. Doing so launches the Certificate Import Wizard.
You will need to import your personal certificate—one that you exported to disk using the procedure in the preceding section—in either of the following situations:
You want to use your encrypted files on a different computer.
Your original personal certificate is accidentally lost or becomes corrupt.
To import a personal encryption certificate, follow these steps:
In Internet Explorer, choose Tools, Internet Options. On the Content tab of the Internet Options dialog box, click Certificates to open the Certificates dialog box.
Click Import to launch the Certificate Import Wizard, and then click Next.
Enter the path and file name of the encryption certificate (a .pfx file) you exported, and then click Next. If you click Browse, you need to select Personal Information Exchange in the Files Of Type box to see .pfx files.
Enter the password, select other options if you want, and then click Next.
Select Place All Certificates In The Following Store, click Browse, and then select Personal. Click OK, Next, and then Finish.
TIP
--------------------------------------------------------------------------------
As a quick alternative to the first three steps of the preceding procedure, you can simply double-click the encryption certificate file in Windows Explorer. Doing so launches the Certificate Import Wizard.
Exporting a Personal Encryption Certificate
Exporting a Personal Encryption Certificate
To back up a personal encryption certificate, take these steps:
Log on as the user whose certificate you want to back up.
In Microsoft Internet Explorer, choose Tools, Internet Options. On the Content tab of the Internet Options dialog box, click Certificates to open the Certificates dialog box.
NOTE
--------------------------------------------------------------------------------
If you prefer, you can use the Certificates snap-in for Microsoft Management Console for this procedure. We chose to open the Certificates dialog box through Internet Options because this route is available and easily understandable for all users; no special privileges are required.
On the Personal tab, select the certificate that shows Encrypting File System in the Certificate Intended Purposes box at the bottom of the dialog box.
NOTE
--------------------------------------------------------------------------------
Windows creates this certificate the first time you encrypt a folder or file. Unless you have encrypted something—or you created an encryption certificate in some other way—the certificate won't exist.
Click Export to launch the Certificate Export Wizard, and then click Next.
Select Yes, Export The Private Key, and then click Next two times.
Specify a password for the .pfx file. It doesn't need to be the same as your logon password. Click Next.
Specify the path and file name for the exported file.
Click Next and then click Finish.
As you'll see in the next section, the import process makes it easy to install your certificate on another computer—and thereby provide access to your encrypted files. For that reason, be careful to observe these guidelines:
When you export your certificate, be sure to protect it with a password that can't be guessed easily. Unlike the case of logon attempts, no policies exist to prevent further attempts after a certain number of incorrect guesses. (On the other hand, be sure to use a password that you can remember when the need arises!)
Be sure to keep your certificate files—whether they're on a floppy disk, a hard disk, or some other medium—in a secure place.
To back up a personal encryption certificate, take these steps:
Log on as the user whose certificate you want to back up.
In Microsoft Internet Explorer, choose Tools, Internet Options. On the Content tab of the Internet Options dialog box, click Certificates to open the Certificates dialog box.
NOTE
--------------------------------------------------------------------------------
If you prefer, you can use the Certificates snap-in for Microsoft Management Console for this procedure. We chose to open the Certificates dialog box through Internet Options because this route is available and easily understandable for all users; no special privileges are required.
On the Personal tab, select the certificate that shows Encrypting File System in the Certificate Intended Purposes box at the bottom of the dialog box.
NOTE
--------------------------------------------------------------------------------
Windows creates this certificate the first time you encrypt a folder or file. Unless you have encrypted something—or you created an encryption certificate in some other way—the certificate won't exist.
Click Export to launch the Certificate Export Wizard, and then click Next.
Select Yes, Export The Private Key, and then click Next two times.
Specify a password for the .pfx file. It doesn't need to be the same as your logon password. Click Next.
Specify the path and file name for the exported file.
Click Next and then click Finish.
As you'll see in the next section, the import process makes it easy to install your certificate on another computer—and thereby provide access to your encrypted files. For that reason, be careful to observe these guidelines:
When you export your certificate, be sure to protect it with a password that can't be guessed easily. Unlike the case of logon attempts, no policies exist to prevent further attempts after a certain number of incorrect guesses. (On the other hand, be sure to use a password that you can remember when the need arises!)
Be sure to keep your certificate files—whether they're on a floppy disk, a hard disk, or some other medium—in a secure place.
Backing Up Your Certificates
Backing Up Your Certificates
When you use encryption for the first time (and you don't already have a certificate that's valid for EFS), Windows creates a self-signed certificate for EFS. (Self-signed means that the certificate has not been granted by a trusted certification authority that can confirm your identity. Such verification is unnecessary for this purpose; in this case, the signature merely confirms that the certificate was created while your account was logged on.) This certificate becomes your personal encryption certificate, and it contains the public/private key pair used for encrypting and decrypting files while you're logged on.
Each user who encrypts files on a system has a personal encryption certificate. In addition, Windows can create a certificate for the designated data recovery agent. This certificate, whose purpose is shown as File Recovery, is not the same as that user's personal encryption certificate, whose purpose is shown as Encrypting File System.
All users should have a backup of their personal encryption certificate. More important, the system administrator should have a backup of the file recovery certificate and the data recovery agent's private key. Without one or the other of the certificates, encrypted files are unusable.
Backing Up the File Recovery Certificate
The file recovery certificate provides an administrative alternative for decrypting files if a user's personal encryption certificate is unavailable for any reason. Having a backup of this certificate is essential if you plan to use EFS.
To back up the file recovery certificate, follow these steps:
Log on as a member of the Administrators group.
In Local Security Settings (Secpol.msc), go to Security Settings\Public Key Policies\Encrypting File System. (In Windows 2000, the folder is called Encrypted Data Recovery Agents.)
Right-click the certificate issued to Administrator (or another user account) for the purpose of File Recovery. Choose All Tasks, Export to launch the Certificate Export Wizard, and then click Next.
Select DER Encoded Binary X.509 (.CER), and then click Next.
Specify the path and file name for the exported file.
Click Next and then click Finish.
When you use encryption for the first time (and you don't already have a certificate that's valid for EFS), Windows creates a self-signed certificate for EFS. (Self-signed means that the certificate has not been granted by a trusted certification authority that can confirm your identity. Such verification is unnecessary for this purpose; in this case, the signature merely confirms that the certificate was created while your account was logged on.) This certificate becomes your personal encryption certificate, and it contains the public/private key pair used for encrypting and decrypting files while you're logged on.
Each user who encrypts files on a system has a personal encryption certificate. In addition, Windows can create a certificate for the designated data recovery agent. This certificate, whose purpose is shown as File Recovery, is not the same as that user's personal encryption certificate, whose purpose is shown as Encrypting File System.
All users should have a backup of their personal encryption certificate. More important, the system administrator should have a backup of the file recovery certificate and the data recovery agent's private key. Without one or the other of the certificates, encrypted files are unusable.
Backing Up the File Recovery Certificate
The file recovery certificate provides an administrative alternative for decrypting files if a user's personal encryption certificate is unavailable for any reason. Having a backup of this certificate is essential if you plan to use EFS.
To back up the file recovery certificate, follow these steps:
Log on as a member of the Administrators group.
In Local Security Settings (Secpol.msc), go to Security Settings\Public Key Policies\Encrypting File System. (In Windows 2000, the folder is called Encrypted Data Recovery Agents.)
Right-click the certificate issued to Administrator (or another user account) for the purpose of File Recovery. Choose All Tasks, Export to launch the Certificate Export Wizard, and then click Next.
Select DER Encoded Binary X.509 (.CER), and then click Next.
Specify the path and file name for the exported file.
Click Next and then click Finish.
Designating Data Recovery Agents
Designating Data Recovery Agents
You can designate any user as a data recovery agent. We recommend that you use the Administrator account.
CAUTION
--------------------------------------------------------------------------------
Do not designate the account you use to create encrypted files as a data recovery agent. Doing so provides little or no protection. If the user profile is damaged or deleted, you will lose all the keys that allow decryption of the files.
Follow these steps to designate a data recovery agent:
Log on with the account that you want to designate as a data recovery agent.
Using the Certificates snap-in (in Windows XP, type certmgr.msc at a command prompt), go to Certificates - Current User\Personal.
Choose Action, All Tasks, Import to launch the Certificate Import Wizard. Click Next.
Enter the path and file name of the encryption certificate (a .pfx file) you exported (see Figure 18-4), and click Next. If you click Browse, you must select Personal Information Exchange in the Files Of Type box to see .pfx files. Click Next.
Figure 18-4. Be sure to specify the .pfx file—not the .cer file to which the Browse button leads you by default.
Enter the password for this certificate, and then select Mark This Key As Exportable. Click Next.
Select Automatically Select The Certificate Store Based On The Type Of Certificate, and then click Next. Click Finish.
In Local Security Settings (Secpol.msc), go to Security Settings\Public Key Policies\Encrypting File System.
Choose Action, Add Data Recovery Agent. Click Next.
On the Select Recovery Agents page, click Browse Folders and then navigate to the folder that contains the .cer file you created. (The Browse Directory button searches Active Directory.) Select the file and click Open.
The Select Recovery Agents page now shows the new agent as USER_UNKNOWN. Don't be alarmed by the USER_UNKNOWN text; simply click Next and then click Finish.
The current user is now the data recovery agent for all encrypted files on this system.
You can designate any user as a data recovery agent. We recommend that you use the Administrator account.
CAUTION
--------------------------------------------------------------------------------
Do not designate the account you use to create encrypted files as a data recovery agent. Doing so provides little or no protection. If the user profile is damaged or deleted, you will lose all the keys that allow decryption of the files.
Follow these steps to designate a data recovery agent:
Log on with the account that you want to designate as a data recovery agent.
Using the Certificates snap-in (in Windows XP, type certmgr.msc at a command prompt), go to Certificates - Current User\Personal.
Choose Action, All Tasks, Import to launch the Certificate Import Wizard. Click Next.
Enter the path and file name of the encryption certificate (a .pfx file) you exported (see Figure 18-4), and click Next. If you click Browse, you must select Personal Information Exchange in the Files Of Type box to see .pfx files. Click Next.
Figure 18-4. Be sure to specify the .pfx file—not the .cer file to which the Browse button leads you by default.
Enter the password for this certificate, and then select Mark This Key As Exportable. Click Next.
Select Automatically Select The Certificate Store Based On The Type Of Certificate, and then click Next. Click Finish.
In Local Security Settings (Secpol.msc), go to Security Settings\Public Key Policies\Encrypting File System.
Choose Action, Add Data Recovery Agent. Click Next.
On the Select Recovery Agents page, click Browse Folders and then navigate to the folder that contains the .cer file you created. (The Browse Directory button searches Active Directory.) Select the file and click Open.
The Select Recovery Agents page now shows the new agent as USER_UNKNOWN. Don't be alarmed by the USER_UNKNOWN text; simply click Next and then click Finish.
The current user is now the data recovery agent for all encrypted files on this system.
Removing the Private Key
Removing the Private Key
To prevent someone from simply logging on as Administrator (or another designated data recovery agent) and viewing another user's encrypted files, you can export and remove the data recovery agent's private key. Keep the key in a secure location—without it, you can't use the file recovery certificate.
To remove the data recovery agent's private key, follow these steps:
Log on with the account you designated as a data recovery agent.
In Certificates (Certmgr.msc), go to Certificates - Current User\Personal\Certificates.
Right-click the File Recovery certificate (so identified in the Intended Purposes column), and then choose All Tasks, Export to launch the Certificate Export Wizard. Click Next.
Select Yes, Export The Private Key, and then click Next.
Select Enable Strong Protection and Delete The Private Key If The Export Is Successful. Click Next.
Enter a password twice, and then click Next.
Specify the path and file name for the exported file.
Click Next and then click Finish.
As with the file recovery certificates, you should copy the file to a removable disk, store it in a secure location, and then remove the file from your hard disk.
The data recovery agent's public key is now used to encrypt a copy of the FEK with each encrypted file, but because the private key is not available, the data recovery agent can't view the files. To reestablish the data recovery agent's access to encrypted files, import the private key you just exported, using the same procedure as for importing a personal certificate. For details, see Importing a Personal Encryption Certificate.
To prevent someone from simply logging on as Administrator (or another designated data recovery agent) and viewing another user's encrypted files, you can export and remove the data recovery agent's private key. Keep the key in a secure location—without it, you can't use the file recovery certificate.
To remove the data recovery agent's private key, follow these steps:
Log on with the account you designated as a data recovery agent.
In Certificates (Certmgr.msc), go to Certificates - Current User\Personal\Certificates.
Right-click the File Recovery certificate (so identified in the Intended Purposes column), and then choose All Tasks, Export to launch the Certificate Export Wizard. Click Next.
Select Yes, Export The Private Key, and then click Next.
Select Enable Strong Protection and Delete The Private Key If The Export Is Successful. Click Next.
Enter a password twice, and then click Next.
Specify the path and file name for the exported file.
Click Next and then click Finish.
As with the file recovery certificates, you should copy the file to a removable disk, store it in a secure location, and then remove the file from your hard disk.
The data recovery agent's public key is now used to encrypt a copy of the FEK with each encrypted file, but because the private key is not available, the data recovery agent can't view the files. To reestablish the data recovery agent's access to encrypted files, import the private key you just exported, using the same procedure as for importing a personal certificate. For details, see Importing a Personal Encryption Certificate.
Generating a File Recovery Certificate
Generating a File Recovery Certificate
To generate a file recovery certificate, follow these steps:
Log on as an administrator.
At a command prompt, type cipher /r:filename, where filename is the name you want to assign to the stored certificate files. Do not include a filename extension.
When prompted, type a password that will be used to protect the files you create.
These steps generate both a .pfx file and a .cer file with the file name you specify.
CAUTION
--------------------------------------------------------------------------------
These files allow anyone to become a data recovery agent. Be sure to copy them to a disk and put it in a secure, safe place. Then erase these files from your hard disk.
INSIDEOUT
--------------------------------------------------------------------------------
An alternative to data recovery agents
The reason Windows XP does not have a default data recovery agent for stand-alone computers is to provide enhanced security. In Windows 2000, a thief who's able to crack the Administrator account (the default data recovery agent) has access to all the encrypted files on a stolen computer. With Windows XP, the only way a thief can get your encrypted data is by knowing your user name and password.
This extra security comes with some risk: If you forget your password, you're locked out of your own files, and you have no practical way to get them back. For that reason, we suggest creating a data recovery agent as one solution. However, another solution that's easier and, perhaps, more secure is to create a Password Reset Disk. For details, see Using a Password Reset Disk.
To generate a file recovery certificate, follow these steps:
Log on as an administrator.
At a command prompt, type cipher /r:filename, where filename is the name you want to assign to the stored certificate files. Do not include a filename extension.
When prompted, type a password that will be used to protect the files you create.
These steps generate both a .pfx file and a .cer file with the file name you specify.
CAUTION
--------------------------------------------------------------------------------
These files allow anyone to become a data recovery agent. Be sure to copy them to a disk and put it in a secure, safe place. Then erase these files from your hard disk.
INSIDEOUT
--------------------------------------------------------------------------------
An alternative to data recovery agents
The reason Windows XP does not have a default data recovery agent for stand-alone computers is to provide enhanced security. In Windows 2000, a thief who's able to crack the Administrator account (the default data recovery agent) has access to all the encrypted files on a stolen computer. With Windows XP, the only way a thief can get your encrypted data is by knowing your user name and password.
This extra security comes with some risk: If you forget your password, you're locked out of your own files, and you have no practical way to get them back. For that reason, we suggest creating a data recovery agent as one solution. However, another solution that's easier and, perhaps, more secure is to create a Password Reset Disk. For details, see Using a Password Reset Disk.
Creating a Data Recovery Agent
Creating a Data Recovery Agent
Designating a data recovery agent—another user who can access your encrypted files—allows you to recover encrypted files if something happens to your private key.
In Windows 2000, the Administrator account is set up as the default data recovery agent. If your computer is a member of a domain, the domain administrator is the default data recovery agent. But if you're using Windows XP and your computer is not in a domain, there is no default data recovery agent.
NOTE
--------------------------------------------------------------------------------
In Windows 2000, a data recovery agent is required. If no data recovery agent exists, you can't encrypt files. In Windows XP, however, a data recovery agent is optional (but usually desirable).
To create a data recovery agent, you must create a file recovery certificate and then designate a user to be the data recovery agent.
Designating a data recovery agent—another user who can access your encrypted files—allows you to recover encrypted files if something happens to your private key.
In Windows 2000, the Administrator account is set up as the default data recovery agent. If your computer is a member of a domain, the domain administrator is the default data recovery agent. But if you're using Windows XP and your computer is not in a domain, there is no default data recovery agent.
NOTE
--------------------------------------------------------------------------------
In Windows 2000, a data recovery agent is required. If no data recovery agent exists, you can't encrypt files. In Windows XP, however, a data recovery agent is optional (but usually desirable).
To create a data recovery agent, you must create a file recovery certificate and then designate a user to be the data recovery agent.
Disabling EFS for Individual Folders or Files
Disabling EFS for Individual Folders or Files
You might want to prevent the encryption of files in a certain folder to ensure that they remain available to everyone who has access to the folder. To disable encryption within a folder, use Notepad (or another text editor) to create a file that contains the following lines:
[Encryption]Disable=1
Save the file as Desktop.ini in the folder in which you want to prevent encryption. Any encrypted files already in the folder remain encrypted, but users who attempt to encrypt any other files will be stopped with this message: "The directory has been disabled for encryption."
Disabling encryption in this fashion doesn't disable encryption altogether, even within the folder you've set up. If you copy or move encrypted files into the folder, they remain encrypted. And if you create a subfolder within the folder, you can encrypt the subfolder and any files it contains.
Troubleshooting
--------------------------------------------------------------------------------
Files still become encrypted after you've disabled EFS for a folder.
You might discover that files added to a folder become encrypted even after you create the Desktop.ini file described here and store it in the folder. This can occur if encryption was already enabled for the folder when you added the Desktop.ini file. (With the file in place, you won't be able to set the encryption attribute for the folder.) To prevent new files from being encrypted, right-click the folder, choose Properties, click Advanced, and clear the Encrypt Contents To Secure Data check box.
It's possible, but generally not practical, to prevent certain files from being encrypted. You can do this in any of the following ways, each of which has a drawback:
Store the file in %SystemRoot% or one of its subfolders—folders in which encryption is never allowed. (Drawbacks: Windows makes it difficult to browse to these folders, and storing the file here might not fit your system of organizing files.)
Use the Attrib command to set the file's System attribute. (Drawback: By default, Windows Explorer does not display system files, so they're difficult to find.)
Remove Write permission from the file for users you want to prevent from encrypting. (Drawback: Removing Write permission also prevents users from editing the file.)
Strengthening EFS Protection
EFS provides extremely strong protection against attackers. Multiple levels of encryption make it all but impossible to crack. In Windows XP (but not Windows 2000), you can strengthen security even more by using Triple Data Encryption Standard (3DES) to encrypt and decrypt files instead of the default algorithm, expanded Data Encryption Standard (DESX). Although 3DES is more secure, it's slower because it processes each block of each file three times.
To enable 3DES protection, follow these steps:
Open Local Security Settings (Secpol.msc).
Select Security Settings\Local Policies\Security Options.
In the details pane, double-click System Cryptography: Use FIPS Compliant Algorithms For Encryption, Hashing, And Signing.
Select Enabled and click OK.
INSIDEOUT
--------------------------------------------------------------------------------
Protecting encrypted files from wily administrators
If you use EFS extensively and your computer is not a member of a domain, you might consider upgrading to Windows XP if you haven't already. That's because Windows XP adds another level of protection that directly affects the security of your encrypted files. In Windows 2000, an administrator can reset your password—a valuable trick if you forget the password. However, that means an unscrupulous administrator can reset your password, log in using your account, and peer into your encrypted files. The underhandedness won't go undetected (because your password has been changed, you'll need to contact the same administrator to reset it for you), but the damage will have been done. With Windows XP, in contrast, if anyone other than yourself changes your password, your certificates (which are needed for decrypting files, among other things) become inaccessible. Should a devious, but uninformed, administrator try to get your secrets by changing your password, you can restore access to your certificates by resetting your password to its previous value or by using your Password Reset Disk. For more information, see Recovering a Lost Password
You might want to prevent the encryption of files in a certain folder to ensure that they remain available to everyone who has access to the folder. To disable encryption within a folder, use Notepad (or another text editor) to create a file that contains the following lines:
[Encryption]Disable=1
Save the file as Desktop.ini in the folder in which you want to prevent encryption. Any encrypted files already in the folder remain encrypted, but users who attempt to encrypt any other files will be stopped with this message: "The directory has been disabled for encryption."
Disabling encryption in this fashion doesn't disable encryption altogether, even within the folder you've set up. If you copy or move encrypted files into the folder, they remain encrypted. And if you create a subfolder within the folder, you can encrypt the subfolder and any files it contains.
Troubleshooting
--------------------------------------------------------------------------------
Files still become encrypted after you've disabled EFS for a folder.
You might discover that files added to a folder become encrypted even after you create the Desktop.ini file described here and store it in the folder. This can occur if encryption was already enabled for the folder when you added the Desktop.ini file. (With the file in place, you won't be able to set the encryption attribute for the folder.) To prevent new files from being encrypted, right-click the folder, choose Properties, click Advanced, and clear the Encrypt Contents To Secure Data check box.
It's possible, but generally not practical, to prevent certain files from being encrypted. You can do this in any of the following ways, each of which has a drawback:
Store the file in %SystemRoot% or one of its subfolders—folders in which encryption is never allowed. (Drawbacks: Windows makes it difficult to browse to these folders, and storing the file here might not fit your system of organizing files.)
Use the Attrib command to set the file's System attribute. (Drawback: By default, Windows Explorer does not display system files, so they're difficult to find.)
Remove Write permission from the file for users you want to prevent from encrypting. (Drawback: Removing Write permission also prevents users from editing the file.)
Strengthening EFS Protection
EFS provides extremely strong protection against attackers. Multiple levels of encryption make it all but impossible to crack. In Windows XP (but not Windows 2000), you can strengthen security even more by using Triple Data Encryption Standard (3DES) to encrypt and decrypt files instead of the default algorithm, expanded Data Encryption Standard (DESX). Although 3DES is more secure, it's slower because it processes each block of each file three times.
To enable 3DES protection, follow these steps:
Open Local Security Settings (Secpol.msc).
Select Security Settings\Local Policies\Security Options.
In the details pane, double-click System Cryptography: Use FIPS Compliant Algorithms For Encryption, Hashing, And Signing.
Select Enabled and click OK.
INSIDEOUT
--------------------------------------------------------------------------------
Protecting encrypted files from wily administrators
If you use EFS extensively and your computer is not a member of a domain, you might consider upgrading to Windows XP if you haven't already. That's because Windows XP adds another level of protection that directly affects the security of your encrypted files. In Windows 2000, an administrator can reset your password—a valuable trick if you forget the password. However, that means an unscrupulous administrator can reset your password, log in using your account, and peer into your encrypted files. The underhandedness won't go undetected (because your password has been changed, you'll need to contact the same administrator to reset it for you), but the damage will have been done. With Windows XP, in contrast, if anyone other than yourself changes your password, your certificates (which are needed for decrypting files, among other things) become inaccessible. Should a devious, but uninformed, administrator try to get your secrets by changing your password, you can restore access to your certificates by resetting your password to its previous value or by using your Password Reset Disk. For more information, see Recovering a Lost Password
Disabling or Reenabling EFS
Disabling or Reenabling EFS
If you want to prevent users from encrypting files on a particular machine, you can disable EFS. If your computer is part of a domain, domain-level policies determine whether EFS can be used on a workstation. For stand-alone computers and computers that are part of a workgroup, the following sections explain how to control the availability of EFS.
Disabling or Reenabling EFS in Windows XP
To disable EFS on a computer running Windows XP Professional that is not part of a domain, follow these steps:
Open Registry Editor. (At a command prompt, type regedit.)
Open the HKLM\Software\Microsoft\Windows NT\CurrentVersion\EFS key.
Choose Edit, New, DWORD Value.
Type EfsConfiguration as the name for the new value.
Double-click the EfsConfiguration value and change its value data to 1.
Restart the computer.
To reenable EFS, return to the same value and change it to 0.
NOTE
--------------------------------------------------------------------------------
Intrepid tweakers might come across a check box called Allow Users To Encrypt Files Using Encrypting File System (EFS) and assume that clearing it disables EFS. Unfortunately, this action has no effect in a workgroup environment. If you want to check it out for yourself, open Local Security Settings (Secpol.msc), select Public Key Policies, right-click Encrypting File System, and choose Properties.
Disabling or Reenabling EFS in Windows 2000
If you're using Windows 2000, follow these steps to disable EFS on a computer that is not part of a domain:
Open Local Security Settings. (In Control Panel, open Administrative Tools, Local Security Policy. Or, more simply, type secpol.msc at a command prompt.)
In Local Security Settings, go to Public Key Policies\Encrypted Data Recovery Agents.
Right-click the Administrator certificate and choose Delete.
CAUTION
--------------------------------------------------------------------------------
Before you delete a certificate, be sure you have exported the file recovery certificate and its private key so that the key is available for data recovery. (For details, see "Backing Up the Data Recovery Agent Certificate.") Without it—or another valid data recovery agent certificate, such as one from a domain controller—you won't be able to reenable EFS unless you reinstall Windows 2000.
In response to the confirmation dialog box, click Yes.
This procedure creates an empty recovery policy. When the policy is empty—that is, all the data recovery agent certificates have been deleted—users who attempt to encrypt files will see the error message "There is no valid encryption recovery policy configured for this system."
To reenable EFS after you've set an empty recovery policy, you reinstall the data recovery agent certificate, as follows:
In Local Security Settings, go to Public Key Policies\Encrypted Data Recovery Agents.
Right-click Encrypted Data Recovery Agents, and choose Initialize Empty Policy. (If the command is not on the shortcut menu, you already have an empty policy; skip this step.)
Right-click Encrypted Data Recovery Agents, and choose Add to launch the Add Recovery Agent Wizard. Click Next.
On the Select Recovery Agents page, click Browse Folders and then navigate to the folder that contains the .cer file for the data recovery agent you want to add. (The Browse Directory button searches Active Directory, a feature of Windows 2000 Server-based domains.) Click Open.
Here's where the wizard becomes confusing. The Select Recovery Agents page now shows the new agent as USER_UNKNOWN. This is normal. Simply click Next and then click Finish.
A message appears: "The certificate cannot be validated." Again, this is normal. Click OK.
The certificate for the data recovery agent (with the correct user name shown) now appears in the details pane, and you can begin encrypting files again.
If you want to prevent users from encrypting files on a particular machine, you can disable EFS. If your computer is part of a domain, domain-level policies determine whether EFS can be used on a workstation. For stand-alone computers and computers that are part of a workgroup, the following sections explain how to control the availability of EFS.
Disabling or Reenabling EFS in Windows XP
To disable EFS on a computer running Windows XP Professional that is not part of a domain, follow these steps:
Open Registry Editor. (At a command prompt, type regedit.)
Open the HKLM\Software\Microsoft\Windows NT\CurrentVersion\EFS key.
Choose Edit, New, DWORD Value.
Type EfsConfiguration as the name for the new value.
Double-click the EfsConfiguration value and change its value data to 1.
Restart the computer.
To reenable EFS, return to the same value and change it to 0.
NOTE
--------------------------------------------------------------------------------
Intrepid tweakers might come across a check box called Allow Users To Encrypt Files Using Encrypting File System (EFS) and assume that clearing it disables EFS. Unfortunately, this action has no effect in a workgroup environment. If you want to check it out for yourself, open Local Security Settings (Secpol.msc), select Public Key Policies, right-click Encrypting File System, and choose Properties.
Disabling or Reenabling EFS in Windows 2000
If you're using Windows 2000, follow these steps to disable EFS on a computer that is not part of a domain:
Open Local Security Settings. (In Control Panel, open Administrative Tools, Local Security Policy. Or, more simply, type secpol.msc at a command prompt.)
In Local Security Settings, go to Public Key Policies\Encrypted Data Recovery Agents.
Right-click the Administrator certificate and choose Delete.
CAUTION
--------------------------------------------------------------------------------
Before you delete a certificate, be sure you have exported the file recovery certificate and its private key so that the key is available for data recovery. (For details, see "Backing Up the Data Recovery Agent Certificate.") Without it—or another valid data recovery agent certificate, such as one from a domain controller—you won't be able to reenable EFS unless you reinstall Windows 2000.
In response to the confirmation dialog box, click Yes.
This procedure creates an empty recovery policy. When the policy is empty—that is, all the data recovery agent certificates have been deleted—users who attempt to encrypt files will see the error message "There is no valid encryption recovery policy configured for this system."
To reenable EFS after you've set an empty recovery policy, you reinstall the data recovery agent certificate, as follows:
In Local Security Settings, go to Public Key Policies\Encrypted Data Recovery Agents.
Right-click Encrypted Data Recovery Agents, and choose Initialize Empty Policy. (If the command is not on the shortcut menu, you already have an empty policy; skip this step.)
Right-click Encrypted Data Recovery Agents, and choose Add to launch the Add Recovery Agent Wizard. Click Next.
On the Select Recovery Agents page, click Browse Folders and then navigate to the folder that contains the .cer file for the data recovery agent you want to add. (The Browse Directory button searches Active Directory, a feature of Windows 2000 Server-based domains.) Click Open.
Here's where the wizard becomes confusing. The Select Recovery Agents page now shows the new agent as USER_UNKNOWN. This is normal. Simply click Next and then click Finish.
A message appears: "The certificate cannot be validated." Again, this is normal. Click OK.
The certificate for the data recovery agent (with the correct user name shown) now appears in the details pane, and you can begin encrypting files again.
Recovering Encrypted Data
Recovering Encrypted Data
The security policy for a computer or a domain can include a data recovery policy. (In Windows 2000, a data recovery policy is required.) This policy designates one or more users as data recovery agents; these users can decrypt encrypted files even if the personal encryption certificate used to encrypt the file is no longer available. This capability makes it possible to recover encrypted files after an employee leaves a company, for example.
If your computer is running Windows 2000 and is not part of a Windows domain, the local Administrator account is the default data recovery agent. In Windows XP, stand-alone computers have no default data recovery agent; you should create one. (For details, see Creating a Data Recovery Agent.) In a domain environment, the default data recovery agent is the Administrator account for the domain.
If your computer is a member of a domain, the domain administrator can designate additional users as data recovery agents. Using the domain's Enterprise Certificate Authority, the domain administrator creates file recovery certificates for these users and adds them to Public Key Policies\Encrypted Data Recovery Agents in Local Security Settings or, more likely, in the domain security policy.
Whether your computer is a domain member or in a workgroup, running Windows XP or Windows 2000, best practices suggest not storing the private key associated with the data recovery agent's file recovery certificate on the computer. (If it's stored on the computer, the data recovery agent has access to all users' encrypted files, a situation that removes the privacy protection that EFS is designed to provide.) To restore the data recovery agent's file recovery certificate or private key when it's needed, take these steps:
Log on as Administrator.
Use the Certificates dialog box to import the file recovery certificate. The procedure is the same as that used to import a personal encryption certificate; for details, see Importing a Personal Encryption Certificate.
If you need to recover encrypted files, it might be useful to know who encrypted the files in the first place. With Windows alone, you have no easy way to find out. However, you can use a tool named Efsinfo.exe to show who encrypted each file and who has permission to decrypt it, including any data recovery agents. If you have a Windows XP Professional CD, you can install Efsinfo (along with a number of other useful tools) by running \Support\Tools\Setup on the CD. Efsinfo is also available as a free download from Microsoft; browse to http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/efsinfo-o.asp. (If you prefer to type a shorter URL and don't mind clicking a few links, go to http://www.reskits.com and look for free tools in the Windows 2000 Resource Kit.)
Microsoft Knowledge Base article Q243026 has more information about Efsinfo.
A utility called EFSDump, from the good people at Sysinternals, is available at http://www.sysinternals.com/ntw2k/source/misc.shtml. Like Efsinfo.exe, EFSDump shows who encrypted a file and who has access to it.
The security policy for a computer or a domain can include a data recovery policy. (In Windows 2000, a data recovery policy is required.) This policy designates one or more users as data recovery agents; these users can decrypt encrypted files even if the personal encryption certificate used to encrypt the file is no longer available. This capability makes it possible to recover encrypted files after an employee leaves a company, for example.
If your computer is running Windows 2000 and is not part of a Windows domain, the local Administrator account is the default data recovery agent. In Windows XP, stand-alone computers have no default data recovery agent; you should create one. (For details, see Creating a Data Recovery Agent.) In a domain environment, the default data recovery agent is the Administrator account for the domain.
If your computer is a member of a domain, the domain administrator can designate additional users as data recovery agents. Using the domain's Enterprise Certificate Authority, the domain administrator creates file recovery certificates for these users and adds them to Public Key Policies\Encrypted Data Recovery Agents in Local Security Settings or, more likely, in the domain security policy.
Whether your computer is a domain member or in a workgroup, running Windows XP or Windows 2000, best practices suggest not storing the private key associated with the data recovery agent's file recovery certificate on the computer. (If it's stored on the computer, the data recovery agent has access to all users' encrypted files, a situation that removes the privacy protection that EFS is designed to provide.) To restore the data recovery agent's file recovery certificate or private key when it's needed, take these steps:
Log on as Administrator.
Use the Certificates dialog box to import the file recovery certificate. The procedure is the same as that used to import a personal encryption certificate; for details, see Importing a Personal Encryption Certificate.
If you need to recover encrypted files, it might be useful to know who encrypted the files in the first place. With Windows alone, you have no easy way to find out. However, you can use a tool named Efsinfo.exe to show who encrypted each file and who has permission to decrypt it, including any data recovery agents. If you have a Windows XP Professional CD, you can install Efsinfo (along with a number of other useful tools) by running \Support\Tools\Setup on the CD. Efsinfo is also available as a free download from Microsoft; browse to http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/efsinfo-o.asp. (If you prefer to type a shorter URL and don't mind clicking a few links, go to http://www.reskits.com and look for free tools in the Windows 2000 Resource Kit.)
Microsoft Knowledge Base article Q243026 has more information about Efsinfo.
A utility called EFSDump, from the good people at Sysinternals, is available at http://www.sysinternals.com/ntw2k/source/misc.shtml. Like Efsinfo.exe, EFSDump shows who encrypted a file and who has access to it.
Sharing Your Encrypted Files with Other Users
Sharing Your Encrypted Files with Other Users
A new feature in Windows XP allows you to share access to your encrypted files with one or more trusted users. The users you specify might share the computer with you or have access to the encrypted files over the network.
The only prerequisite for sharing access to an encrypted file is that each user with whom you want to share the file must have an encryption certificate on your computer. The easiest way for a user who shares your computer to create a certificate is for that user to log on and encrypt a file. Network users should export their own certificate (see Exporting a Personal Encryption Certificate); you can then import the certificate to your computer.
TIP
--------------------------------------------------------------------------------
Checking for encryption certificates
To find out whether another user already has an encryption certificate on your computer, use the Certificates snap-in for Microsoft Management Console. (For details, see Using the Certificates Snap-In.) Self-signed certificates, whether created on your computer or imported to your computer, appear in the Trusted People\Certificates folder. Certificates issued by a certification authority (CA) appear in the Other People\Certificates folder. (Note that EFS will not use certificates issued by an untrusted CA.) If Encrypting File System appears in the Intended Purposes column—you might need to enlarge the window or scroll to the right to see the column—you can share your encrypted files with this person.
To enable another user to use one of your encrypted files, follow these steps:
Right-click an encrypted file and choose Properties. On the General tab, click Advanced.
In the Advanced Attributes dialog box, click Details.
NOTE
--------------------------------------------------------------------------------
The Details button is unavailable when you initially encrypt a file. To use this button, you must encrypt the file and then return to the Advanced Attributes dialog box. Note also that the Details button is available only when you display properties for a single file; if you select a folder or multiple files, the button is unavailable.
In the Encryption Details dialog box, click Add. The Select User dialog box appears, as shown in Figure 18-3.
Figure 18-3. You can provide access to any account that has an Encrypting File System certificate on your computer.
Select the name of the user to whom you want to give access, and then click OK.
The users specified in the Encryption Details dialog box now have access to the encrypted file. Of course, they'll also need sufficient NTFS permissions to use the file and, if the file is in a shared network folder, permissions to access the network share.
CAUTION
--------------------------------------------------------------------------------
Grant EFS access only to users you trust. Users who are granted access permissions also can share files with other users of their choosing. The only way you can prevent such sharing is to remove the user's Write permission for the file—but that might prevent the type of access you need.
A new feature in Windows XP allows you to share access to your encrypted files with one or more trusted users. The users you specify might share the computer with you or have access to the encrypted files over the network.
The only prerequisite for sharing access to an encrypted file is that each user with whom you want to share the file must have an encryption certificate on your computer. The easiest way for a user who shares your computer to create a certificate is for that user to log on and encrypt a file. Network users should export their own certificate (see Exporting a Personal Encryption Certificate); you can then import the certificate to your computer.
TIP
--------------------------------------------------------------------------------
Checking for encryption certificates
To find out whether another user already has an encryption certificate on your computer, use the Certificates snap-in for Microsoft Management Console. (For details, see Using the Certificates Snap-In.) Self-signed certificates, whether created on your computer or imported to your computer, appear in the Trusted People\Certificates folder. Certificates issued by a certification authority (CA) appear in the Other People\Certificates folder. (Note that EFS will not use certificates issued by an untrusted CA.) If Encrypting File System appears in the Intended Purposes column—you might need to enlarge the window or scroll to the right to see the column—you can share your encrypted files with this person.
To enable another user to use one of your encrypted files, follow these steps:
Right-click an encrypted file and choose Properties. On the General tab, click Advanced.
In the Advanced Attributes dialog box, click Details.
NOTE
--------------------------------------------------------------------------------
The Details button is unavailable when you initially encrypt a file. To use this button, you must encrypt the file and then return to the Advanced Attributes dialog box. Note also that the Details button is available only when you display properties for a single file; if you select a folder or multiple files, the button is unavailable.
In the Encryption Details dialog box, click Add. The Select User dialog box appears, as shown in Figure 18-3.
Figure 18-3. You can provide access to any account that has an Encrypting File System certificate on your computer.
Select the name of the user to whom you want to give access, and then click OK.
The users specified in the Encryption Details dialog box now have access to the encrypted file. Of course, they'll also need sufficient NTFS permissions to use the file and, if the file is in a shared network folder, permissions to access the network share.
CAUTION
--------------------------------------------------------------------------------
Grant EFS access only to users you trust. Users who are granted access permissions also can share files with other users of their choosing. The only way you can prevent such sharing is to remove the user's Write permission for the file—but that might prevent the type of access you need.
Accessing Encrypted Data on Remote Shares
Accessing Encrypted Data on Remote Shares
You can use your encrypted files (or ones to which you've been granted access, as described in the previous section) when they're stored on another computer in your network. This, of course, makes it feasible for multiple users to access encrypted files, but it has other advantages as well; in particular, storing your network's important documents on a single server can simplify backup of these essential files. You can encrypt and decrypt files that are stored on a network share or, if you're using Windows XP, in a Web Distributed Authoring and Versioning (WebDAV) Web folder.
Using files stored on a network share requires a Microsoft Windows 2000 Server or Microsoft Windows .NET Server domain environment, which places this topic beyond the scope of this book. Don't feel shortchanged, however; despite the otherwise superior security imposed by such domains, remote access to encrypted files on a network share is less secure than using Web folders. When files are stored on a network share, the encryption and decryption are performed on the computer where the files are stored, and the files are transmitted between computers in unencrypted form. When a file is stored in a Web folder, the file remains encrypted during transmission; all encryption and decryption take place at the user's computer.
TIP
--------------------------------------------------------------------------------
Securely share your files over the Internet
Storing an encrypted file in a document folder at MSN Groups (http://groups.msn.com) provides the same security as storing in a local Web folder. You can share your documents with others (or retrieve them yourself from another location), and your encrypted documents remain encrypted when they're transferred across the Internet.
In addition, the use of Web folders for remotely accessing encrypted files is easier to set up and administer. And, if the Web folder is available over the Internet, you can securely access your encrypted files from anywhere in the world with an ordinary Internet connection.
You can set up a Web folder on a server that is running Internet Information Services (IIS) 5 or later. (Windows 2000 includes IIS 5.0; Windows XP Professional includes IIS 5.1.) To set up a Web folder, follow these steps:
Install IIS if you haven't already done so. (For information about installing and securing IIS, see Tightening Security on Internet Information Services.)
Right-click the folder you want to share as a Web folder and choose Properties.
On the Web Sharing tab, select Share This Folder. The Edit Alias dialog box appears:
Specify an alias (the name by which users will access the folder). Select the Read, Write, and Directory Browsing permissions. Select None in the Application Permissions box. Click OK in each dialog box.
Users can then access the Web folder in much the same way as they'd use a local folder. Its URL is http://servername/alias, where servername is the name of the server and alias is the alias you assigned in step 4 of the preceding procedure.
You can use your encrypted files (or ones to which you've been granted access, as described in the previous section) when they're stored on another computer in your network. This, of course, makes it feasible for multiple users to access encrypted files, but it has other advantages as well; in particular, storing your network's important documents on a single server can simplify backup of these essential files. You can encrypt and decrypt files that are stored on a network share or, if you're using Windows XP, in a Web Distributed Authoring and Versioning (WebDAV) Web folder.
Using files stored on a network share requires a Microsoft Windows 2000 Server or Microsoft Windows .NET Server domain environment, which places this topic beyond the scope of this book. Don't feel shortchanged, however; despite the otherwise superior security imposed by such domains, remote access to encrypted files on a network share is less secure than using Web folders. When files are stored on a network share, the encryption and decryption are performed on the computer where the files are stored, and the files are transmitted between computers in unencrypted form. When a file is stored in a Web folder, the file remains encrypted during transmission; all encryption and decryption take place at the user's computer.
TIP
--------------------------------------------------------------------------------
Securely share your files over the Internet
Storing an encrypted file in a document folder at MSN Groups (http://groups.msn.com) provides the same security as storing in a local Web folder. You can share your documents with others (or retrieve them yourself from another location), and your encrypted documents remain encrypted when they're transferred across the Internet.
In addition, the use of Web folders for remotely accessing encrypted files is easier to set up and administer. And, if the Web folder is available over the Internet, you can securely access your encrypted files from anywhere in the world with an ordinary Internet connection.
You can set up a Web folder on a server that is running Internet Information Services (IIS) 5 or later. (Windows 2000 includes IIS 5.0; Windows XP Professional includes IIS 5.1.) To set up a Web folder, follow these steps:
Install IIS if you haven't already done so. (For information about installing and securing IIS, see Tightening Security on Internet Information Services.)
Right-click the folder you want to share as a Web folder and choose Properties.
On the Web Sharing tab, select Share This Folder. The Edit Alias dialog box appears:
Specify an alias (the name by which users will access the folder). Select the Read, Write, and Directory Browsing permissions. Select None in the Application Permissions box. Click OK in each dialog box.
Users can then access the Web folder in much the same way as they'd use a local folder. Its URL is http://servername/alias, where servername is the name of the server and alias is the alias you assigned in step 4 of the preceding procedure.
Using Encrypted Data
Using Encrypted Data
You'll notice no significant difference in working with encrypted folders or files if you're logged on with the same account you used when you encrypted them. In fact, you might forget that you're using encrypted files.
INSIDEOUT
--------------------------------------------------------------------------------
Identifying encrypted files
Because EFS works transparently, knowing which folders and files are encrypted requires a close look. The process of right-clicking each file and then choosing Properties, General, Advanced (followed by Cancel, Cancel) is tedious. Fortunately, you can determine whether a folder or file is encrypted in any of these additional, and easier, ways:
In Windows XP (but not Windows 2000), you can tell at a glance: By default, Windows Explorer displays the names of encrypted objects in green. (If they're not green, you need to set an option. In Windows Explorer, choose Tools, Folder Options. On the View tab, select Show Encrypted Or Compressed NTFS Files In Color. Windows Explorer uses blue for compressed files.)
In Windows Explorer, use Details view. Choose View, Choose Details, and then select Attributes. Encrypted files show the letter E in the Attributes column.
In a Command Prompt window, type cipher with no parameters to display the encryption state of the current folder and its files. Cipher precedes the name of each encrypted file with an E; a U (for unencrypted) identifies other files. To display only specific files (or files in another folder), append a file specification (including wildcards if you like) to the Cipher command line.
To list all encrypted files on all local drives, type cipher /u /n in a Command Prompt window.
Encrypted files differ from unencrypted files in several subtle but important ways:
When you are logged on with an account different from the one you used when you encrypted a file... If you try to open an encrypted file, you get an "access denied" message. Likewise, if you try to decrypt an encrypted file by clearing the encryption attribute, you get an "access denied" message. However, if you have Modify or Full Control permission, you can delete or rename an encrypted file.
When you copy or move an unencrypted file to an encrypted folder... The copy you add to the encrypted folder becomes encrypted.
TIP
--------------------------------------------------------------------------------
You can override the default automatic encryption behavior by configuring a policy. In Group Policy (Gpedit.msc), open Computer Configuration\Administrative Templates\System. Double-click Do Not Automatically Encrypt Files Moved To Encrypted Folders and select Enabled.
When you copy an encrypted file... If you copy an encrypted file to an NTFS volume on your computer or another computer running Windows XP or Windows 2000, it remains encrypted. (If EFS is disabled on the target computer, Windows refuses to copy the file, instead displaying a red-herring "access denied" message.) If you copy an encrypted file to a FAT volume (including floppy disks) or to an NTFS volume on a computer that is running Windows NT, the file becomes decrypted.
When you move an encrypted file... If you move an encrypted file to another folder on the same volume, the file remains encrypted. Moving the file to another volume is essentially a "copy and then delete" process; moving your own encrypted files is handled the same way as the copy operation just described. If you move someone else's encrypted file to a FAT volume, you get an "access denied" message.
When you rename an encrypted file... The file is renamed and it remains encrypted.
When you delete an encrypted file... The restorable file (if you delete to the Recycle Bin) remains encrypted.
When you back up an encrypted file using Windows Backup... You've picked the best way to back up encrypted files or move them between systems! The files in the backup media remain encrypted, whether they're on disk or tape. (Because most removable media can't be formatted as NTFS, an ordinary copy becomes decrypted.)
When you use encrypted files on a different computer... Your personal encryption certificate and its private key must be available on the computer. You can copy the keys manually. For details, see Backing Up Your Certificates. If you use roaming profiles, your encryption keys are automatically available on all computers you log on to with that user account.
CAUTION
--------------------------------------------------------------------------------
Other users with permission to delete a file (that is, users with Modify or Full Control permission) can't use your encrypted files—but they can make them difficult for you to use. Any such user can rename your files, which can make them difficult to find, and also can delete your files. (Even if the user merely deletes them to the Recycle Bin and doesn't remove them altogether, the deleted files are unavailable to you because you don't have access to any other user's Recycle Bin.) Therefore, if you're concerned about protecting your files from other authorized users as well as from a thief who steals your computer, you should modify the NTFS permissions to prevent any type of modification by other users. For more information, see Sharing Documents Securely on a Multiuser Computer.
Like the encryption process, decryption is done transparently. That is, you work with your encrypted files exactly the same way you work with unencrypted files. When Windows detects that a file you're accessing is encrypted, it finds your certificate and uses its private key to decrypt the data as it is read from the disk.
To permanently decrypt a folder or file, clear the Encrypt Contents To Secure Data check box in the Advanced Attributes dialog box. If you decrypt a folder, Windows asks whether you want to decrypt only the folder or the folder and its contents. If you choose the latter option, Windows prohibits you from decrypting any files for which you don't hold a valid encryption certificate. If you change the attribute for a file that you encrypted, Windows decrypts it without further ado. If you attempt to decrypt a file that someone else encrypted, you get an "access denied" message.
You'll notice no significant difference in working with encrypted folders or files if you're logged on with the same account you used when you encrypted them. In fact, you might forget that you're using encrypted files.
INSIDEOUT
--------------------------------------------------------------------------------
Identifying encrypted files
Because EFS works transparently, knowing which folders and files are encrypted requires a close look. The process of right-clicking each file and then choosing Properties, General, Advanced (followed by Cancel, Cancel) is tedious. Fortunately, you can determine whether a folder or file is encrypted in any of these additional, and easier, ways:
In Windows XP (but not Windows 2000), you can tell at a glance: By default, Windows Explorer displays the names of encrypted objects in green. (If they're not green, you need to set an option. In Windows Explorer, choose Tools, Folder Options. On the View tab, select Show Encrypted Or Compressed NTFS Files In Color. Windows Explorer uses blue for compressed files.)
In Windows Explorer, use Details view. Choose View, Choose Details, and then select Attributes. Encrypted files show the letter E in the Attributes column.
In a Command Prompt window, type cipher with no parameters to display the encryption state of the current folder and its files. Cipher precedes the name of each encrypted file with an E; a U (for unencrypted) identifies other files. To display only specific files (or files in another folder), append a file specification (including wildcards if you like) to the Cipher command line.
To list all encrypted files on all local drives, type cipher /u /n in a Command Prompt window.
Encrypted files differ from unencrypted files in several subtle but important ways:
When you are logged on with an account different from the one you used when you encrypted a file... If you try to open an encrypted file, you get an "access denied" message. Likewise, if you try to decrypt an encrypted file by clearing the encryption attribute, you get an "access denied" message. However, if you have Modify or Full Control permission, you can delete or rename an encrypted file.
When you copy or move an unencrypted file to an encrypted folder... The copy you add to the encrypted folder becomes encrypted.
TIP
--------------------------------------------------------------------------------
You can override the default automatic encryption behavior by configuring a policy. In Group Policy (Gpedit.msc), open Computer Configuration\Administrative Templates\System. Double-click Do Not Automatically Encrypt Files Moved To Encrypted Folders and select Enabled.
When you copy an encrypted file... If you copy an encrypted file to an NTFS volume on your computer or another computer running Windows XP or Windows 2000, it remains encrypted. (If EFS is disabled on the target computer, Windows refuses to copy the file, instead displaying a red-herring "access denied" message.) If you copy an encrypted file to a FAT volume (including floppy disks) or to an NTFS volume on a computer that is running Windows NT, the file becomes decrypted.
When you move an encrypted file... If you move an encrypted file to another folder on the same volume, the file remains encrypted. Moving the file to another volume is essentially a "copy and then delete" process; moving your own encrypted files is handled the same way as the copy operation just described. If you move someone else's encrypted file to a FAT volume, you get an "access denied" message.
When you rename an encrypted file... The file is renamed and it remains encrypted.
When you delete an encrypted file... The restorable file (if you delete to the Recycle Bin) remains encrypted.
When you back up an encrypted file using Windows Backup... You've picked the best way to back up encrypted files or move them between systems! The files in the backup media remain encrypted, whether they're on disk or tape. (Because most removable media can't be formatted as NTFS, an ordinary copy becomes decrypted.)
When you use encrypted files on a different computer... Your personal encryption certificate and its private key must be available on the computer. You can copy the keys manually. For details, see Backing Up Your Certificates. If you use roaming profiles, your encryption keys are automatically available on all computers you log on to with that user account.
CAUTION
--------------------------------------------------------------------------------
Other users with permission to delete a file (that is, users with Modify or Full Control permission) can't use your encrypted files—but they can make them difficult for you to use. Any such user can rename your files, which can make them difficult to find, and also can delete your files. (Even if the user merely deletes them to the Recycle Bin and doesn't remove them altogether, the deleted files are unavailable to you because you don't have access to any other user's Recycle Bin.) Therefore, if you're concerned about protecting your files from other authorized users as well as from a thief who steals your computer, you should modify the NTFS permissions to prevent any type of modification by other users. For more information, see Sharing Documents Securely on a Multiuser Computer.
Like the encryption process, decryption is done transparently. That is, you work with your encrypted files exactly the same way you work with unencrypted files. When Windows detects that a file you're accessing is encrypted, it finds your certificate and uses its private key to decrypt the data as it is read from the disk.
To permanently decrypt a folder or file, clear the Encrypt Contents To Secure Data check box in the Advanced Attributes dialog box. If you decrypt a folder, Windows asks whether you want to decrypt only the folder or the folder and its contents. If you choose the latter option, Windows prohibits you from decrypting any files for which you don't hold a valid encryption certificate. If you change the attribute for a file that you encrypted, Windows decrypts it without further ado. If you attempt to decrypt a file that someone else encrypted, you get an "access denied" message.
Encrypting Offline Files
Encrypting Offline Files
The offline files feature, introduced with Windows 2000, allows you to cache a copy of files from a network share on your local computer. This capability is particularly useful for a mobile computer because it allows you to continue working with your files even when your computer is not connected to the network. (When you reconnect to the network, Windows synchronizes the local and network versions of each file.) As we point out, however, mobile computers are the ones most vulnerable to theft, so it would be terrific to be able to encrypt the local versions of your offline files. With Windows XP (but not Windows 2000), you can.
To encrypt your offline files, do the following:
In Windows Explorer, choose Tools, Folder Options.
On the Offline Files tab, shown in Figure 18-2, select both Enable Offline Files and Encrypt Offline Files To Secure Data.
Figure 18-2. When you select this option, the local copy of your offline files is always encrypted, regardless of the files' setting in the network folder.
Using the Cipher Command
Cipher.exe provides a command-line alternative for encrypting and decrypting folders and files. To encrypt or decrypt a folder or file, include the path and the appropriate switches. Use the /E switch to encrypt the folders or files you specify or the /D switch to decrypt them. For example, to encrypt the My Documents folder, including its files and subfolders, type cipher /e /a /s:"%userprofile%\my documents" at a command prompt.
In the file specification, you can use wildcards. You can also specify multiple folders and files in a single instance of the command; simply separate each name with a space. Table 18-1 shows Cipher's command-line switches for basic encryption and decryption operations. Cipher can also generate file encryption keys for users, create file recovery certificates, wipe unused data areas, and perform other tasks. For a complete list, type cipher /? at a command prompt.
Table 18-1. Common Command-Line Switches for Cipher.exe
Switch Description
/E
Encrypts the specified folders
/D
Decrypts the specified folders
/S:folder
Performs the operation on folder and its subfolders (but not on files)
/A
Performs the operation on specified files and files in specified folders
The offline files feature, introduced with Windows 2000, allows you to cache a copy of files from a network share on your local computer. This capability is particularly useful for a mobile computer because it allows you to continue working with your files even when your computer is not connected to the network. (When you reconnect to the network, Windows synchronizes the local and network versions of each file.) As we point out, however, mobile computers are the ones most vulnerable to theft, so it would be terrific to be able to encrypt the local versions of your offline files. With Windows XP (but not Windows 2000), you can.
To encrypt your offline files, do the following:
In Windows Explorer, choose Tools, Folder Options.
On the Offline Files tab, shown in Figure 18-2, select both Enable Offline Files and Encrypt Offline Files To Secure Data.
Figure 18-2. When you select this option, the local copy of your offline files is always encrypted, regardless of the files' setting in the network folder.
Using the Cipher Command
Cipher.exe provides a command-line alternative for encrypting and decrypting folders and files. To encrypt or decrypt a folder or file, include the path and the appropriate switches. Use the /E switch to encrypt the folders or files you specify or the /D switch to decrypt them. For example, to encrypt the My Documents folder, including its files and subfolders, type cipher /e /a /s:"%userprofile%\my documents" at a command prompt.
In the file specification, you can use wildcards. You can also specify multiple folders and files in a single instance of the command; simply separate each name with a space. Table 18-1 shows Cipher's command-line switches for basic encryption and decryption operations. Cipher can also generate file encryption keys for users, create file recovery certificates, wipe unused data areas, and perform other tasks. For a complete list, type cipher /? at a command prompt.
Table 18-1. Common Command-Line Switches for Cipher.exe
Switch Description
/E
Encrypts the specified folders
/D
Decrypts the specified folders
/S:folder
Performs the operation on folder and its subfolders (but not on files)
/A
Performs the operation on specified files and files in specified folders
Encrypting Your Data
Encrypting Your Data
You'll want to encrypt any folders that contain confidential files. The most likely container for such files is your My Documents folder, although you might have documents stored in other folders, too.
To encrypt a folder, follow these steps:
Right-click the folder, choose Properties, click the General tab, and then click the Advanced button. (If the properties dialog box doesn't have an Advanced button, the folder is not on an NTFS-formatted volume and you can't use EFS.)
Select Encrypt Contents To Secure Data.
Click OK twice. If the folder contains any files or subfolders, Windows displays a confirmation message:
NOTE
--------------------------------------------------------------------------------
If you select Apply Changes To This Folder Only in the confirmation dialog box, Windows doesn't encrypt any of the files currently stored in the folder. But any new files that you create in the folder, including files that you copy or move to the folder, will be encrypted.
To encrypt one or more files, follow the same procedure. You'll see a different confirmation message, shown in Figure 18-1, reminding you that the file's folder is not encrypted and giving you an opportunity to encrypt it. It's generally better not to encrypt individual files because the information you intend to protect can too easily become decrypted without your knowledge. For example, with some applications that create a copy of a document you have open for editing, the application saves the copy—which is not encrypted—and deletes the original, encrypted document. Static files that you use for reference only—but that you never edit—can safely be encrypted without encrypting the parent folder. Even in that situation, however, you'll probably find it simpler to encrypt the whole folder.
Figure 18-1. If you encrypt individual files, Windows prods you to encrypt the parent folder as well.
NOTE
--------------------------------------------------------------------------------
Some files can't be encrypted. For example, you can't encrypt any files that have the System attribute. Those files are usually system files, and the system might be rendered unusable if some of its essential files were encrypted. For the same reason, you can't encrypt any files in the %SystemRoot% folder or any of its subfolders. Files in roaming user profiles also can't be encrypted. And files can't be both compressed and encrypted; if you encrypt a compressed file, Windows uncompresses it.
Troubleshooting
--------------------------------------------------------------------------------
Windows reports an "error applying attributes."
If you see a message box similar to the one shown here when you attempt to encrypt a file, EFS has been disabled on your computer. (The text of the message can vary, depending on whether encryption is disabled for a particular folder or for the computer.) Although the four buttons might lead you to believe that you have a choice in the matter, you don't. Regardless of which button you click, Windows refuses to encrypt your files—just as if you had clicked Cancel.
To solve this problem, you need to enable the Encrypting File System. For instructions, see Disabling or Reenabling EFS.
INSIDEOUT
--------------------------------------------------------------------------------
Add encryption commands to shortcut menus
If you frequently encrypt and decrypt files and folders (for most users, it's a one-time "set it and forget it" operation), you'll find that it's rather tedious to right-click, choose Properties, click Advanced, select or clear a check box, and click OK twice every time you want to change encryption status. If you're comfortable using a command-line interface, you can use the Cipher command to perform these tasks. (For details, see Using the Cipher Command.) But if you'd prefer to work with Windows Explorer, you can use an easier way: Add encryption commands to the shortcut menu that appears when you right-click a folder or file.
To do that, follow these steps:
Use Registry Editor to open the HKLM\Software\Microsoft\Windows\ CurrentVersion\Explorer\Advanced key.
Open the Edit menu, and choose New, DWORD Value.
Name the new value EncryptionContextMenu.
Double-click the EncryptionContextMenu value and set its data to 1.
This change takes effect the next time you start Windows Explorer. When you right-click a folder or file that's not encrypted, the shortcut menu includes an Encrypt command; a Decrypt command appears if the target is already encrypted.
You'll want to encrypt any folders that contain confidential files. The most likely container for such files is your My Documents folder, although you might have documents stored in other folders, too.
To encrypt a folder, follow these steps:
Right-click the folder, choose Properties, click the General tab, and then click the Advanced button. (If the properties dialog box doesn't have an Advanced button, the folder is not on an NTFS-formatted volume and you can't use EFS.)
Select Encrypt Contents To Secure Data.
Click OK twice. If the folder contains any files or subfolders, Windows displays a confirmation message:
NOTE
--------------------------------------------------------------------------------
If you select Apply Changes To This Folder Only in the confirmation dialog box, Windows doesn't encrypt any of the files currently stored in the folder. But any new files that you create in the folder, including files that you copy or move to the folder, will be encrypted.
To encrypt one or more files, follow the same procedure. You'll see a different confirmation message, shown in Figure 18-1, reminding you that the file's folder is not encrypted and giving you an opportunity to encrypt it. It's generally better not to encrypt individual files because the information you intend to protect can too easily become decrypted without your knowledge. For example, with some applications that create a copy of a document you have open for editing, the application saves the copy—which is not encrypted—and deletes the original, encrypted document. Static files that you use for reference only—but that you never edit—can safely be encrypted without encrypting the parent folder. Even in that situation, however, you'll probably find it simpler to encrypt the whole folder.
Figure 18-1. If you encrypt individual files, Windows prods you to encrypt the parent folder as well.
NOTE
--------------------------------------------------------------------------------
Some files can't be encrypted. For example, you can't encrypt any files that have the System attribute. Those files are usually system files, and the system might be rendered unusable if some of its essential files were encrypted. For the same reason, you can't encrypt any files in the %SystemRoot% folder or any of its subfolders. Files in roaming user profiles also can't be encrypted. And files can't be both compressed and encrypted; if you encrypt a compressed file, Windows uncompresses it.
Troubleshooting
--------------------------------------------------------------------------------
Windows reports an "error applying attributes."
If you see a message box similar to the one shown here when you attempt to encrypt a file, EFS has been disabled on your computer. (The text of the message can vary, depending on whether encryption is disabled for a particular folder or for the computer.) Although the four buttons might lead you to believe that you have a choice in the matter, you don't. Regardless of which button you click, Windows refuses to encrypt your files—just as if you had clicked Cancel.
To solve this problem, you need to enable the Encrypting File System. For instructions, see Disabling or Reenabling EFS.
INSIDEOUT
--------------------------------------------------------------------------------
Add encryption commands to shortcut menus
If you frequently encrypt and decrypt files and folders (for most users, it's a one-time "set it and forget it" operation), you'll find that it's rather tedious to right-click, choose Properties, click Advanced, select or clear a check box, and click OK twice every time you want to change encryption status. If you're comfortable using a command-line interface, you can use the Cipher command to perform these tasks. (For details, see Using the Cipher Command.) But if you'd prefer to work with Windows Explorer, you can use an easier way: Add encryption commands to the shortcut menu that appears when you right-click a folder or file.
To do that, follow these steps:
Use Registry Editor to open the HKLM\Software\Microsoft\Windows\ CurrentVersion\Explorer\Advanced key.
Open the Edit menu, and choose New, DWORD Value.
Name the new value EncryptionContextMenu.
Double-click the EncryptionContextMenu value and set its data to 1.
This change takes effect the next time you start Windows Explorer. When you right-click a folder or file that's not encrypted, the shortcut menu includes an Encrypt command; a Decrypt command appears if the target is already encrypted.
Before You Begin: Learn the Dangers of EFS
Before You Begin: Learn the Dangers of EFS
EFS provides secure encryption of your most important information. The encryption is so secure that if you lose the key that allows you to decrypt your data, the information is effectively lost. By default, Windows provides no "back door" if your private key is lost, nor is there any practical way to hack these files. (If there were, it wouldn't be very good encryption.)
You can innocently lose your key in a number of ways. Suppose, for example, that you have stored your data in encrypted folders on a second volume (such as drive D). You notice that your computer is running sluggishly and its hard disk is overflowing with junk files—so you decide to reinstall Windows from scratch. Not worrying about your files on another partition, you format drive C and reinstall Windows. Although it's not apparent, reinstalling Windows creates new security identifiers (SIDs) for each user, even if you do everything exactly the same way as the last time you ran Setup. As a result, each user's encryption certificates are also different from the ones they replaced, and they can't be used to access the encrypted data stored on drive D. Even the Administrator account—which also has a new SID—can't decrypt the files from a different Windows installation.
Fortunately, with a little care, you can prevent these drastic scenarios. To learn about EFS and then begin safely using it for your important files, we recommend that you follow this approach:
Create an empty folder and encrypt it. (For details, see the next section, "Encrypting Your Data.")
Create a nonessential file in the encrypted folder (or copy a file to the folder)—and check to see that you can use it just as you would any ordinary file.
If your computer is not part of a domain, create a data recovery agent, a second user account that can be used to decrypt files should your personal encryption certificate become lost or corrupt. (For details, see Creating a Data Recovery Agent. )
Back up your file recovery certificate and your personal encryption certificate along with their associated private keys. (For details, see Backing Up Your Certificates.)
Note that you won't have a certificate to back up until you have encrypted at least one folder or file. A new Windows installation doesn't have encryption certificates; one is created the first time a user encrypts a folder or file.
Begin using EFS for your important confidential files.
In summary: If you encrypt files on a computer that is not joined to a domain, be sure to set up a data recovery agent. Back up both your personal certificate and the data recovery agent's file recovery certificate.
EFS provides secure encryption of your most important information. The encryption is so secure that if you lose the key that allows you to decrypt your data, the information is effectively lost. By default, Windows provides no "back door" if your private key is lost, nor is there any practical way to hack these files. (If there were, it wouldn't be very good encryption.)
You can innocently lose your key in a number of ways. Suppose, for example, that you have stored your data in encrypted folders on a second volume (such as drive D). You notice that your computer is running sluggishly and its hard disk is overflowing with junk files—so you decide to reinstall Windows from scratch. Not worrying about your files on another partition, you format drive C and reinstall Windows. Although it's not apparent, reinstalling Windows creates new security identifiers (SIDs) for each user, even if you do everything exactly the same way as the last time you ran Setup. As a result, each user's encryption certificates are also different from the ones they replaced, and they can't be used to access the encrypted data stored on drive D. Even the Administrator account—which also has a new SID—can't decrypt the files from a different Windows installation.
Fortunately, with a little care, you can prevent these drastic scenarios. To learn about EFS and then begin safely using it for your important files, we recommend that you follow this approach:
Create an empty folder and encrypt it. (For details, see the next section, "Encrypting Your Data.")
Create a nonessential file in the encrypted folder (or copy a file to the folder)—and check to see that you can use it just as you would any ordinary file.
If your computer is not part of a domain, create a data recovery agent, a second user account that can be used to decrypt files should your personal encryption certificate become lost or corrupt. (For details, see Creating a Data Recovery Agent. )
Back up your file recovery certificate and your personal encryption certificate along with their associated private keys. (For details, see Backing Up Your Certificates.)
Note that you won't have a certificate to back up until you have encrypted at least one folder or file. A new Windows installation doesn't have encryption certificates; one is created the first time a user encrypts a folder or file.
Begin using EFS for your important confidential files.
In summary: If you encrypt files on a computer that is not joined to a domain, be sure to set up a data recovery agent. Back up both your personal certificate and the data recovery agent's file recovery certificate.
Using the Encrypting File System
Using the Encrypting File System
The Encrypting File System allows you to encrypt files on an NTFS volume so that only you can use them. This offers a level of protection beyond that provided by NTFS permissions, which you can use to restrict access to your files by others who log on to your computer. NTFS permissions are vulnerable for a couple of reasons. First, all users with administrative privileges can grant themselves (or others) permission to access your files. What's worse, anyone who gains physical access to your computer can boot from a floppy disk (or from another operating system, if your computer is set up for dual booting) and use a utility such as NTFSDOS (available from Sysinternals, http://www.sysinternals.com) to read the files on your hard disk—without having to provide a user name or password. Portable computers, which are more easily stolen, are especially vulnerable to this type of information loss.
TIP
--------------------------------------------------------------------------------
Require a startup password on portable computers
On most computers, you can use BIOS settings to construct another obstacle for anyone who steals your computer. Set your BIOS so that a password is required to start the computer or to enter the BIOS setup program, and set the boot options so that the computer can't be booted from a floppy disk or CD. Unfortunately, this type of protection can also be circumvented. For example, removing the hard disk and installing it in another computer makes its files available to someone with the proper tools.
A much more effective method is to remove the Syskey startup key from the computer. To start the computer, you'll then need to enter a password (or insert a floppy disk that contains the startup key, depending on how you set up Syskey protection) before you can log on. For details about configuring this protection, see Adding Another Layer of Protection with Syskey.
EFS provides a secure way to store your sensitive data. Windows creates a randomly generated file encryption key (FEK) and then transparently encrypts the data using this FEK as data is written to disk. Windows then encrypts the FEK using your public key. (Windows creates a personal encryption certificate with a public/private key pair for you the first time you use EFS.) The FEK is a symmetric key (that is, the same key is used for encrypting and decrypting data), which is orders of magnitude faster than public key encryption. The FEK, and therefore the data it protects, can be decrypted only with your certificate and its associated private key, which are available only when you log on with your user name and password. (Designated data recovery agents can also decrypt your data. For information about data recovery agents, see Recovering Encrypted Data.) Other individuals who attempt to use your encrypted files receive an "access denied" message. Even administrators and others who have permission to take ownership of files are unable to open your encrypted files.
You can encrypt individual files, folders, or entire drives. We recommend that you encrypt folders instead of individual files. If you have hard disk volumes that contain only data (that is, drives other than the system drive and boot drive), consider encrypting the entire drive. When you encrypt a folder or drive, the existing files it contains are encrypted, and new files that you create in the folder or drive are encrypted automatically, as are temporary files that your applications create in the folder or drive. (For example, Microsoft Word creates a copy of a document in the folder where it's stored when you open the document for editing. If the document's folder isn't encrypted, the temporary copy isn't encrypted—giving prying eyes a potential opportunity to view your data.) For this reason, you should also consider encrypting your %Temp% and %Tmp% folders, which many applications use to store temporary copies of documents that are open for editing. (Note, however, that doing so might slow your system considerably, and it might prevent some installation programs from running properly.)
The Encrypting File System allows you to encrypt files on an NTFS volume so that only you can use them. This offers a level of protection beyond that provided by NTFS permissions, which you can use to restrict access to your files by others who log on to your computer. NTFS permissions are vulnerable for a couple of reasons. First, all users with administrative privileges can grant themselves (or others) permission to access your files. What's worse, anyone who gains physical access to your computer can boot from a floppy disk (or from another operating system, if your computer is set up for dual booting) and use a utility such as NTFSDOS (available from Sysinternals, http://www.sysinternals.com) to read the files on your hard disk—without having to provide a user name or password. Portable computers, which are more easily stolen, are especially vulnerable to this type of information loss.
TIP
--------------------------------------------------------------------------------
Require a startup password on portable computers
On most computers, you can use BIOS settings to construct another obstacle for anyone who steals your computer. Set your BIOS so that a password is required to start the computer or to enter the BIOS setup program, and set the boot options so that the computer can't be booted from a floppy disk or CD. Unfortunately, this type of protection can also be circumvented. For example, removing the hard disk and installing it in another computer makes its files available to someone with the proper tools.
A much more effective method is to remove the Syskey startup key from the computer. To start the computer, you'll then need to enter a password (or insert a floppy disk that contains the startup key, depending on how you set up Syskey protection) before you can log on. For details about configuring this protection, see Adding Another Layer of Protection with Syskey.
EFS provides a secure way to store your sensitive data. Windows creates a randomly generated file encryption key (FEK) and then transparently encrypts the data using this FEK as data is written to disk. Windows then encrypts the FEK using your public key. (Windows creates a personal encryption certificate with a public/private key pair for you the first time you use EFS.) The FEK is a symmetric key (that is, the same key is used for encrypting and decrypting data), which is orders of magnitude faster than public key encryption. The FEK, and therefore the data it protects, can be decrypted only with your certificate and its associated private key, which are available only when you log on with your user name and password. (Designated data recovery agents can also decrypt your data. For information about data recovery agents, see Recovering Encrypted Data.) Other individuals who attempt to use your encrypted files receive an "access denied" message. Even administrators and others who have permission to take ownership of files are unable to open your encrypted files.
You can encrypt individual files, folders, or entire drives. We recommend that you encrypt folders instead of individual files. If you have hard disk volumes that contain only data (that is, drives other than the system drive and boot drive), consider encrypting the entire drive. When you encrypt a folder or drive, the existing files it contains are encrypted, and new files that you create in the folder or drive are encrypted automatically, as are temporary files that your applications create in the folder or drive. (For example, Microsoft Word creates a copy of a document in the folder where it's stored when you open the document for editing. If the document's folder isn't encrypted, the temporary copy isn't encrypted—giving prying eyes a potential opportunity to view your data.) For this reason, you should also consider encrypting your %Temp% and %Tmp% folders, which many applications use to store temporary copies of documents that are open for editing. (Note, however, that doing so might slow your system considerably, and it might prevent some installation programs from running properly.)
Using Server Logs
Using Server Logs
IIS maintains log files that you can use to ensure that no unauthorized access to the server is being made. Each access to the server for any type of file creates an entry in the log file. Failed accesses, such as pages that are not found or requests by users who are not authorized to access the server, are logged as well. One user loading a single Web page can create dozens of entries in the log if the page contains images that are also hosted on the server.
To enable logging, open the Internet Information Services console, right-click Default Web Site, and choose Properties. On the Web Site tab, select Enable Logging. To configure logging options, click Properties to display the dialog box shown in Figure 17-13.
Figure 17-13. Enable IIS access logs to ensure that no unauthorized users are using the server.
For small and lightly loaded Web servers, you might be able to simply review the file with Notepad to see whether any suspicious activity has occurred, as shown in Figure 17-14. You can also import the file into Excel using the process described for ICF log files. (See Examining Internet Connection Firewall Logs.) Neither of these approaches is practical for a busier Web server; even one that gets a few thousand accesses a day would be very difficult to analyze this way. Instead, you might want to use a log analysis program. These programs read in the log files for a period of time (day, week, month, or longer) and summarize the accesses by user, page name, directory, or other groupings. You can find a large list of commercial and free log analyzers at http://directory.google.com/Top/Computers/Software/Internet/Site_Management/Log_Analysis/.
Figure 17-14. You can view the IIS log file with Notepad, import it into Excel for further analysis, or use a log file analysis program.
Keeping Up with IIS Security Patches
A poorly maintained Web or FTP server is a disaster waiting to happen. New exploits are constantly being discovered and patched, but your server is protected only if you apply the patches. After you've installed IIS, Windows Update should automatically notify you of new IIS patches and fixes if you have enabled AutoUpdate. Still, it is a good idea to occasionally run the Microsoft Baseline Security Analyzer or Security Hotfix Checker (HFNetChk). For details about these programs, see Testing and Verifying Your Secure Status.
IIS maintains log files that you can use to ensure that no unauthorized access to the server is being made. Each access to the server for any type of file creates an entry in the log file. Failed accesses, such as pages that are not found or requests by users who are not authorized to access the server, are logged as well. One user loading a single Web page can create dozens of entries in the log if the page contains images that are also hosted on the server.
To enable logging, open the Internet Information Services console, right-click Default Web Site, and choose Properties. On the Web Site tab, select Enable Logging. To configure logging options, click Properties to display the dialog box shown in Figure 17-13.
Figure 17-13. Enable IIS access logs to ensure that no unauthorized users are using the server.
For small and lightly loaded Web servers, you might be able to simply review the file with Notepad to see whether any suspicious activity has occurred, as shown in Figure 17-14. You can also import the file into Excel using the process described for ICF log files. (See Examining Internet Connection Firewall Logs.) Neither of these approaches is practical for a busier Web server; even one that gets a few thousand accesses a day would be very difficult to analyze this way. Instead, you might want to use a log analysis program. These programs read in the log files for a period of time (day, week, month, or longer) and summarize the accesses by user, page name, directory, or other groupings. You can find a large list of commercial and free log analyzers at http://directory.google.com/Top/Computers/Software/Internet/Site_Management/Log_Analysis/.
Figure 17-14. You can view the IIS log file with Notepad, import it into Excel for further analysis, or use a log file analysis program.
Keeping Up with IIS Security Patches
A poorly maintained Web or FTP server is a disaster waiting to happen. New exploits are constantly being discovered and patched, but your server is protected only if you apply the patches. After you've installed IIS, Windows Update should automatically notify you of new IIS patches and fixes if you have enabled AutoUpdate. Still, it is a good idea to occasionally run the Microsoft Baseline Security Analyzer or Security Hotfix Checker (HFNetChk). For details about these programs, see Testing and Verifying Your Secure Status.
Encrypting Files and Folders
Encrypting Files and Folders
Throughout this book, we explain various methods for keeping snoops away from your data: password-protected user -accounts, restrictive NTFS permissions, prudent network sharing, firewalls, and so on. But what if, despite your best efforts, your files fall into the wrong hands? This is certainly a risk if you travel with a portable computer—a popular target for thieves. But even offices and homes in low-crime neighborhoods are sometimes burglarized, putting your desktop computers at risk. A stealthier thief—perhaps a coworker or someone who manages to penetrate your computer's defenses through the Internet—can also make off with your files.
Nearly every computer, whether it's in a business or a home, contains some sensitive data that must never be available outside your most trusted circle (or, in some cases, to anyone else at all). In addition to financial data—such as your accounting records or personal finance files—your computer might be the repository for marketing plans, trade secrets, medical history, diaries, address books, and similar information. If someone can obtain a file by downloading it from your computer or by borrowing (or stealing) your portable computer, they know your secrets.
In this chapter, we discuss the Encrypting File System (EFS), a feature of Microsoft Windows XP Professional and Windows 2000 that can prevent the loss of such confidential data. EFS encodes your files so that even if thieves are able to obtain a file, they can't read it. The files are readable only when you log on to the computer with your user account (which, presumably, you have protected with a strong password). In fact, even someone else logging on to your computer won't have access to your encrypted files, which provides protection on systems that are shared by more than one user.
NOTE
--------------------------------------------------------------------------------
EFS is not available on computers running Windows XP Home Edition.
Security Checklist: Encrypting Data
Once you set up EFS, it works silently in the background, requiring no further attention. If you don't implement EFS correctly, however, you can undermine your security efforts. For example, your editing program can leave unencrypted temporary files on your drive. To adequately protect your data and, more important, to avoid permanently and irrevocably locking yourself out of your own folders, be sure to observe these guidelines:
If you use Windows 2000, install Service Pack 2 or the High Encryption Pack to enable 128-bit encryption.
Encrypt a file or folder to create a personal encryption certificate.
Export the personal encryption certificate for each account.
If you use Windows XP, be sure you have a Password Reset Disk. Also consider creating and designating a data recovery agent.
Export and protect the private keys for recovery accounts, and then remove them from the computer. This prevents someone from accessing your files using the data recovery agent account.
Encrypt the My Documents folder and any other local folder you use for storing documents.
Always encrypt folders, not files. When a folder is encrypted, all files created in that folder are encrypted. (Many programs save a new copy of the document you are editing. This copy will be encrypted if you encrypt the folder, but it will be not be encrypted if you encrypt only the original file.)
Don't destroy file recovery certificates and private keys when you change data recovery agent policies. Keep them until you are sure that all the files they protect have been updated.
Configure a policy so that the page file is cleared when you shut down your computer. Otherwise, data from files that were decrypted during a working session might remain in the page file, which a thief could peruse. (For details, see Exploring Security Options).
Disable hibernation (a power-saving option you configure in Control Panel, Power Options). If your system goes into hibernation while encrypted files are open (and therefore decrypted), the data is accessible to a thief who views the Hiberfil.sys file.
NOTE
--------------------------------------------------------------------------------
EFS in Windows XP Professional offers several features that are not available in Windows 2000, the first version of Windows to include EFS support. We note these additional features throughout this chapter, but here's a preview of the significant differences in Windows XP:
You can share your encrypted files with other users you designate.
You can store encrypted files in a shared Web folder on a remote computer.
You can encrypt offline files.
Names of encrypted files and folders are displayed in green in Windows Explorer.
Stronger encryption algorithms are available.
No default data recovery agent is required.
Local administrators can't gain access to your encrypted files by changing your password.
Installing Strong Encryption in Windows 2000
--------------------------------------------------------------------------------
Before you begin relying on EFS to protect your data, you should ensure that your copy of Windows 2000 uses strong encryption. (Strong encryption refers to cryptographic operations that use keys of 128 bits or more.)
All versions of Windows XP have built-in support for strong encryption. However, the original Windows 2000 Professional CD includes only 56-bit encryption—the maximum allowed for export from the United States at the time Windows 2000 was completed. In January 2000—only a few weeks before the retail release of Windows 2000—the U.S. government issued new export regulations allowing companies to ship strong encryption products to almost all countries.
If you haven't already done so, you should upgrade to 128-bit encryption, which provides strong encryption for encrypted files on NTFS volumes; for secure network connections, such as those using Internet Protocol Security (IPSec); and for all other encryption-based services. (To find out whether strong encryption is installed on your computer, search for a file named Rsaenh.dll; the file exists in %SystemRoot%\System32 only if strong encryption has been installed.) You can upgrade to strong encryption in any of these ways:
Install Service Pack 2 (or later) for Windows 2000. We recommend this method because SP2 also includes a large number of security patches, bug fixes, and enhancements.
Install from the High Encryption Floppy Disk included in the Windows 2000 Professional retail package. Run Encpack.exe from the floppy disk.
Download and then install the High Encryption Pack from http://www.microsoft.com/windows2000/downloads/recommended/encryption.
Throughout this book, we explain various methods for keeping snoops away from your data: password-protected user -accounts, restrictive NTFS permissions, prudent network sharing, firewalls, and so on. But what if, despite your best efforts, your files fall into the wrong hands? This is certainly a risk if you travel with a portable computer—a popular target for thieves. But even offices and homes in low-crime neighborhoods are sometimes burglarized, putting your desktop computers at risk. A stealthier thief—perhaps a coworker or someone who manages to penetrate your computer's defenses through the Internet—can also make off with your files.
Nearly every computer, whether it's in a business or a home, contains some sensitive data that must never be available outside your most trusted circle (or, in some cases, to anyone else at all). In addition to financial data—such as your accounting records or personal finance files—your computer might be the repository for marketing plans, trade secrets, medical history, diaries, address books, and similar information. If someone can obtain a file by downloading it from your computer or by borrowing (or stealing) your portable computer, they know your secrets.
In this chapter, we discuss the Encrypting File System (EFS), a feature of Microsoft Windows XP Professional and Windows 2000 that can prevent the loss of such confidential data. EFS encodes your files so that even if thieves are able to obtain a file, they can't read it. The files are readable only when you log on to the computer with your user account (which, presumably, you have protected with a strong password). In fact, even someone else logging on to your computer won't have access to your encrypted files, which provides protection on systems that are shared by more than one user.
NOTE
--------------------------------------------------------------------------------
EFS is not available on computers running Windows XP Home Edition.
Security Checklist: Encrypting Data
Once you set up EFS, it works silently in the background, requiring no further attention. If you don't implement EFS correctly, however, you can undermine your security efforts. For example, your editing program can leave unencrypted temporary files on your drive. To adequately protect your data and, more important, to avoid permanently and irrevocably locking yourself out of your own folders, be sure to observe these guidelines:
If you use Windows 2000, install Service Pack 2 or the High Encryption Pack to enable 128-bit encryption.
Encrypt a file or folder to create a personal encryption certificate.
Export the personal encryption certificate for each account.
If you use Windows XP, be sure you have a Password Reset Disk. Also consider creating and designating a data recovery agent.
Export and protect the private keys for recovery accounts, and then remove them from the computer. This prevents someone from accessing your files using the data recovery agent account.
Encrypt the My Documents folder and any other local folder you use for storing documents.
Always encrypt folders, not files. When a folder is encrypted, all files created in that folder are encrypted. (Many programs save a new copy of the document you are editing. This copy will be encrypted if you encrypt the folder, but it will be not be encrypted if you encrypt only the original file.)
Don't destroy file recovery certificates and private keys when you change data recovery agent policies. Keep them until you are sure that all the files they protect have been updated.
Configure a policy so that the page file is cleared when you shut down your computer. Otherwise, data from files that were decrypted during a working session might remain in the page file, which a thief could peruse. (For details, see Exploring Security Options).
Disable hibernation (a power-saving option you configure in Control Panel, Power Options). If your system goes into hibernation while encrypted files are open (and therefore decrypted), the data is accessible to a thief who views the Hiberfil.sys file.
NOTE
--------------------------------------------------------------------------------
EFS in Windows XP Professional offers several features that are not available in Windows 2000, the first version of Windows to include EFS support. We note these additional features throughout this chapter, but here's a preview of the significant differences in Windows XP:
You can share your encrypted files with other users you designate.
You can store encrypted files in a shared Web folder on a remote computer.
You can encrypt offline files.
Names of encrypted files and folders are displayed in green in Windows Explorer.
Stronger encryption algorithms are available.
No default data recovery agent is required.
Local administrators can't gain access to your encrypted files by changing your password.
Installing Strong Encryption in Windows 2000
--------------------------------------------------------------------------------
Before you begin relying on EFS to protect your data, you should ensure that your copy of Windows 2000 uses strong encryption. (Strong encryption refers to cryptographic operations that use keys of 128 bits or more.)
All versions of Windows XP have built-in support for strong encryption. However, the original Windows 2000 Professional CD includes only 56-bit encryption—the maximum allowed for export from the United States at the time Windows 2000 was completed. In January 2000—only a few weeks before the retail release of Windows 2000—the U.S. government issued new export regulations allowing companies to ship strong encryption products to almost all countries.
If you haven't already done so, you should upgrade to 128-bit encryption, which provides strong encryption for encrypted files on NTFS volumes; for secure network connections, such as those using Internet Protocol Security (IPSec); and for all other encryption-based services. (To find out whether strong encryption is installed on your computer, search for a file named Rsaenh.dll; the file exists in %SystemRoot%\System32 only if strong encryption has been installed.) You can upgrade to strong encryption in any of these ways:
Install Service Pack 2 (or later) for Windows 2000. We recommend this method because SP2 also includes a large number of security patches, bug fixes, and enhancements.
Install from the High Encryption Floppy Disk included in the Windows 2000 Professional retail package. Run Encpack.exe from the floppy disk.
Download and then install the High Encryption Pack from http://www.microsoft.com/windows2000/downloads/recommended/encryption.
Blocking Anonymous Access to IIS
Blocking Anonymous Access to IIS
Most Web servers on the Internet are set up for anonymous access, but that usually isn't the first choice for a Web server running on your own system. If you're the only person planning to use the server, you should disable anonymous access. You don't incur the inconvenience of entering passwords, because when you go to your local Web site (using http://localhost) Internet Explorer automatically logs you in using your current user name and password.
To disable anonymous access in IIS, open the Internet Information Services console. Right-click Default Web Site and choose Properties. On the Directory Security tab, click Edit in the Anonymous Access And Authentication Control box. In the Authentication Methods dialog box, shown in Figure 17-12, clear the Anonymous Access check box.
Figure 17-12. For the best security, disable anonymous access to your IIS server and do not enable Basic Authentication.
Integrated Windows Authentication was previously named NT Challenge Response, and the old name provides a clue to how it works. Instead of a client sending an actual password over the network, the server sends the client a "challenge phrase" consisting of some bytes of data. The server sends a different challenge phrase each time, but the actual content isn't important. The client takes the challenge phrase, modifies it using the password as a key, and then sends the modified challenge phrase back to the server as the response. Meanwhile, the server has performed the same calculation on its end, using the password that it expects from the client. If the response sent by the client matches the server's calculated value, the two must have used the same password to perform the calculation, and permission is granted.
Basic Authentication takes the direct and insecure approach. The user name and password are sent across the network essentially in plain-text form. Anyone with network monitoring software can pick up this information and use it at any time to log in to the server. An attacker can obtain this information in several other ways, even without network monitoring. For example, a proxy server could cache this information and it could be retrieved if the security of the proxy was compromised.
Since Basic Authentication is so insecure, you should avoid turning it on for your server. However, you might encounter situations in which you can't avoid it. Only Internet Explorer supports Integrated Windows Authentication. If you turn off anonymous access to the Web site and don't turn on Basic Authentication, users with browsers other than Internet Explorer will receive the error message "HTTP 401.2 - Unauthorized: Logon failed due to server configuration" when they go to your site. (This is confusing but technically correct; the server configuration issue is the lack of Basic Authentication.)
TIP
--------------------------------------------------------------------------------
Use Internet Explorer's automatic logon feature
If you frequently access an IIS Web server on another system on your local network, you can avoid constantly typing your user name and password, even when you've disabled anonymous access in IIS. On the system running IIS, create a user with the same user name and password as the one you'll be using on the remote system. With its standard default settings, Internet Explorer will then automatically log on using your current user name and password, no prompting required. If you still receive prompts in Internet Explorer, select Tools, Internet Options, Security and select the Local Intranet zone. Click the Sites button and select the Include All Local (Intranet) Sites Not Listed In Other Zones check box. Click OK, and then click the Custom Level button and scroll to the bottom of the list. Under User Authentication, select Automatic Log on Only In Intranet Zone.
Most Web servers on the Internet are set up for anonymous access, but that usually isn't the first choice for a Web server running on your own system. If you're the only person planning to use the server, you should disable anonymous access. You don't incur the inconvenience of entering passwords, because when you go to your local Web site (using http://localhost) Internet Explorer automatically logs you in using your current user name and password.
To disable anonymous access in IIS, open the Internet Information Services console. Right-click Default Web Site and choose Properties. On the Directory Security tab, click Edit in the Anonymous Access And Authentication Control box. In the Authentication Methods dialog box, shown in Figure 17-12, clear the Anonymous Access check box.
Figure 17-12. For the best security, disable anonymous access to your IIS server and do not enable Basic Authentication.
Integrated Windows Authentication was previously named NT Challenge Response, and the old name provides a clue to how it works. Instead of a client sending an actual password over the network, the server sends the client a "challenge phrase" consisting of some bytes of data. The server sends a different challenge phrase each time, but the actual content isn't important. The client takes the challenge phrase, modifies it using the password as a key, and then sends the modified challenge phrase back to the server as the response. Meanwhile, the server has performed the same calculation on its end, using the password that it expects from the client. If the response sent by the client matches the server's calculated value, the two must have used the same password to perform the calculation, and permission is granted.
Basic Authentication takes the direct and insecure approach. The user name and password are sent across the network essentially in plain-text form. Anyone with network monitoring software can pick up this information and use it at any time to log in to the server. An attacker can obtain this information in several other ways, even without network monitoring. For example, a proxy server could cache this information and it could be retrieved if the security of the proxy was compromised.
Since Basic Authentication is so insecure, you should avoid turning it on for your server. However, you might encounter situations in which you can't avoid it. Only Internet Explorer supports Integrated Windows Authentication. If you turn off anonymous access to the Web site and don't turn on Basic Authentication, users with browsers other than Internet Explorer will receive the error message "HTTP 401.2 - Unauthorized: Logon failed due to server configuration" when they go to your site. (This is confusing but technically correct; the server configuration issue is the lack of Basic Authentication.)
TIP
--------------------------------------------------------------------------------
Use Internet Explorer's automatic logon feature
If you frequently access an IIS Web server on another system on your local network, you can avoid constantly typing your user name and password, even when you've disabled anonymous access in IIS. On the system running IIS, create a user with the same user name and password as the one you'll be using on the remote system. With its standard default settings, Internet Explorer will then automatically log on using your current user name and password, no prompting required. If you still receive prompts in Internet Explorer, select Tools, Internet Options, Security and select the Local Intranet zone. Click the Sites button and select the Include All Local (Intranet) Sites Not Listed In Other Zones check box. Click OK, and then click the Custom Level button and scroll to the bottom of the list. Under User Authentication, select Automatic Log on Only In Intranet Zone.
Running the IIS Lockdown Tool
Running the IIS Lockdown Tool
Given all the options that exist for configuring IIS, it can be confusing to determine which are required for your particular needs and which are optional and should be disabled. Fortunately, Microsoft has created a wizard that will walk you through the process of determining which features you need, disabling the features you don't need and setting the security as tight as practically possible. You can read about the wizard (alternately called the Internet Information Services Lockdown Wizard and the IIS Lockdown tool) at http://www.microsoft.com/technet/security/tools/tools/locktool.asp, and you can download it from http://www.microsoft.com/Downloads/Release.asp?ReleaseID=33961.
To use the Internet Information Services Lockdown Wizard, follow these steps:
Run the executable file, Iislockd.exe, from the folder where you downloaded it.
Click Next on the introduction and license agreement pages. The Select Server Template page appears.
Select the template that most closely matches your use of IIS and then click Next.
Select Install URLScan Filter On The Server and click Next. The URLScan feature protects the server from future URL-related exploits that might be uncovered. The Ready To Apply Settings page appears.
Click Next, and the wizard applies appropriate settings, disables unneeded services, and so on. Click Next and then click Finish to close the wizard.
A concise report of the actions taken by the wizard is saved as %SystemRoot%\System32\ Inetsrv\Oblt-rep.log. A more detailed log file is saved in the same folder as Oblt-log.log.
CAUTION
--------------------------------------------------------------------------------
Do not delete the log files. The Internet Information Services Lockdown Wizard uses the Oblt-log.log file to undo its changes if that becomes necessary.
If you have problems accessing IIS after running the wizard, you can undo the changes it made. Just run the wizard again, and it offers to reverse all its modifications, as shown in Figure 17-11, giving you the opportunity to lock down IIS with a different set of options. This behavior is useful because you can select or clear specific options and see whether they are the source of the problem you are experiencing.
Figure 17-11. If something doesn't work right after you run the Internet Information Services Lockdown Wizard, you can undo its changes.
Given all the options that exist for configuring IIS, it can be confusing to determine which are required for your particular needs and which are optional and should be disabled. Fortunately, Microsoft has created a wizard that will walk you through the process of determining which features you need, disabling the features you don't need and setting the security as tight as practically possible. You can read about the wizard (alternately called the Internet Information Services Lockdown Wizard and the IIS Lockdown tool) at http://www.microsoft.com/technet/security/tools/tools/locktool.asp, and you can download it from http://www.microsoft.com/Downloads/Release.asp?ReleaseID=33961.
To use the Internet Information Services Lockdown Wizard, follow these steps:
Run the executable file, Iislockd.exe, from the folder where you downloaded it.
Click Next on the introduction and license agreement pages. The Select Server Template page appears.
Select the template that most closely matches your use of IIS and then click Next.
Select Install URLScan Filter On The Server and click Next. The URLScan feature protects the server from future URL-related exploits that might be uncovered. The Ready To Apply Settings page appears.
Click Next, and the wizard applies appropriate settings, disables unneeded services, and so on. Click Next and then click Finish to close the wizard.
A concise report of the actions taken by the wizard is saved as %SystemRoot%\System32\ Inetsrv\Oblt-rep.log. A more detailed log file is saved in the same folder as Oblt-log.log.
CAUTION
--------------------------------------------------------------------------------
Do not delete the log files. The Internet Information Services Lockdown Wizard uses the Oblt-log.log file to undo its changes if that becomes necessary.
If you have problems accessing IIS after running the wizard, you can undo the changes it made. Just run the wizard again, and it offers to reverse all its modifications, as shown in Figure 17-11, giving you the opportunity to lock down IIS with a different set of options. This behavior is useful because you can select or clear specific options and see whether they are the source of the problem you are experiencing.
Figure 17-11. If something doesn't work right after you run the Internet Information Services Lockdown Wizard, you can undo its changes.
Managing IIS Services
Managing IIS Services
With IIS installed, you will see an Internet Information Services item in Administrative Tools. (In Windows 2000, the item is named Internet Services Administrator, but it's the same thing.) Figure 17-10 shows the Internet Information Services console, which also uses an MMC snap-in.
Figure 17-10. If you've installed the FTP and SMTP services but don't currently use them, stop them in the Internet Information Services console.
Unless you specify otherwise during the installation process, the default IIS configuration installs and enables the Web, FTP, and SMTP services. In most cases, you will be managing the server content through local files or file shares, so you should disable the FTP service unless you are absolutely sure you need it. Your current network usually has an existing SMTP mail server, so you should also disable the SMTP server.
NOTE
--------------------------------------------------------------------------------
Security-conscious Web administrators might discover an IP Address And Domain Name Restrictions box. (Right-click Web Sites, choose Properties, and then click the Directory Security tab.) With IIS running on Microsoft Windows 2000 Server or Microsoft Windows .NET Server, this option lets you choose which remote systems can access the server. However, this option is unavailable through IIS running on Windows XP Professional 2000 or Windows 2000 Professional, and the corresponding Edit button is disabled.
With IIS installed, you will see an Internet Information Services item in Administrative Tools. (In Windows 2000, the item is named Internet Services Administrator, but it's the same thing.) Figure 17-10 shows the Internet Information Services console, which also uses an MMC snap-in.
Figure 17-10. If you've installed the FTP and SMTP services but don't currently use them, stop them in the Internet Information Services console.
Unless you specify otherwise during the installation process, the default IIS configuration installs and enables the Web, FTP, and SMTP services. In most cases, you will be managing the server content through local files or file shares, so you should disable the FTP service unless you are absolutely sure you need it. Your current network usually has an existing SMTP mail server, so you should also disable the SMTP server.
NOTE
--------------------------------------------------------------------------------
Security-conscious Web administrators might discover an IP Address And Domain Name Restrictions box. (Right-click Web Sites, choose Properties, and then click the Directory Security tab.) With IIS running on Microsoft Windows 2000 Server or Microsoft Windows .NET Server, this option lets you choose which remote systems can access the server. However, this option is unavailable through IIS running on Windows XP Professional 2000 or Windows 2000 Professional, and the corresponding Edit button is disabled.
Tightening Security on Internet Information Services
Tightening Security on Internet Information Services
Although neither Windows XP Professional nor Windows 2000 Professional is intended for high-performance server applications, Internet Information Services can do quite well for a light-duty intranet or as a testing server on these systems. (IIS isn't supported on Windows XP Home Edition.) If you're not careful, however, installing IIS on a system can open security holes. Several powerful services are installed by IIS, and if they are not configured or maintained properly, they offer outsiders a way to gain access to and/or control files on the system.
To install IIS, go to Control Panel, Add Or Remove Programs, Add/Remove Windows Components, Internet Information Services. Click Details to select the components you want to install, as shown in Figure 17-9. In Windows 2000, the FTP and SMTP services are selected for installation by default. Whether you use Windows 2000 or Windows XP, however, if you do not need these services, the best security move is to clear the check boxes so they won't be installed. If you're not sure whether you need the services, you can install them now and then disable them until you need them.
Figure 17-9. When installing Internet Information Services, choose only the components you need. Few people need the FTP or SMTP service.
Although neither Windows XP Professional nor Windows 2000 Professional is intended for high-performance server applications, Internet Information Services can do quite well for a light-duty intranet or as a testing server on these systems. (IIS isn't supported on Windows XP Home Edition.) If you're not careful, however, installing IIS on a system can open security holes. Several powerful services are installed by IIS, and if they are not configured or maintained properly, they offer outsiders a way to gain access to and/or control files on the system.
To install IIS, go to Control Panel, Add Or Remove Programs, Add/Remove Windows Components, Internet Information Services. Click Details to select the components you want to install, as shown in Figure 17-9. In Windows 2000, the FTP and SMTP services are selected for installation by default. Whether you use Windows 2000 or Windows XP, however, if you do not need these services, the best security move is to clear the check boxes so they won't be installed. If you're not sure whether you need the services, you can install them now and then disable them until you need them.
Figure 17-9. When installing Internet Information Services, choose only the components you need. Few people need the FTP or SMTP service.
windows services Smart Card; SCardSvr
Smart Card; SCardSvr
Smart Card Helper; SCardDrv
Used to support smart card authentication hardware. If you don't have a smart card that you use to log in to your system, you can keep these two services set to Manual.
SSDP Discovery Service; SSDPSRV
Provides a directory of Universal Plug and Play (UPnP) devices that are available on the network. The Simple Service Discovery Protocol (SSDP) is part of UPnP support in Windows XP. In late 2001, a buffer overflow vulnerability was patched in this service (Microsoft Security Bulletin MS01-059). Because UPnP is sparsely used, you can usually set this service to Manual. However, ICF depends on UPnP to provide incoming connections to systems behind the firewall. If SSDP is disabled, you can't use Remote Desktop and Remote Assistance to access systems across the Internet.
System Event Notification; SENS
Notifies system components and applications of events such as logon, screen saver start, or a switch to battery power. Keep this service set to Automatic.
System Restore Service; srservice
Maintains System Restore checkpoints. On most systems, you should keep this service set to Automatic. If you want to change System Restore behavior, open Control Panel, System and click the System Restore tab. If you turn off System Restore on all drives (which we don't recommend), you could set this service to Manual.
Task Scheduler; Schedule
Runs the programs in the Scheduled Tasks folder based on their schedules. Keep this service set to Automatic.
TCP/IP NetBIOS Helper; LmHosts
Provides NetBIOS name management services in Windows 2000. (See Determining Which Ports Are Active.)
Telephony; TapiSrv
Supports modem connections. If you do not use a modem, you can keep this service set to Manual. However, when used on a system with ICF or ICS running, that service will start the Telephony service.
Telnet; TlntSvr
Provides remote command-line access to the system. This service is a security risk and should be set to Disabled.
Terminal Services; TermService
Supports all of Microsoft's multiple-login and remote access technologies: Windows Terminal Services, Remote Desktop, Fast User Switching, and Remote Assistance. If you do not plan on using any remote access, disable all the features that depend on it and set this service to Manual.
Themes; Themes
Provides support for the new look and feel in Windows XP. This service should be left at Automatic with one possible exception. If you have reverted to the Windows Classic look (Control Panel, Display, Themes) and do not intend to use any of the new user interface features in the future, you can set this service to Manual. (When you do this, the Windows XP theme no longer appears as an option.)
Uninterruptible Power Supply; UPS
Supports the ability of an uninterruptible power supply (UPS) to notify the computer when power has gone out and the UPS battery is running low. This service is used only if you have a UPS, have connected the UPS to the computer via its USB or serial cable, and have configured the UPS Service via Control Panel, Power Options, UPS. In all situations, you can safely keep this service set to Manual.
Universal Plug and Play Device Host; upnphost
Lets the computer perform UPnP announcements on behalf of noncomputer peripherals, such as a printer or a camera. The peripheral must provide the drivers and software to support UPnP; in mid-2002 such devices are virtually nonexistent. It is probably safe to keep this service set to Manual until vendors start to use this feature.
Volume Shadow Copy; VSS
Manages the volume shadow, a feature of Windows XP that backup programs can use to take a snapshot and then back up volumes with open files. This service should be set to Manual.
WebClient; WebClient
Supports the Web-based Distributed Authoring and Versioning (WebDAV) extensions for HTTP. It isn't likely that you use these, so we recommend setting this service to Manual.
Windows Audio; AudioSrv
Supports playing sounds. You should leave this service set to Automatic. You cannot stop the service from the Services console, which is a strong hint that it should always be running.
Windows Image Acquisition (WIA); stisvc
Provides support for scanners and cameras; not required unless you have one of these peripherals. You can keep the service set to Manual, and Windows will start it if necessary.
Windows Installer; MSIServer
Supports installation, repair, and removal of applications that use Windows Installer (.msi) files. The service can be set to Manual, and Windows will start it when needed.
Windows Management Instrumentation; winmgmt
Provides information about the system configuration to third-party applications and in some cases to Windows itself. This service, part of the plumbing of Windows, should remain set to Automatic.
Windows Management Instrumentation Driver Extensions; Wmi
Supplies an interface to the driver, if you have installed a driver that provides Windows Management Instrumentation (WMI) functionality. By default, this service is set to Manual, and you can keep it that way.
Windows Time; W32Time
Provides time synchronization services. Settings for this service are housed in Control Panel, Date And Time, Internet Time. If you plan to set the time on a system manually, you can set this service to Manual. Otherwise, keep it set to Automatic.
Wireless Zero Configuration; WZCSVC
Supports automatic configuration of some brands of 802.11a/b wireless LAN cards. The documentation for your LAN card should indicate whether it uses Wireless Zero Configuration. If it does not, or if you do not have a wireless LAN, set this service to Manual.
WMI Performance Adapter; WmiApSrv
Implements performance counters as part of Windows Management Instrumentation. Keep this service set to Manual.
Workstation; lanmanworkstation
Makes network connections to other servers. Keep this service set to Automatic.
World Wide Web Publishing; w3svc
Provides Web server service, as part of IIS. If you have installed IIS, you should probably have this service set to Automatic so that it will run on startup. Otherwise, you should uninstall IIS.
Smart Card Helper; SCardDrv
Used to support smart card authentication hardware. If you don't have a smart card that you use to log in to your system, you can keep these two services set to Manual.
SSDP Discovery Service; SSDPSRV
Provides a directory of Universal Plug and Play (UPnP) devices that are available on the network. The Simple Service Discovery Protocol (SSDP) is part of UPnP support in Windows XP. In late 2001, a buffer overflow vulnerability was patched in this service (Microsoft Security Bulletin MS01-059). Because UPnP is sparsely used, you can usually set this service to Manual. However, ICF depends on UPnP to provide incoming connections to systems behind the firewall. If SSDP is disabled, you can't use Remote Desktop and Remote Assistance to access systems across the Internet.
System Event Notification; SENS
Notifies system components and applications of events such as logon, screen saver start, or a switch to battery power. Keep this service set to Automatic.
System Restore Service; srservice
Maintains System Restore checkpoints. On most systems, you should keep this service set to Automatic. If you want to change System Restore behavior, open Control Panel, System and click the System Restore tab. If you turn off System Restore on all drives (which we don't recommend), you could set this service to Manual.
Task Scheduler; Schedule
Runs the programs in the Scheduled Tasks folder based on their schedules. Keep this service set to Automatic.
TCP/IP NetBIOS Helper; LmHosts
Provides NetBIOS name management services in Windows 2000. (See Determining Which Ports Are Active.)
Telephony; TapiSrv
Supports modem connections. If you do not use a modem, you can keep this service set to Manual. However, when used on a system with ICF or ICS running, that service will start the Telephony service.
Telnet; TlntSvr
Provides remote command-line access to the system. This service is a security risk and should be set to Disabled.
Terminal Services; TermService
Supports all of Microsoft's multiple-login and remote access technologies: Windows Terminal Services, Remote Desktop, Fast User Switching, and Remote Assistance. If you do not plan on using any remote access, disable all the features that depend on it and set this service to Manual.
Themes; Themes
Provides support for the new look and feel in Windows XP. This service should be left at Automatic with one possible exception. If you have reverted to the Windows Classic look (Control Panel, Display, Themes) and do not intend to use any of the new user interface features in the future, you can set this service to Manual. (When you do this, the Windows XP theme no longer appears as an option.)
Uninterruptible Power Supply; UPS
Supports the ability of an uninterruptible power supply (UPS) to notify the computer when power has gone out and the UPS battery is running low. This service is used only if you have a UPS, have connected the UPS to the computer via its USB or serial cable, and have configured the UPS Service via Control Panel, Power Options, UPS. In all situations, you can safely keep this service set to Manual.
Universal Plug and Play Device Host; upnphost
Lets the computer perform UPnP announcements on behalf of noncomputer peripherals, such as a printer or a camera. The peripheral must provide the drivers and software to support UPnP; in mid-2002 such devices are virtually nonexistent. It is probably safe to keep this service set to Manual until vendors start to use this feature.
Volume Shadow Copy; VSS
Manages the volume shadow, a feature of Windows XP that backup programs can use to take a snapshot and then back up volumes with open files. This service should be set to Manual.
WebClient; WebClient
Supports the Web-based Distributed Authoring and Versioning (WebDAV) extensions for HTTP. It isn't likely that you use these, so we recommend setting this service to Manual.
Windows Audio; AudioSrv
Supports playing sounds. You should leave this service set to Automatic. You cannot stop the service from the Services console, which is a strong hint that it should always be running.
Windows Image Acquisition (WIA); stisvc
Provides support for scanners and cameras; not required unless you have one of these peripherals. You can keep the service set to Manual, and Windows will start it if necessary.
Windows Installer; MSIServer
Supports installation, repair, and removal of applications that use Windows Installer (.msi) files. The service can be set to Manual, and Windows will start it when needed.
Windows Management Instrumentation; winmgmt
Provides information about the system configuration to third-party applications and in some cases to Windows itself. This service, part of the plumbing of Windows, should remain set to Automatic.
Windows Management Instrumentation Driver Extensions; Wmi
Supplies an interface to the driver, if you have installed a driver that provides Windows Management Instrumentation (WMI) functionality. By default, this service is set to Manual, and you can keep it that way.
Windows Time; W32Time
Provides time synchronization services. Settings for this service are housed in Control Panel, Date And Time, Internet Time. If you plan to set the time on a system manually, you can set this service to Manual. Otherwise, keep it set to Automatic.
Wireless Zero Configuration; WZCSVC
Supports automatic configuration of some brands of 802.11a/b wireless LAN cards. The documentation for your LAN card should indicate whether it uses Wireless Zero Configuration. If it does not, or if you do not have a wireless LAN, set this service to Manual.
WMI Performance Adapter; WmiApSrv
Implements performance counters as part of Windows Management Instrumentation. Keep this service set to Manual.
Workstation; lanmanworkstation
Makes network connections to other servers. Keep this service set to Automatic.
World Wide Web Publishing; w3svc
Provides Web server service, as part of IIS. If you have installed IIS, you should probably have this service set to Automatic so that it will run on startup. Otherwise, you should uninstall IIS.
windows services 4
QoS RSVP; RSVP
Provides a mechanism for an application to nicely share bandwidth with other applications. (The name stands for Quality of Service Resource Reservation Protocol.) An application must be QoS-aware for this service to be used; the only common QoS-aware application that ships with Windows is NetMeeting. Leave this service set to Manual.
Remote Access Auto Connection Manager; RasAuto
With a dial-up connection, automatically dials the connection when it detects that a message must be sent to the remote network. Most commonly, this service is used to connect to a dial-up Internet service provider. If you have no dial-up connections (for example, if you use a cable modem or DSL), you can set this service to Disabled.
Remote Access Connection Manager; RasMan
Creates network connections and manages the Network Connections folder. ICF and ICS also require this service. In most cases, it will be running. Leave this service set to Manual so that it will start if needed.
Remote Desktop Help Session Manager; RDSessMgr
Supports the Remote Assistance feature of Windows XP. By default, Remote Assistance is not enabled and must be turned on (Control Panel, System, Remote). Because this feature could be a security risk, the most secure setting is to keep Remote Assistance disabled. If you are not using Remote Assistance, keep this service set to Manual or Disabled.
Remote Procedure Call (RPC); RpcSs
Supports RPC functionality that is used by many components of Windows. Leave this service set to Automatic. If this service is turned off, the computer will not boot.
Remote Procedure Call (RPC) Locator; RpcLocator
Helps other computers on the network find RPC-based programs on this computer. Because this is not a common situation for a workstation, you can usually set this service to Manual with no problem.
Remote Registry; RemoteRegistry
Lets a remote computer modify the Windows registry on your computer. For best security, you should disable this service. Giving this ability to a remote computer is sometimes useful for remote management tasks in a large corporation, but the potential for hard-to-detect abuse is great.
Removable Storage; NtmsSvc
Used to manage offline storage media such as magnetic tapes or CD-RWs. However, this service is not well documented and is totally unused on most systems. You can keep the service set to Manual so that it will start in the rare case in which it is needed. If you're curious, you can see the user interface in the Computer Management console; open Storage\Removable Storage.
Routing and Remote Access; RemoteAccess
Provides support for incoming dial-up and VPN connections. This service should be set to Manual or Disabled unless you want to provide remote access for the network through this computer.
Secondary Logon; seclogon (known as RunAs Service in Windows 2000)
Lets the system start a process under an alternative user account name. This service can be used by Scheduled Tasks or by administrators, and its setting should be left at Automatic.
Security Accounts Manager; SamSs
Manages user name and password information for some applications, along with Protected Storage. Leave this service set to Automatic.
Server; lanmanserver
Supports network file and printer sharing and RPC support. This service should usually be left set to Automatic. To prevent all incoming access to files on this system via file and printer sharing, remove the File And Printer Sharing For Microsoft Networks component from all network connections.
Shell Hardware Detection; ShellHWDetection
Sends information about newly detected hardware to applications, and implements AutoPlay functionality. Keep it at the default setting of Automatic.
Simple Mail Transfer Protocol (SMTP); SMTPSVC
Provides e-mail message transport, as part of IIS. If you do not need this service (and most users do not), you should stop it in the Internet Information Services console and then set it to Manual or Disabled. (Besides being a security risk for your system, an incorrectly configured SMTP server can be hijacked by spammers. You might find your IP address, or even your entire IP address range, placed on several "known to send spam" lists, such as the Realtime Blackhole list at http://mail-abuse.org/rbl/. Many mail servers refuse to accept messages from any server on these lists, as they assume that the messages are spam.)
Provides a mechanism for an application to nicely share bandwidth with other applications. (The name stands for Quality of Service Resource Reservation Protocol.) An application must be QoS-aware for this service to be used; the only common QoS-aware application that ships with Windows is NetMeeting. Leave this service set to Manual.
Remote Access Auto Connection Manager; RasAuto
With a dial-up connection, automatically dials the connection when it detects that a message must be sent to the remote network. Most commonly, this service is used to connect to a dial-up Internet service provider. If you have no dial-up connections (for example, if you use a cable modem or DSL), you can set this service to Disabled.
Remote Access Connection Manager; RasMan
Creates network connections and manages the Network Connections folder. ICF and ICS also require this service. In most cases, it will be running. Leave this service set to Manual so that it will start if needed.
Remote Desktop Help Session Manager; RDSessMgr
Supports the Remote Assistance feature of Windows XP. By default, Remote Assistance is not enabled and must be turned on (Control Panel, System, Remote). Because this feature could be a security risk, the most secure setting is to keep Remote Assistance disabled. If you are not using Remote Assistance, keep this service set to Manual or Disabled.
Remote Procedure Call (RPC); RpcSs
Supports RPC functionality that is used by many components of Windows. Leave this service set to Automatic. If this service is turned off, the computer will not boot.
Remote Procedure Call (RPC) Locator; RpcLocator
Helps other computers on the network find RPC-based programs on this computer. Because this is not a common situation for a workstation, you can usually set this service to Manual with no problem.
Remote Registry; RemoteRegistry
Lets a remote computer modify the Windows registry on your computer. For best security, you should disable this service. Giving this ability to a remote computer is sometimes useful for remote management tasks in a large corporation, but the potential for hard-to-detect abuse is great.
Removable Storage; NtmsSvc
Used to manage offline storage media such as magnetic tapes or CD-RWs. However, this service is not well documented and is totally unused on most systems. You can keep the service set to Manual so that it will start in the rare case in which it is needed. If you're curious, you can see the user interface in the Computer Management console; open Storage\Removable Storage.
Routing and Remote Access; RemoteAccess
Provides support for incoming dial-up and VPN connections. This service should be set to Manual or Disabled unless you want to provide remote access for the network through this computer.
Secondary Logon; seclogon (known as RunAs Service in Windows 2000)
Lets the system start a process under an alternative user account name. This service can be used by Scheduled Tasks or by administrators, and its setting should be left at Automatic.
Security Accounts Manager; SamSs
Manages user name and password information for some applications, along with Protected Storage. Leave this service set to Automatic.
Server; lanmanserver
Supports network file and printer sharing and RPC support. This service should usually be left set to Automatic. To prevent all incoming access to files on this system via file and printer sharing, remove the File And Printer Sharing For Microsoft Networks component from all network connections.
Shell Hardware Detection; ShellHWDetection
Sends information about newly detected hardware to applications, and implements AutoPlay functionality. Keep it at the default setting of Automatic.
Simple Mail Transfer Protocol (SMTP); SMTPSVC
Provides e-mail message transport, as part of IIS. If you do not need this service (and most users do not), you should stop it in the Internet Information Services console and then set it to Manual or Disabled. (Besides being a security risk for your system, an incorrectly configured SMTP server can be hijacked by spammers. You might find your IP address, or even your entire IP address range, placed on several "known to send spam" lists, such as the Realtime Blackhole list at http://mail-abuse.org/rbl/. Many mail servers refuse to accept messages from any server on these lists, as they assume that the messages are spam.)
Inscription à :
Articles (Atom)