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.
Inscription à :
Articles (Atom)