A major part of securing a Windows 2000 network is determining who accessed specific resources or who performed specific actions on the network. Auditing lets an administrator track these events in the Security Log of the Windows 2000 Event Viewer.
After this lesson, you will be able to
- Design an audit strategy that will allow inspection of critical events for Windows 2000–based computers in your organization
Estimated lesson time: 30 minutes
Configuring Audit Settings
Within Windows 2000 you can configure several auditing settings. In some cases all you have to do is configure the audit settings within the audit policy shown in Figure 2.16. In other cases, such as object access or directory service access, you have to also indicate which individual objects will be included in the audit.
Figure 2.16 Configuring audit settings
The audit policies that can be defined for a domain include
- Audit Account Logon Events. Occurs any time a user logs on to a computer. If the user logs on to the local computer, the event is recorded in the computer's audit log. If the user logs on to a domain, the authenticating domain controller records the account logon event.
- Audit Account Management. Occurs whenever a user creates, changes, or deletes a user account or group. It also occurs when a user account is renamed, disabled, or enabled, or a password is set or changed.
- Audit Directory Service Access. Occurs whenever a user gains access to an Active Directory object. To log this type of access, you must configure specific Active Directory objects for auditing.
- Audit Logon Events. Recorded any time a user authenticates with the local computer or with Active Directory. This includes physically logging on at a computer or establishing a network connection to the computer.
- Audit Object Access. Logged any time a user gains access to a file, folder, or printer. The administrator must configure specific files, folders, or printers for auditing.
- Audit Policy Change. Occurs any time local policies are changed in Group Policy. This includes user rights, audit policy, or security options.
- Audit Privilege Use. Occurs any time a user exercises a user right, such as changing the system time, or any time an administrator takes ownership of a file.
- Audit Process Tracking. Occurs any time an application performs an action. This setting is used to determine which files and registry keys an application requires access to when operating.
- Audit System Events. Occurs any time a server is restarted or shut down. It also occurs any time the security log is reset on the computer.
Making the Decision
By defining audit settings within Active Directory by using Group Policy, you can ensure that the desired settings are maintained forest-wide. This ensures that users are unable to change their audit settings locally in an attempt to keep from viewing the security log.
When you define your audit strategy, you must consider the following design points:
- Determine where to apply the audit settings. As with all Group Policy, you can define audit settings locally, at the site level, at the domain level, or at individual OUs. As with all Group Policy, the audit policies will be applied in the following order:
- If audit policy is defined at the local computer, these audit settings will be applied first to the local computer.
- If audit policy is defined at the site level, these audit settings are applied.
- If audit policy is defined at the domain, these audit settings are applied.
- If audit policy is defined at the first level of OUs, these audit settings are applied.
- Any audit policies defined at any of the child OUs will be applied until the audit policy defined at the actual OU where the computer object is located will be applied.
- Define DC auditing settings in the Domain Controllers OU. By default, all DCs are located in the Domain Controllers OU. By defining auditing settings to the Domain Controllers OU, you ensure that consistent auditing is performed across all DCs in a domain.
- Collect computers with similar audit requirements into common OUs. By grouping computer accounts into common OUs, you can apply the required audit policy settings at the OU level.
- Do not audit all events. The more auditing that you configure, the more audit events will fill the event log with unnecessary data. It's essential that you select only the events that are important to your auditing needs.
The configuration of auditing also includes increasing the default size of the security log from 512 K. When auditing is enabled, you can be sure that you will require more space than the default size. The actual size must be set based on the amount of data that will be included in the auditing configuration. These settings can be configured for DCs in the Default Domain Con trollers Policy in the Computer Configuration\Windows Settings\Security Settings\Event Log\Settings for Event Logs.
- Determine the appropriate mix of failure and success audits to meet your security requirements. Include failure audits in your audit strategy to detect intrusion attempts before they are successful, catch intruders before they cause damage to the network, and detect internal users attempting tasks that they're not authorized to perform. Include success audits to determine whether an attacker is successful in an intrusion attempt and to determine if excess privileges are assigned to a security principal.
- Define your audit strategy to match the organization's risk level. The lower the risk level that the organization is comfortable with, the more events you include in the audit strategy. For example, a lower-security network might audit only failed logon attempts, while a higher-security network might choose to audit both successful and failed logon attempts.
Applying the Decision
Because the current network deployment at Wide World Importers is concerned only with internal network auditing, you can put less emphasis on auditing for external attacks and more emphasis on maintaining security.
As mentioned earlier, you generally use failure auditing to determine if attacks are attempted and success auditing to reveal when actual intrusions or security breakdowns have taken place.
As a starting point for auditing, Table 2.1 outlines a common auditing structure that organizations use to ensure that the security log contains any attempts at intrusion:
Table 2.1 A Proposed Auditing Structure for Wide World Importers
|Policy ||Success ||Failure |
|Audit account management ||X ||X |
|Audit account logon events || ||X |
|Audit directory service access || || |
|Audit logon events || || |
|Audit object access ||X ||X |
|Audit policy changes ||X ||X |
|Audit privilege use || || |
|Audit process tracking || || |
|Audit system events ||X ||X |
These auditing settings provide the following information in the security log:
- All account management tasks are audited. This allows the network administrator to determine when user accounts were created, modified, or deleted and who performed the task.
- Auditing account logon event failures helps determine if failed logon attempts are occurring. This identifies any attempted break-in attempts by logging all failed logons. If you raise the security requirements, you could also include success events to determine if a break-in attempt is successful.
- Assuming that there are files that Wide World Importers might want to audit for usage, you must enable both success and failure auditing for object access. This allows you to determine who is accessing a file or folder object. This setting also requires that the file or folder is stored on an NT file system (NTFS) volume and that auditing is enabled on the Advanced tab for the object.
- Auditing success and failure events for policy changes ensures that any changes to the audit policy will be recorded in the audit logs.
- Auditing success and failure for system events detects any attempts to restart the server. The events record who attempted to restart the server and when the restart event took place.
You must define an audit strategy for your organization. Your decision on what audit settings to deploy balances the information that you require from auditing and the effect on performance and resource usage that the auditing requires.