Auditing with Group Policy

Auditing is a powerful tool. It can help you determine when people are doing things they shouldn't, as well as help you determine when people are doing things they should. Either way, you'll use Group Policy to turn on your auditable events. Certain aspects of auditing you'll turn on at the Domain Controller OU level, inside the "Default Domain Controllers Policy" GPO. Other aspects of auditing you'll typically turn on at other OU levels (via a GPO linked to the OU containing the systems you want to audit).

In Figure 6.8, you can see the default auditing settings contained within the "Default Domain Controllers Policy" GPO.

Figure 6.8: Windows 2003 enables lots of auditable events by default.

The list of possibilities for auditing are numerous and confusing. Table 6.1 shows what can be audited , along with where you should perform the audit.

Table 6.1: Auditable Events
Auditing Right	What It Does	Where You Should Set It	Is It On by Default in Windows 2003 Active Directory?	Notes
Audit account logon events	Enters events when someone attempts to log on to Active Directory.	In the "Default Domain Controllers Policy" GPO to monitor when anyone tries to log on to Active Directory.	Yes.	By default, only successes generate events. Settings can be changed to record logon failures as well.
Audit account management	Enters events when someone attempts to create, delete, rename, enable, or disable users, computers, groups, and so on.	In the "Default Domain Controllers Policy" GPO to generate events for when users, computers, and so on are created in Active Directory. Set at the OU level to generate events on file servers for when users and groups are created on member machines.	Yes. Enabled on Domain Controllers, which log Active Directory events only. Not enabled on member servers.	By default, only successful object manipulations generate events. Settings can be changed to record failures as well.
Audit directory service access	Enters events when Active Directory objects are specified to be audited.	In the "Default Domain Controllers Policy" GPO.	Yes. In "Default Domain Controllers Policy" GPO, which will log Active Directory logons and GPO creation, deletion, and modification. See Auditing Group Policy Object changes" section. Not enabled on member servers.	Works in conjunction with the actual attribute in Active Directory that has auditing for users or computers enabled. Can be used to audit other aspects of Active Directory. See "Auditing Group Policy Changes" below.
Audit logon events	Enters events for interactive logon (Local logon) and network logon (Kerberos).	Set at OU level to generate events on servers you want to track access for. Tracks access to files, registry, and other generic objects in the system.	Yes in "Default Domain Controller Policy" GPO, which affects only Active Directory logons.	Set this setting to determine if UserA touches a shared folder on ServerA. This will constitute an auditable event for "Audit logon Events."
Audit object access	Enters events when file objects are specified to be audited.	If you store files on your Domain Controllers, you can set this at the "Default Domain Controllers Policy" GPO. Else, set at the OU level to monitor specific files within member machines.	No.	Works in conjunction with actual file on file server having auditing enabled. See the "Auditing File Access" section.
Audit policy change	Enters events when changes are made to user rights, auditing policies, or trust relationships.	In the "Default Domain Controllers" GPO to monitor when changes are made within Active Directory. Set at OU level to monitor when changes are made on member machines.	Yes. In "Default Domain Controllers Policy" GPO, which affects only Active Directory events.
Audit privilege use	Enters events when any user right is used, such as backup and restore.	In the "Default Domain Controllers Policy" GPO to generate events for when accounts in Active Directory are used. Set at the OU level to generate events on file servers when accounts on member machines are used.	No.
Audit process tracking	Enters events when specific programs or processes are running.	In the "Default Domain Controllers Policy" GPO to affect Domain Controllers. Set at the OU level to monitor processes on specific servers within the OU.	No.	This is an advanced auditing feature that can generate a lot of events once turned on. Only turn this on at the behest of Microsoft PSS or other troubleshooting authority.
Audit system events	Enters events when the system starts up, shuts down, or any time the security or system logs have been modified.	In the "Default Domain Controllers Policy" GPO to determine when Domain Controllers are rebooted or logs have been modified. Set at an OU level to monitor when member machines are rebooted or logs have been modified.	Yes. In "Default Domain Controllers Policy" GPO, which affects only Domain Controllers.

Tip

No matter how much you audit, it does you no good unless you're actually reviewing the logs! There is no way out of the box to centralize the collection of logs from your Domain Controllers, servers, or workstations. Consider a third-party tool, such as Microsoft MOM or Event Log Sentry from www.engagent.com. Microsoft is slated to have its own free, basic audit-log centralization tool called MACS. It might show up in Windows 2003/R2 as an add-on or download.

Auditing Group Policy Object Changes

