| Now that we've covered the basics of using the Event Viewer and managing Security Logs, we are going to put this knowledge to use. One of the primary uses of the event logs, specifically the Security log, is to monitor the access of server resources by users and processes. In the current climate of security breaches and what seems like weekly security exploits, it's very important to know who is using your servers and for what purposes. Auditing is the process of recording user and system activities on the network. These events are recorded in the Windows Server 2003 Security Log, which is one of the logs contained in the event log we examined earlier in this chapter. Just about any activity involving a Windows Server 2003 object can be recorded in the Security log. When you configure auditing, you decide what activities, called events, you want to track and against what object. Typical activities that can be tracked are valid or invalid logon attempts, creating or opening files, and changes in user rights. After the audited events are recorded in the Security log, you can use the Event Viewer utility to view and analyze them. In Windows Server 2003, the security descriptor is used to control access to objects. In addition to storing permissions information, a security descriptor also contains auditing information. The portion of the security descriptor that contains this auditing information is known as a System Access Control List (SACL). The SACL is used to specify what attributes of the object are audited and what events associated with the attributes are audited. It is just as important to audit user account-management tasks as it is to audit the accesses of important network resources. The entries saved to the Security log provide the network administrator with a summary of network operations, showing what tasks were attempted and by whom. Not only does this help to detect intrusions by malicious invaders, but the logs can also show more mundane problems, such as careless users who inadvertently delete important files. As shown in Figure 16.17, a typical entry in the Security log shows the following: The time and date the event occurred The event performed The user account that performed the event The success or failure of the event
Figure 16.17. A typical Security log entry showing a failed logon. 
Using Audit Policies To simplify the configuration of auditing, Windows Server 2003 allows you to create an audit policy, which is used to define the events that are recorded in the Windows Server 2003 Security logs. Audit policies are created and applied similar to the other types of policies using the Group Policy snap-ins. Unlike previous versions of Windows, when Windows Server 2003 is first installed, auditing is turned on. By turning on various auditing event categories, you can implement an auditing policy that suits the security needs of your organization. Note: Check for Inheritance Auditing policies are subject to policy inheritance, so the policies that you set on your local computer could be overshadowed by policies set for the domain as a whole.
The first step in creating an audit policy is deciding which events and users should be audited and on which computers. Generally, the audit policies are different depending on the role, or type of computer, that is being audited. For example, the audit policy would most likely be more extensive for a domain controller than for a workstation. In addition, audit policies can be applied at different levels, so you need to decide whether to apply them at the site, the organizational unit, or the domain level. The next step is to decide what attributes of the events you are auditing that you want to track. For example, if you are tracking logon attempts, you must decide if you want to record successful logons, failed logons, or both. As part of this step, you must consider that the more events that are audited, the larger the Security logs become. Although you can configure the Security logs to be larger, this makes it more difficult to find specific events. After you have decided what events to audit, and how you want them audited, you must specify your choices using the Audit Policy container in the Group Policy snap-in. After you have made your choices, you can use the Group Policy snap-in to apply the audit policy to the desired objects. The type of events that can be audited by Windows Server 2003 are separated into the following event categories: Account Logon Events This event is recorded when a domain controller receives a request to validate a user account. This provides the network administrator with a record of user accounts that have logged on to the network, when they logged on, and what privileges they were given. Account Management This event monitors the actions of the network administrator. It records any changes that the administrator makes to the attributes of a user, a group, or a computer account. It also records an event when the administrator creates or deletes an account. This option is of the most use in networks with multiple administrators, especially when you have inexperienced administrators that need to be monitored closely. Directory Service Access This event monitors user access to the Directory Service objects. Auditing has to be turned on for the specific object for this activity to be logged. Logon Events This event monitors logons and logoffs at the local console as well as network connections to the computer. Object Access This event monitors user access to objects on the network, such as files, folders, or printers. Auditing has to be turned on for the specific object for this activity to be logged. Policy Change This event monitors changes in any of the policies that have been applied in the domain. This includes changes to user security options, user rights, and audit policies. This option can be very handy when certain permissions-related operations stop working. You can search back through the log to see if any policies have been changed inadvertently. Privilege Use This event monitors the use of user rights. Typical examples are the administrator viewing or working with the Security log, or a user changing the system time. The entry in the log shows the account name, the time, and exactly which right was used. Process Tracking This event is used to monitor executable files, such as EXE, DLL, and OCX files, and is generally used by programmers who want to track program execution. It can also be used for virus detection. In most cases, better tools are available for doing both tasks. Note: Auditing Is Object Specific The types of events that can be audited for an object are determined by the type of object to be audited. For example, the auditing features for files and directories require the use of an NTFS file system.
System Events This is a catchall event monitor. It is used to track events such as users restarting or shutting down computers, services starting and stopping, and any events that affect overall Windows Server 2003 security. An example of this is if the audit log fills up.
Creating an Audit Policy Audit policies are created using the Group Policy snap-in or from the Active Directory Users and Computers snap-in, if your server is a member of a domain. To create an audit policy, perform the procedure outlined in Step by Step 16.10. Step by Step 16.10 Creating an audit policy for logon failure events 1. | From the Start menu, click Start, All Programs, Administrative Tools, Domain Controller Security Policy.
| 2. | Click Local Policies, Audit Policy. The Audit Policy settings are displayed in the right pane, as you can see in Figure 16.18.
Figure 16.18. The default audit policies available for the domain controller. Note that several are turned on by default. 
| | | 3. | Right-click the Audit Account Logon Events audit policy.
| 4. | The Audit Policy Properties dialog box appears, as shown in Figure 16.19. Select the Define These Policy Settings check box and then select both the Success and the Failure check boxes. This turns on auditing for any logon event.
Figure 16.19. Auditing successful logons is turned on by default. Turn on failure auditing for this exercise. 
| 5. | Click OK to save.
|
|
It is important to remember that for objects, auditing is a two-step process. First, you have to enable the specific auditing category that includes the object you want to audit. Second, you have to enable auditing of specific events on this object from the properties page of the object itself. For example, if you want to audit the access of the Payroll folder on one of your file servers, you must turn on auditing for object access, either at the site, domain, OU, or local level. Next, select the properties page of the folder and enable auditing for that folder. In Step by Step 16.11, we first turn on auditing for object access at the domain level using the Domain Security Policy MMC; then we enable auditing on the Payroll folder. Step by Step 16.11 Creating an audit policy for object access 1. | From the Start menu, click Start, All Programs, Administrative Tools, Domain Security Policy.
| | | 2. | From the Default Domain Security Policy MMC, shown in Figure 16.20, click Local Properties, Audit Policy.
Figure 16.20. Double-click the desired audit policy to configure it. Note that by default, nothing is enabled at the domain level. 
| 3. | The policies in effect for the object are displayed. Double-click the Audit Object Access policy. This opens the Properties dialog box.
| 4. | Under Audit These Attempts, select Define These Policy Settings to enable the policy, and then select the Failure check box. Enabling this will record an entry in the Security log anytime an unauthorized attempt to access an object is made. Click OK to save.
| 5. | Close the Default Domain Security Policy MMC.
| 6. | Open a command window and enter the GPUpdate command. Close the command window.
| 7. | Open either Windows Explorer or My Computer and navigate to the Payroll folder. Right-click the Payroll folder and select Properties.
| 8. | From the resulting Properties dialog box, select the Security tab. From the Security tab, click the Advanced button.
| | | 9. | This opens the Advanced Security Settings dialog box. Select the Auditing tab, shown in Figure 16.21.
Figure 16.21. The Auditing tab displays the type of auditing enabled, who it applies to, whether it was inherited, and from where. 
| 10. | On the Auditing tab, click the Add button. From the Select User or Group dialog box that appears, enter the user or group for which you would like to track access to the resource. If you don't know the exact name, you can click the Advanced button to browse for a user or group name. Click OK when you're finished.
| | | 11. | The Auditing Entry dialog box appears, as shown in Figure 16.22. Notice that you can select from a variety of events for success, failure, or both. In addition, you have the option to apply the auditing settings to the folder only, the folder and its files, and a variety of other options. This turns on auditing for any logon event.
Figure 16.22. The Auditing Entry dialog box allows you to select both the events and the objects on which to enable auditing. 
| 12. | Click OK three times to save.
|
|
When you're defining your audit policy, it is important to know what you plan to do with all the data that is collected. If you are using the audit policy for resource planning, you might want to increase the log size so that you can store data for a longer length of time, or you can archive logs from time to time so that you can keep an ongoing record of system and resource usage. Exam Alert: Have a Good Understanding of Auditing With the heavy emphasis that Microsoft has been putting on security, you should expect to see at least one, if not more, security-related auditing questions on the exam.
Always audit the files and folders that contain sensitive data, while ignoring common files that most users access regularly. Quantity of data does not always equal quality of data. In addition, auditing does create overhead, both in processing time and disk space. The Everyone group should be used to audit resource access instead of using the Users group. Remember that most user accounts are added to the Everyone group by default. However in Windows Server 2003, the Everyone group no longer includes anonymous users. Don't forget to audit all administrative tasks performed by the administrative groups. This allows you to spot problems created by inexperienced administrators. In addition, the Administrator account is a favorite target for intruders. By monitoring the administrative accounts, you should be able to spot the erratic activity that is common to an improperly trained or unauthorized user. Challenge In the world we live in today, security has become a major concern. A good system administrator must not only be wary of threats from the outside, but must also guard against inside threats. Recent statistics have shown that a server is more likely to be attacked from inside the firewall than from the outside. Some parts of your network need to be more secure than others. For example, anything that has to do with trade secrets, proprietary company information, or employee data should have the strongest security applied. But how do you know whether your security measures are effective? Are you suffering from a false sense of security? (No pun intended!) What types of tools are included in Windows Server 2003 that can reassure you? On your own, try to develop a strategy to address this type of issue. If you would like to see a possible solution, follow the next steps. Estimated Time: 20 minutes One way to attack this problem is to turn on auditing for specific files and folders. A good practice is to always audit the files and folders that contain sensitive data, while ignoring common files that most users access regularly. On the server that contains the objects you want to audit, follow these steps: 1. | From the Start menu, click Start, All Programs, Administrative Tools, Local Security Policy.
| 2. | From the Local Security Policy MMC, click Local Properties, Audit Policy.
| 3. | The policies in effect for the object are displayed. Double-click the Audit Object Access policy; this opens a Properties dialog box.
| 4. | Under Audit These Attempts, select the Failure check box. Click OK to save.
| 5. | Close the Local Security Policy MMC.
| 6. | Open either Windows Explorer or My Computer and navigate to the folder that you want to audit. Right-click the folder and select Properties.
| 7. | From the resulting Properties dialog box, select the Security tab. From the Security tab, click the Advanced button.
| 8. | This opens the Advanced Security Settings dialog box. Select the Auditing tab.
| 9. | The Auditing tab displays the type of auditing enabled, who it applies to, whether it was inherited, and from where. On the Auditing tab, click the Add button.
| 10. | From the Select User or Group dialog box that appears, enter the user or group for which you want to track access to the resource. For security auditing, select the Everyone group. Click OK when you're finished.
| 11. | The Auditing Entry dialog box appears. Notice that you can select from a variety of events for success, failure, or both. In addition, you have the option to apply the auditing settings to the folder only, to the folder and its files, and a variety of other options.
| 12. | Click OK three times to save.
|
|
Exam Alert: Logon Auditing When a user logs on to a domain where auditing is enabled, the authenticating domain controller will log an event in its security log. It is likely that multiple domain controllers have authenticated the user at different timestherefore, you must examine the security log on each domain controller. In Event Viewer, you can set various filters to simplify the search for information.
|
