As sanitation engineers and quantum physicists have long known, just because you can't see something doesn't mean it isn't there. Even if you have a small organization where everyone gets along with each other and no one would even dream of damaging the system, you need to take precautions.
This brings us to the final leg of the security triad, which is auditing. Any activity involving Windows security objects can be monitored and logged. This can require a lot of work on the part of your servers, so you should choose your auditing points carefully.
This section discusses how to configure auditing, what to audit, when to audit, how to interpret the audit logs, and how to set up systems to notify you in case of an audit warning so you don't constantly have to pore through the logs to see if something unusual happened. It also discusses various third-party products that can help you with auditing and event reporting.
Windows comes with an armada of auditing tools. The majority of these tools rely on monitoring access to security objects such as NTFS files/folders, Registry keys, Active Directory objects, printer objects, and services. As an administrator, you should understand that these monitoring tools look for accesses, not necessarily modifications.
Auditing is a little like putting a nanny monitor in your home. It will tell you that the nanny opened the refrigerator, but it won't tell you if she took any of the leftovers from Cheesecake Factory. Don't expect to use auditing as a compliance enforcement tool. Still, it's better than simply guessing about the origins of a security problem.
When you enable auditing, two services are involved. The Security Reference Monitor reports on events concerning security objects themselves and the LSASS reports on all other security events.
These services write their results into a log called Secevent.evt that is stored in \Windows\System32\Config along with the Registry hives. You can view the contents of the log with the Event Viewer, which can be launched from START | PROGRAMS | ADMINISTRATIVE TOOLS | EVENT VIEWER. You can also open the Event Viewer from the command line by simply typing eventvwr. The Event Viewer displays the log under the name Security.
The default size for an Event log is 512KB, which is too small if you audit many events. The default behavior of the log is to overwrite older entries when the log fills up, which might obscure old sins. You can change these and other log file settings as shown in Procedure 11.10.
Procedure 11.10 Changing Log File Settings
Open the Event Viewer console using START | PROGRAMS | ADMINISTRATIVE TOOLS | EVENT VIEWER.
Right-click the Security Log object and select PROPERTIES from the flyout menu. The Properties window opens.
Change the entry for Maximum Log Size to a value large enough to accommodate several days logging.
Under Event Log Wrapping, set the logging behavior when the log file gets full to Do Not Overwrite Events. You can set a system policy that causes the server to refuse connections if the Security log gets full. Don't forget to save the log and clear it manually every week or so.
Click OK to save any changes and close the Properties window.
You should carefully manage who can access the Security log. A user who can clear the log essentially can wipe fingerprints from the crime scene. The system writes a log entry when someone clears the Security log, so you can ask the person what he was trying to hide, but you lose specifics of the transactions that were recorded.
You can modify Event log configurations as part of a group policy and push them out to member servers. This gives you a standard set of log parameters when you collect your audit information. The group policy can be set for a domain or for an OU containing the computer objects representing the servers. The policies are located under Computer Configuration | Windows Settings | Security Settings | Event Log | Settings for Event Logs. The policies include the following:
Maximum log sizes.
This sets the upper size of each of the Event logs. Be sure to set this at a size that is smaller than the free space available on the drives. Event logs were limited to 4GB in Windows 2000. The limit in Windows Server 2003 is extended to the maximum volume size under NTFS.
Restrict Guest access.
You should never need to enable this policy because you should never enable the Guest account.
Enable this policy when you want to force administrators to periodically save copies of Event logs. It is of little real use in production because it does not automatically archive and empty Event logs.
You should always retain your Security Event logs by selecting the Do Not Overwrite Events option for this policy. It is important that you archive your logs periodically or you will lose the events that occur after the logs fill up.
Shutdown the computer when the Security log is full.
For highly secure environments, you may want to enable this option. It will perform a standard shutdown when the log fills up and only an administrator can start up the server and log on to empty the log. Be very sure to empty the event log periodically if you enable this feature.
Auditing can consume significant system resources so it is not enabled by default. You can enable auditing on a local server or you can set a policy to affect a set of servers in an OU or for an entire domain.
Audit policies are set in group policies under Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy. You can elect to audit for success or failure or both. The following events can be audited:
This monitors network access to a computer via network logon and logoff. This contrasts to local access that is monitored with the Logon Events policy. Set this policy when you want a record of accounts that access a server and what privileges they have been assigned.
This records when an administrator adds, deletes, or modifies the attributes of a security principal. This is especially useful if you have delegated admin permissions to people outside your group and you want to monitor how they are getting along.
Directory Services Access.
This monitors access to Active Directory objects. See the section, "Enabling Object Access Auditing."
This monitors local logon/logoff at the console of a machine. This contrasts with network access, which is monitored with the Account Logon policy. See the sidebar, "Logon/Logoff Audit Errors," for more information.
This monitors access to security objects such as NTFS files/folders and Registry keys. Auditing for Active Directory objects is controlled by the Directory Services Access policy. You must also configure auditing for each file/folder or key you want to monitor. See the section, "Enabling Object Access Auditing."
This monitors for modifications to group policies. You should always enable this policy, because it gives you a record of who might have disabled a policy to hide certain activities.
This monitors privileged access to resources by the system or accounts that have system privileges. For example, only administrators can open the Security log. When you open the Security log, an entry is made in the log under Privilege Use that shows your account name and what you did that exercised a system privilege.
This monitors access to executable code such as EXE, DLL, and OCX files. This is handy for figuring out who is accessing a particular file. It can also help track down viruses, although most virus scanners offer better tools.
This monitors the various system updates that occur during operation. If you're troubleshooting a pesky service that refuses to work for some inexplicable reason, this is a great trace to follow. Used in conjunction with Process Tracking, you can follow the service to see whether it performs an illegal or disallowed activity or asks the system to perform such an activity. The trace also shows you how the various security providers get initialized.
Managing the Event Log with AUDITPOL
The AUDITPOL utility permits you to modify audit settings on individual servers. It does not set Active Directory policies, so it is not as useful as it could be in an enterprise environment, but it is very handy for quickly managing audit policies via a command line.
AUDITPOL controls the following audit policies:
Directory Service Access
The syntax for the command is:
auditpol \\<server_name> /enable /logon:failure
Enabling Object Access Auditing
After Object Access or Directory Service Access auditing is enabled in a group policy, you must enable auditing for the objects you want to monitor. This is done by adding a user or group to the SACL (Security ACL) for the object or objects you're monitoring.
Audit entries are added via START | PROPERTIES | SECURITY | ADVANCED | AUDITING. For Active Directory objects, the Everyone group is added by default for all objects in a domain.
Use caution when enabling auditing because of permission inheritance. You may inadvertently apply the audit entry to the SACL of a large number of files and folders, minimizing the effectiveness of your monitoring and filling the Security log with unnecessary entries.
When you enable Object Access auditing, do so in a policy linked to an OU that contains the computer object you want to monitor. If you do not want to enable auditing on a large number of computers, you can add that specific computer to the ACLs for the policy itself.
When you enable Directory Service Access auditing, do so in a policy linked to the OU that contains the domain controllers.
Applying Group Policy Changes
After you change a security policy, you must refresh the security database so that the policy takes effect. This is done using the GPUPDATE utility. The update performed by GPUPDATE is the same as would happen automatically every five minutes on domain controllers and every 90 to 120 minutes on member computers. There is no need to restart.
After you refresh the audit policies, test them by performing an auditable activity. For example, if you enable Audit Account Logon Events and Audit Logon Events, log on at a member workstation and then access a domain controller via a share point. This should trigger two auditable events, one for the console logon and one for the network access.
If you don't see any entries in the Security log after enabling auditing and running GPUDATE, press F5 or select REFRESH from the console menu. If you still do not get entries, there might be a policy lower in the Active Directory tree that has a No Auditing option set. For more information about troubleshooting group policies, see Chapter 12, "Managing Group Policies."
Before you enable auditing, you should determine exactly what you want to know. This eliminates extraneous log entries and unnecessary load on the servers that must write to the Security log. Here are a few examples of events that you may want to monitor for on a regular basis:
Unauthorized Folder Access
You're concerned that a certain user or group of users are trying to get unauthorized access to a certain folder. Follow the steps in Procedure 11.11.
Procedure 11.11 Monitoring for Unauthorized Folder Access
In AD Users and Computers, create a group called AccessCheck (use whatever group type you've decided to use for ACL entries) and add the suspected users to this group.
For the OU containing the member server, create a new policy called Unauthorized Folder Access Detection.
In the new policy, enable Audit Object Access for Failure.
In the ACLs for the policy, add the AccessCheck group and give it Apply Group Policy permissions. Remove all other groups except for the Administrators group. Give the Administrators Read-Write-Create-Delete but not Apply Group Policy.
Save the policy.
At the server containing the share, open the Properties window for the folder.
Select the Security tab; then, click Advanced and select the Auditing tab.
Add the AccessCheck group to the SACL for this object.
Click OK to save the change.
Run GPUDATE to apply the policy to the server containing the share.
Check the logs periodically to see if the suspected users have attempted to access the folder.
Unauthorized Directory Service Object Access
You're concerned that a certain user is poking around inside Active Directory and trying to make changes. The user does not have permission to make these changes, but you want to make sure he isn't attempting to do so anyway. Follow the steps in Procedure 11.12.
Procedure 11.12 Monitoring Access to Directory Service Objects
Open the Group Policy window for the Domain Controllers OU.
Create a new group policy called Unauthorized DS Access Detection.
In this policy, enable the Audit Directory Service Access policy for Success and Failure.
In the Properties for the policy, add the user's account and give it Apply Group Policy permissions.
Remove the other ACL entries except for Administrators and uncheck the Apply Group Policy from the Administrators group.
Apply the policy using GPUPDATE or wait five minutes for the background refresh.
You want a record of all user logon/logoffs in the domain and, in addition, you want a record of logon/logoff access to a particular server. Follow the steps in Procedure 11.13.
Procedure 11.13 Audit Monitor for Logon/Logoff
In the Default Domain policy, enable the Account Logon and Logon Events policies for Success and Failure.
In the OU that contains the server, create a new policy called Logon Monitoring.
In the new group policy, enable the Account Logon policy for Success and Failure.
In the Security properties for the new group policy, add the name for the server you want to monitor and set the Apply Group Policy permission. Clear the Apply Group Policy permission on all other entries.
Run GPUPDATE on the server or wait 90 to 120 minutes for the background refresh to apply the policy.
Under most circumstances, you can get all the information you need about printing from the System log, which records each print event. You may find yourself wanting to monitor the management of the print queues themselves, though. For instance, you may have someone who is blocking print jobs or deleting the jobs or jockeying them around to get better position in the queue.
You may get a surprise if you use this auditing tool. When a user has a Printer window open, it communicates with the network printer every five seconds. This generates an enormous number of Object Access events on a production print server. Use this audit judiciously. Follow the steps in Procedure 11.14.
Procedure 11.14 Audit Monitoring for Printers
In the OU holding the computer object representing the print server, create a group policy called Printer Monitoring.
In the new policy, enable Object Access auditing for Success and Failure.
Open the Properties window for a printer; select Security and Advanced and then select the Audit tab.
Add the Everyone group to the ACL.
Save the changes and apply the policy using GPUPDATE.
Monitor the Security log on the server for a while to make sure no one left other objects with auditing enabled. This could fill your Security log with extraneous information.
Backup and Restore Monitoring
The ability to back up and restore files is a highly privileged operation. A user with these privileges could conceivably abscond with tons of sensitive information in a highly portable format. Windows 2000/Windows Server 2003 makes the backup privilege even more sensitive because the NTBACKUP utility makes it simple to backup to a file on portable media.
If you have reason to suspect that a user is exercising backup/restore privileges in an unauthorized manner, you can enable the Audit use of backup and restore privilege policy. You should enable this policy for an OU containing the machines you think are the target of this type of activity. The policy is located in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.
Additional System Monitoring
Here are additional recommendations for auditing policies. Remember to increase the size of your Security log to accommodate these entries:
Always monitor for successful and failed logon/logoff activity for the domain and all servers.
Always monitor for failed directory service access.
Always monitor for failed account management events.
Always monitor for failed privilege use.