You might be asked to determine who created a specific Group Policy and when it was created. To that end, you can leverage Active Directory's auditing capability and use Group Policy to audit Group Policy! Whenever a new Group Policy is born, deleted, or modified, various events such as the event in Figure 6.9 are generated.

Figure 6.9: This type of event is generated when GPOs are modified.

These events are generated in Windows 2003 because two things are automatically set up by default in Windows 2003 Active Directory:

Audit Directory Service access is enabled in the "Default Domain Controllers Policy" GPO. You can see this in Figure 6.8, earlier in this chapter.
Auditing is turned on for the "Policies" object container within Active Directory. The Policies folder is where the GPC (Group Policy Container) is stored in Active Directory. Auditing is turned on so that events are generated when anyone creates, destroys, or modifies any objects inside the folder.

To view the Policies container, follow these steps:

Launch Active Directory Users And Computers.
Choose View ˜ Advanced Features. This enables you to see some normally hidden folders and security rights within Active Directory Users And Computers.
Drill down into Domain ˜ System ˜ Policies.
Right-click the Policies folder, and choose the Properties from the shortcut menu to open the Properties dialog box.
Click the Security tab.
Click the Advanced button to open the "Advanced Security Settings for Policies" window.
Click the Auditing tab, which is shown in Figure 6.10.

Figure 6.10: Auditing for GPO changes is set on the Policies folder within Active Directory Users And Computers.

If you drill down even deeper, you'll discover that the "Everyone" group will trigger events when new GPOs are modified or created. It is this interaction that generates events, such as what is seen in Figure 6.9.

Note	If you wanted to hone in on who triggered events (as opposed to the Everyone group) you could remove the Everyone group from being audited (shown in Figure 6.10) and plunk in just the users or groups you wanted to monitor.

Clearly, you can do a lot when creating or modifying a GPO. As you saw in Figure 6.9, the Event ID for GPO Auditing is Event ID number 566. However, there are numerous instances of Event 566, each with information that depends on precisely what you do to the GPO. The bad news is that the audit doesn't show you the GPO's "friendly name "; rather, it shows only the GUID, which is a little disappointing and makes things difficult to track down.

Table 6.2 shows what to expect when looking within Event 566.

Table 6.2: The Contents of Event 566
Action that Occurred	Field to Look For	What It Shows in the Field
Create a new GPO	Accesses	Create Child groupPolicyContainer
Modify a GPO	Properties	Write PropertyDefault property set version-Number gPCMachineExtensionNames group PolicyContainer
Remove a GPO	Access	WRITE_DAC
	Properties	WRITE_DAC groupPolicyContainer
Change GPO status	Properties	Write PropertyDefault property set flags
Remove the "Link Enabled" status or remove the link from an OU	Properties	Write PropertyDefault property set gPLink
Enforce/unenforce a GPO link	Properties	Write PropertyDefault property set gPLink
Block/unblock inheritance on an OU	Object Type	domainDNS
	Properties	Default property set gPOptions organizationalUnit
Change permissions	Properties	WRITE_DAC groupPolicyContainer

Note	Windows 2000 shows these as Event 565, whereas Windows 2003 shows these as Event 566. The "Field to Look For" column and the "What It Shows" column may not be precisely the same for Windows 2000 domains.

Note	Windows 2000 will also pop up Event 643 whenever the "Default Domain Policy" GPO is processed (whether changed or unchanged). You might see a lot of these, and you can safely ignore them.

Auditing File Access

If you want to enable auditing when users attempt to access files on file servers, you need to do the following within Active Directory:

Create an OU.
Move the accounts of those file servers in the OU.
Create a GPO linked to the OU.
Enable the Audit object access policy setting inside the GPO linked to the OU.

Once you do this, you then specify which files or folders on the target file server you wish to audit. To do so, follow these steps:

At the target file server itself, use Explorer to drill down into the drive letter and directory that you want to audit. Right-click the folder (or just one specific file), and choose Properties from the shortcut menu to open the Properties dialog box.
Click the Security tab, and then click the Advanced button to open the "Advanced Security Settings" for the share.
Click the Auditing tab.
Click Add, to pop up the "Auditing Entry" dialog as seen in Figure 6.11. This dialog will allow you to add users to the Auditing entries.

Figure 6.11: Set auditing for files on the file or folder on the target system.

The simplest and most effective entry you can add is the "Everyone" group, as shown in Figure 6.11. When anyone tries to touch the file, you can audit for certain triggers, such as the "Read " permission.