3. Auditing Directory Service Changes
Just as the Audit Object Access policy allows you to log
attempts to access objects such as files and folders, the Audit Directory Service Access policy allows you to log
attempts to access objects in Active Directory. The same basic principles apply. You
configure the policy to audit Success or Failure. You then configure
the SACL of the Active Directory object to specify the types of access
you want to audit.
As an example, if you want to monitor changes to the membership
of a security-sensitive group such as Domain Admins, you can enable
the Audit Directory Service Access policy to audit Success events. You
can then open the SACL of the Domain Admins group and configure an
auditing entry for successful modifications of the group’s
member attribute. In fact, in Windows Server 2008
and later, the default configuration is to audit Success events for
Directory Service Access, and to audit all changes to the Domain
Admins group. You will see this in an exercise in this lesson’s
practice.
In Microsoft Windows Server 2003 and Windows 2000 Server, you
could audit directory service access and be notified that an object,
or the property of an object, had been changed, but you could not
identify the previous and new values of the attribute that had
changed. For example, an event could be logged indicating that a
particular user changed an attribute of Domain Admins, but you could
not easily identify which attribute was changed, and there was no way
to determine from the audit log exactly what change was made to that
attribute.
Windows Server 2008 added an auditing category called Directory
Service Changes. The important distinction between Directory Service
Changes and Directory Service Access is that with Directory Service
Changes auditing, you can identify the previous and current values of
a changed attribute.
Enabling Directory Service Changes Auditing
Directory Service Changes is not enabled by default. Instead,
Directory Service Access is enabled to mimic the auditing
functionality of previous versions of Windows. To enable auditing of
successful Directory Service Changes, open Command Prompt on a
domain controller and type this command:
auditpol /set /subcategory:"directory service changes" /success:enable
Tip
The auditpol command enables auditing
of directory service changes.
Although you can use the preceding command to enable Directory
Service Changes auditing in a lab and explore the events that are
generated, don’t implement this in a domain until you’ve read the
documentation on TechNet, starting with the step-by-step guide found
at http://go.microsoft.com/fwlink/?LinkId=168805.
Specifying Auditing Settings for Directory Service
Changes
You must still modify the SACL of objects to specify which
attributes should be audited.
To access the SACL and its audit entries:
-
In Active Directory Users And Computers, open the
Properties dialog box of the object you want to audit. -
On the Security tab, click Advanced. -
Click the Auditing tab.
To add an audit entry:
-
Click Add. -
Select the user, group, or computer to audit. Often this
will be the Everyone group. -
In the Auditing Entry dialog box, 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 using one or more of the granular access levels.
Viewing Audited Events in the Security Log
After you have enabled the desired audit 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, and select Security
Log.
When Directory Service Changes auditing is enabled and
auditing entries are configured in the SACL of directory service
objects, events are logged to the Security Log that clearly indicate
the attribute that was changed and the change made. In most cases,
event log entries show the previous and current value of the changed
attribute.
Practice Implementing an Audit Policy
In this practice, you configure auditing settings, enable
audit policies for object access, and filter for specific events
in the Security log. The business objective is to monitor a folder
containing confidential data that should not be accessed by users
in the Consultants group. You also configure auditing to monitor
changes to the membership of the Domain Admins group. To perform
this practice, you must complete the following preparatory
tasks:
-
Create a folder called Confidential Data on the C
drive. -
Create a global security group called
Consultants. -
Create a user named James Fine, and add the user to the
Consultants group.
If you have performed earlier practices, some of these
objects may already exist. Finally, in this and other practices in
this training kit, you will log on to the domain controller with
user accounts that are not a member of Domain Administrators or
the domain’s Administrators group. Therefore, you must give all
user accounts the right to log on locally to the domain
controllers in your practice environment. Follow the steps in the
article, “Grant a Member the Right to Logon Locally,” at
http://technet.microsoft.com/en-us/library/ee957044(WS.10).aspx to
grant the Allow Logon Locally right to the Administrators and
Domain Users groups. If you will use Remote Desktop Services to
connect to the domain controller—rather than logging on
locally—grant the Allow Logon Through Remote Desktop Services
right. Reboot the server or otherwise refresh Group Policy. This
is for the practice environment only. In a production environment,
you should not grant users the right to log on to domain
controllers.
EXERCISE 1 Configure Permissions and
Audit Settings
In this exercise, you configure permissions on the
Confidential Data folder to deny access to consultants. You then
enable auditing of attempts by consultants to access the
folder.
-
Log on to SERVER01 as Administrator. -
Open the properties of the C:\Confidential Data folder
and click the Security tab. -
Click Edit. -
Click Add. -
Type Consultants and
click OK. -
Select the Deny check box for the Full Control
permission. -
Click Apply. Click Yes to confirm the use of a Deny
permission. -
Click OK to close the Permissions dialog box. -
Click Advanced. -
On the Auditing tab, click Edit. -
Click Add. -
Type Consultants and
click OK. -
In the Auditing Entry dialog box, select the check box
under Failed next to Full Control. -
Click OK to close all dialog boxes.
EXERCISE 2 Enable Audit
Policy
Because SERVER01 is a domain controller, you use the
existing Default Domain Controllers Policy GPO to enable auditing.
On a stand-alone server, you would enable auditing by using Local
Security Policy or a GPO scoped to the server.
-
Open Group Policy Management and select the Group Policy
Objects container. -
Right-click the Default Domain Controllers Policy and
click Edit. -
Expand Computer Configuration\Policies\Windows
Settings\Security Settings\Local Policies and click Audit Policy. -
Double-click Audit Object Access. -
Select Define These Policy Settings. -
Select the Failure check box. -
Click OK, and then close the console. -
To refresh the policy and ensure that all settings have
been applied, open Command Prompt and type the command gpupdate.
EXERCISE 3 Generate Audit
Events
You now attempt to access the Confidential Data folder as a
member of the Consultants group.
-
Log on to SERVER01 as James Fine. -
Open the C:\ folder. Attempt to open the C:\Confidential
Data folder. -
Create a text file on your desktop and attempt to cut
and paste the file into the Confidential Data folder.
EXERCISE 4 Examine the Security
Log
You can now view the attempts by a consultant to access the
Confidential Data folder.
-
Log on to SERVER01 as Administrator. -
Open Event Viewer from the Administrative Tools
folder. -
Expand Windows Logs and click Security. -
Which types of events do you see in the Security log?
Remember that policies can enable auditing for numerous
security-related actions, including directory service access,
account management, logon, and more. Notice that the source of
events indicated in the Source column is Microsoft Windows
security auditing. -
To filter the log and narrow the scope of your search,
click the Filter Current Log link in the Actions pane. -
Configure the filter to be as narrow as possible.
What do you know about the event you are trying to
locate? You know it occurred within the last hour, that the
source is Microsoft Windows security auditing, and that it is
a File System event. -
Check your work by referring to Figure 5. -
Click OK.
Can you more easily locate the events generated when
James Fine attempted to access the Confidential Data
folder?
You cannot filter for the C:\Confidential Data folder
name in the Filter dialog box shown in Figure 5. But you
can locate events for that folder by exporting the file to a
log analysis tool or even to a text file. -
Click the Save Filtered Log File As link in the Actions
pane. -
In the Save As dialog box, click the Desktop link in the
Favorite Links pane.
-
In the Save As Type drop-down list, select Text. -
In the File Name text box, type Audit Log Export
. -
Click Save. -
Open the resulting text file in Notepad and search for
instances of C:\Confidential Data.
EXERCISE 5 Use Directory Service
Changes Auditing
In this exercise, you see the Directory Service Access
auditing that is enabled by default in Windows Server 2008 R2. You
then implement the Directory Service Changes auditing feature,
introduced in Windows Server 2008, to monitor changes to the
Domain Admins group.
-
Open the Active Directory Users And Computers
snap-in. -
On the View menu, ensure that Advanced Features is
selected. -
Select the Users container. -
Right-click Domain Admins and click Properties. -
On the Security tab, click Advanced. -
On the Auditing tab, select the auditing entry with
Special listed in the Access column. -
Click Edit. -
Confirm that auditing is already enabled for successful
writes to all properties. -
Click OK. -
Click OK to close the Advanced Security Settings dialog
box.
By default, Windows Server 2008 R2 audits any changes to
the member attribute of the Domain Admins
group. You now make two changes to the group’s
membership. -
In the properties dialog box of the Domain Admins group,
click the Members tab. -
Add the user James Fine and click Apply. -
Select James Fine, click Remove, click Yes to confirm,
and then click Apply. -
Click OK to close the Domain Admins Properties dialog
box. -
Open the Security log and locate the events that were
generated when you added and removed James Fine. The Event ID
is 4662. Examine the information provided on the General
tab.
You can identify that a user (Administrator) accessed an
object (Domain Admins) and used a Write Property access. The
property itself is displayed as a globally unique identifier
(GUID)—you cannot readily identify that the
member attribute was changed. The event
also does not describe the change that was made to the
property.
You now enable Directory Service Changes auditing, a
feature introduced in Windows Server 2008. -
Open Command Prompt and type the following
command:
auditpol /set /subcategory:"directory service changes" /success:enable -
Open the properties of Domain Admins and add James Fine
to the group. -
Return to the Event Viewer snap-in and refresh the view
of the Security log. You should see both a Directory Service
Access event (Event ID 4662) and a Directory Service Changes
event (Event ID 5136). If you do not see the Directory Service
Changes event, wait a few moments, and then refresh the view.
It can take a few seconds for the Directory Service Changes
event to be logged. -
Examine the information in the Directory Service Changes
event.
The information on the General tab clearly indicates
that a user (Administrator) made a change to an object in the
directory (Domain Admins) and that the specific change made
was adding James Fine.
|
