Setting Up an Audit Policy
Part 2 of Brien Poseys series on setting up audit policies, an essential element in your Windows 2000 security arsenal.
In Part 1 of this series ( Creating an Audit Policy ), I discussed some of the issues to consider when setting up an audit policy in Windows 2000. In this article, I'll continue the discussion by demonstrating the actual process of setting up an audit policy.
Events to Audit
- Account Login--An event that's triggered when a domain controller receives a login request. You can audit an account login based upon successful logins or login failures.
- Account Management--Pertains to any sort of maintenance to user accounts. For example, if a user creates, renames, or deletes a user account, an event can be logged. Other types of Account Management events include changing passwords, or enabling or disabling user accounts.
- Directory Service Access--A very general category. Basically, it refers to any time a user changes an Active Directory object. However, as you'll see later in the series, there are many different ways to audit this type of event.
- Logon Events--It may seem that Logon Events are the same as Account Logins, but the two are separate. Login Events refer to any time any user logs in or out of the system. In some situations, Login Events may also be triggered when a user connects to or disconnects from a computer on the network.
- Object Access--It's easy to confuse Directory Service Access and Object Access. However, whereas the Directory Service Access events log the way that users access Active Directory objects, Object Access tracks the way that users access physical objects such as files, folders, and printers. When establishing an audit policy for Object Access events, it's important to remember that you can't simply set up a generic policy that logs every event for every object. Windows 2000 requires you to audit specific objects, such as a specific directory or printer.
- Policy Change--Perhaps one of the most important types of event category. These events are triggered when someone makes a change to your security policies. These changes may include anything from changing user rights to changing audit policies.
- Privilege Use--As you may know, in Windows 2000 it's possible to relieve yourself of some administrative burden by delegating certain rights to others. For example, you might allow the help desk to reset passwords. However, just because you give someone permission to perform a high-level function doesn't mean you should completely turn your back on them. The Privilege Use category of events can be used to make an event log entry any time that someone uses one of the special rights you've assigned to them.
- Process Tracking--The Process Tracking set of events isn't generally of much use when it comes to security. Generally, it's geared more to programmers and administrators who want to know what resources a program is using and why that program keeps crashing.
- System Events--Events going on within the physical system. For example, you can log each time a server (or workstation) is shut down or restarted. A system event can also be triggered if the security log fills up.
Setting Up an Audit Policy
The method you'll use to create an audit policy will vary slightly depending on whether you're creating the policy on a member server, a domain controller, or a stand-alone server. However, you'll use the same basic tools in each case. All the methods use security-related Microsoft Management Console (MMC) snap-ins. The main difference is that if you're configuring a domain controller, member server, or workstation, you'll use the Active Directory Users and Computers snap-in. If you're configuring a system that doesn't participate in a domain, you'll use the Local Security Settings snap-in.