1. Audit Policy
Audit Policy configures a system to audit categories of
activities. If Audit Policy is not enabled, a server does not audit
those activities. Figure 1
shows the expanded Audit Policy node of a GPO.
To configure auditing, you must define the policy setting.
Double-click any policy setting and select the Define These Policy
Settings check box. Then select whether to enable auditing of Success
events, Failure events, or both. Table 1
defines each audit policy and its default settings on a Windows
Server 2008 R2 domain controller.
Table 1. Audit Policies
|
AUDIT POLICY SETTING |
EXPLANATION |
DEFAULT SETTING FOR WINDOWS SERVER 2008 R2 DOMAIN
CONTROLLERS |
|---|
|
Audit Account Logon Events |
Creates an event when a user or computer attempts
to authenticate using an Active Directory account. For
example, when a user logs on to any computer in the domain, an
account logon event is generated. |
Successful account logons are
audited. | |
Audit Logon Events |
Creates an event when a user logs on
interactively (locally) to a computer or over the network
(remotely). For example, if a workstation and a server are
configured to audit logon events, the workstation audits a
user logging on directly to that workstation. When the user
connects to a shared folder on the server, the server logs
that remote logon. When a user logs on, the domain controller
records a logon event because logon scripts and policies are
retrieved from the DC. |
Successful logons are audited. | |
Audit Account Management |
Audits events, including the creation, deletion,
or modification of user, group, or computer accounts and the
resetting of user passwords. |
Successful account management activities are
audited. | |
Audit Directory Service Access |
Audits events that are specified in the system
ACL (SACL), which is seen in an Active Directory object’s
Properties Advanced Security Settings dialog box. In addition
to defining the audit policy with this setting, you must also
configure auditing for the specific object or objects using
the SACL of the object or objects. This policy is similar to
the Audit Object Access policy used to audit files and
folders, but this policy applies to Active Directory
objects. |
Successful directory service access events are
audited, but few objects’ SACLs specify audit settings. | |
Audit Policy Change |
Audits changes to user rights assignment
policies, audit policies, or trust
policies. |
Successful policy changes are
audited. | |
Audit Privilege Use |
Audits the use of a privilege or user right. See
the explanatory text for this policy in Group Policy
Management Editor (GPME). |
No auditing is performed, by
default. | |
Audit System Events |
Audits system restart, shutdown, or changes that
affect the system or security log. |
Successful system events are
audited. | |
Audit Process Tracking |
Audits events such as program activation and
process exit. See the explanatory text for this policy in
GPME. |
No events are audited. | |
Audit Object Access |
Audits access to objects such as files, folders,
registry keys, and printers that have their own SACLs. In
addition to enabling this audit policy, you must configure the auditing
entries in objects’ SACLs. |
No events are audited. |
Note
DEFAULTS, NOT POLICY
The default settings listed in Table 1 are default settings applied to a
Windows Server 2008 R2 server when it is promoted to a domain
controller. They are not settings that are applied by default Group
Policy objects. If you examine the Default Domain Policy and the
Default Domain Controllers Policy, all audit policy settings are Not
Configured, so these system-level defaults remain intact.
As you can see, most major Active Directory events are already
audited by domain controllers, assuming that the events are
successful. Therefore, the creation of a user, the resetting of a
user’s password, the logon to the domain, and the retrieval of a
user’s logon scripts are all logged.
However, not all failure events are audited by default. You
might need to implement additional failure auditing based on your
organization’s IT security policies and requirements. Auditing
failed account logon events, for example, exposes
malicious attempts to access the domain by repeatedly trying to log on
as a domain user account without yet knowing the account’s password.
Auditing failed account management events can reveal someone
attempting to manipulate the membership of a security-sensitive
group.
One of the most important tasks you must fulfill is to balance
and align audit policy with your corporate policies and reality. Your corporate policy might state
that all failed logons and successful changes to Active Directory
users and groups must be audited. That’s easy to achieve in Active
Directory. But how, exactly, are you going to use that information?
Verbose auditing logs are useless if you don’t know how or don’t have
the tools to manage those logs effectively. To implement auditing, you
must have the business requirement to audit, a well-configured audit
policy, and the tools with which to manage audited events.
2. Auditing Access to Files and Folders
Many organizations elect to audit file system access to provide insight into resource
usage and potential security issues. Windows Server 2008 R2 supports
granular auditing based on user or group accounts and the specific
actions performed by those accounts. To configure auditing, you must
complete three steps: specify auditing settings, enable audit policy,
and evaluate events in the security log.
Specifying Auditing Settings on a File or Folder
You can audit access to a file or folder by adding auditing
entries to its system access control list (SACL).
-
Open the properties dialog box of the file or folder, and
then click the Security tab. -
Click Advanced. -
Click the Auditing tab.
The Advanced Security Settings dialog box of a folder
named Confidential Data is shown Figure 1.
-
To add an entry, click Edit to open the Auditing tab in
Edit mode. -
Click Add to select the user, group, or computer to
audit. -
In the Auditing Entry dialog box shown in Figure 2, indicate the type of
access to audit.
You can audit for successes, failures, or both as the
specified user, group, or computer attempts to access the resource
by using one or more of the granular access levels.
You can audit successes to:
-
Log resource access for reporting and billing. -
Monitor access that would suggest users are performing
actions greater than what you had planned, indicating that
permissions are too generous. -
Identify access that is out of character for a particular
account, which might be a sign that a user account has been
breached by a hacker.
Auditing failed events helps you to:
-
Monitor for malicious attempts to access a resource to
which access has been denied. -
Identify failed attempts to access a file or folder to which a user does require access,
indicating that the permissions are not sufficient to achieve a
business requirement.
Auditing entries instruct Windows to audit the successful or
failed activities of a security principal (user, group, or computer)
to use a specific permission. The example in Figure 1 audits for
unsuccessful attempts by users in the Consultants group to access
data in the Confidential Data folder at any level. It does that by
configuring an auditing entry for Full Control access. Full Control
includes all the individual access levels, so this entry covers any
type of access. If a Consultant group member attempts access of any
kind and fails, the activity is logged.
Typically, auditing entries reflect the permission entries for
the object. In other words, you would configure the Confidential
Data folder with permissions that prevent members of the
Consultants group from accessing its contents. You would then use
auditing to monitor members of the Consultants group who nonetheless
attempt to access the folder. Keep in mind, of course, that a member
of the Consultants group can also belong to another group that does
have permission to access the folder. Because that access will be
successful, the activity is not logged. Therefore, if you are
concerned about keeping users out of a folder and making sure they
do not access it in any way, monitor failed access attempts;
however, also audit successful access to identify situations in
which a user is accessing the folder through another group
membership that is potentially incorrect.
Note
DON’T OVER-AUDIT
Audit logs tend to get quite large quite rapidly, so a best
practice for auditing is to configure the bare minimum required to
achieve the business task. For example, specifying to audit the
successes and failures on an active data folder for the Everyone
group using Full Control (all permissions) would generate enormous
audit logs that could affect the performance of the server and
make locating a specific audited event all but impossible.
Configuring auditing entries in the security descriptor of a
file or folder does not, in itself, enable auditing.
Auditing must be enabled by defining the Audit Object Access setting shown in Figure 3. After auditing is
enabled, the security subsystem begins to pay attention to the audit
settings and to log access as directed by those settings.
The policy setting must be applied to the server that contains
the object being audited. You can configure the policy setting in
the server’s local GPO or use a GPO scoped to the server.
You can define the policy to audit Success events, Failure
events, or both. The policy setting (shown in Figure 3) must specify auditing
of Success or Failure attempts that match the type of auditing entry
in the object’s SACL (shown in Figure 2). For example, to log a
failed attempt by a member of the Consultants group to access the
Confidential Data folder, you must configure the Audit Object Access
policy to audit failures, and you must configure the SACL of the
Confidential Data folder to audit failures. If the resultant audit
policy audits successes only, the failure entries in the folder’s
SACL will not trigger logging.
Note
MAKING SURE AUDIT POLICY MATCHES
AUDITING ENTRIES
Remember that access that is audited and logged is the
combination of the audit entries on specific files and folders and
the settings in Audit Policy. If you’ve configured audit entries to
log failures, but the policy enables only logging for successes,
your audit logs will remain empty.
Evaluating Events in the Security Log
After you have enabled the Audit Object Access policy setting
and specified the access you want to audit, using object SACLs, the
system begins to log access according to the audit entries. You can
view the resulting events in the Security log of the server. Open
the Event Viewer console from Administrative Tools. Expand Windows
Logs\Security.
Tip
Auditing access to objects such as files and folders
requires three components. First, the Audit Object Access policy
must be enabled and configured to audit Success or Failure events
as appropriate for the scenario. Second, the SACL of the object
must be configured to audit successful or failed access. Third,
you must examine the Security log. Audit Policy is often managed
by using a GPO, so the GPO must be scoped to apply to the server
with the file or folder, which is usually a file server rather than a domain controller. Some
exam questions that appear to be testing your knowledge of
auditing are actually testing your ability to scope a GPO with
Audit Policy to the correct servers.
|
