Advanced Security Audit Policy Step-by-Step Guide

Updated: June 22, 2011

Applies To: Windows Server 2008, Windows Server 2008 R2

About this guide

Security auditing enhancements in Windows Server 2008 R2 and Windows 7 can help your
organization audit compliance with important business-related and security-related rules by
tracking precisely defined activities, such as:

A group administrator has modified settings or data on servers that contain finance
information.

An employee within a defined group has accessed an important file.

The correct system access control list (SACL) is applied to every file and folder or registry
key on a computer or file share as a verifiable safeguard against undetected access.

In Windows 7 and Windows Server 2008 R2, the number of audit settings for which success and
failure can be tracked has increased to 53. Previously, there were nine basic auditing settings
under Computer Configuration\Policies\Windows Settings\Security Settings\Local
Policies\Audit Policy. These 53 new settings allow you to select only the behaviors that you want
to monitor and exclude audit results for behaviors that are of little or no concern to you, or
behaviors that create an excessive number of log entries. In addition, because Windows 7 and
Windows Server 2008 R2 security audit policy can be applied by using domain Group Policy, audit
policy settings can be modified, tested, and deployed to selected users and groups with relative
simplicity.
This step-by-step guide demonstrates the process of setting up an advanced Windows 7 and
Windows Server 2008 R2 security auditing policy infrastructure in a test environment. It also guides
you through the process of configuring some representative advanced security audit policy settings.
When you have completed these initial tasks, you are strongly encouraged to use the procedures in
this guide to choose, configure, apply, and assess additional security audit policy settings.
During this process, you will create an Active Directory domain, install Windows Server 2008 R2 on a
member server, install Windows 7 on a client computer, and configure new advanced security audit
policy settings, including global object access auditing. In addition, this document will walk you
through the examination of new "reason for access" data available by using a number of new audit
policy settings.
Once complete, you can use this test environment to apply different sets of Windows
Server 2008 R2 advanced security audit policy settings and assess how they might be used to
enhance security in your organization.
As you complete the steps in this guide, you will be able to:

Create and apply advanced audit policy settings to a defined group of computers in your
organization.

Verify that the audit policy settings are applied to a defined group of client computer in
your organization.
 Use new "reason for access" security event data to identify the permissions that were used
to determine whether a particular security event was triggered.

Configure, apply, and analyze the impact of different audit policy settings to identify the
settings that are important to your organization.

Manage per-user auditing in Windows 7 and Windows Server 2008 R2.

Deploying advanced audit policy settings in a test

environment
After completing this step-by-step guide, you will have a working advanced security auditing
infrastructure. You can then test and learn about additional advanced security audit policy settings
by logging on to CONTOSO-CLNT and ensuring that the correct audit policy is being applied on the
computer.

Important

We recommend that you first use the procedures in this guide in a test lab environment.
Step-by-step guides are not meant to be used to deploy Windows features without
additional deployment planning and documentation.

The test environment described in this guide includes three computers that are connected to a
private network and use the following operating systems, applications, and services.

Computer
Operating system Applications and services
name

CONTOSO- Windows Active Directory Domain Services (AD DS)

DC Server 2008 R2 and Domain Name System (DNS)

CONTOSO- Windows Group Policy Management Console (GPMC)

SRV Server 2008 R2

CONTOSO- Windows 7
CLNT
 Note

For more information about operating system compatibility and requirements,

see Which Versions of Windows Support Advanced Audit Policy Configuration?.

The computers form a private intranet and are connected through a common hub or Layer 2 switch.
This configuration can be emulated in a virtual machine environment if desired. This step-by-step
uses private addresses throughout the test lab configuration. The private network ID 10.0.0.0/24 is
used for the intranet. The domain controller for the domain named contoso.com is named
CONTOSO-DC. The following figure shows the configuration of the test environment.

Steps for deploying advanced audit policies in a test

environment
Complete the following steps to deploy advanced audit policy settings in a test environment.
Step 1: Setting up the infrastructure
Step 2: Creating and verifying an advanced audit policy
Step 3: Creating and verifying an audit policy that provides the reason for object access
Step 4: Creating and verifying a global object access policy
Step 5: Creating and verifying additional advanced audit policies
Optional section: Roll back security audit policy from Advanced Audit Policy to basic audit policy

Step 1: Setting up the infrastructure

To prepare your test environment in the CONTOSO domain, you must complete the following tasks:

Configure the domain controller (CONTOSO-DC).

Configure the member server (CONTOSO-SRV).

Configure the client computer (CONTOSO-CLNT).

Use the following table as a reference when setting up the appropriate computer names, operating
systems, and network settings that are required to complete the steps in this guide.

Important

Before you configure your computers with static IP addresses, we recommend that you
first complete two important tasks that require Internet connectivity: Complete
 Windows product activation and use Windows Update to obtain and install any
available critical security updates.

Computer
Operating system requirement IP settings DNS settings
name

CONTOSO- Windows Server 2008 R2, IP address: Configured by

DC Windows Server 2008, or 10.0.0.1 DNS server
Windows Server 2003 with Subnet mask: role
Service Pack 2 (SP2) 255.255.255.0

CONTOSO- Windows Server 2008 R2 IP address: Preferred:

SRV 10.0.0.2 10.0.0.1
Subnet mask:
255.255.255.0

CONTOSO- Windows 7 or Windows IP address: Preferred:

CLNT Server 2008 R2 10.0.0.3 10.0.0.1
Subnet mask:
255.255.255.0

Configure the domain controller (CONTOSO-DC)

Depending on your environment, you may evaluate advanced audit policy settings in a Windows
Server 2008 R2, Windows Server 2008, or Windows Server 2003 domain. For this guide, we use a
Windows Server 2008 R2 domain.

Note

For more information about operating system requirements, see What's New in
Windows Security Auditing.

To configure the domain controller CONTOSO-DC running Windows Server 2008 R2, you must:

Install Windows Server 2008 R2.

Configure TCP/IP properties.

 Install AD DS.

Create a Finance organizational unit (OU).

First, install Windows Server 2008 R2 on a stand-alone server.

To install Windows Server 2008 R2
1. Start your computer by using the Windows Server 2008 R2 product CD.
2. When prompted for a computer name, type CONTOSO-DC.
3. Follow the rest of the instructions that appear on your screen to finish the installation.
Next, configure TCP/IP properties so that CONTOSO-DC has an IPv4 static IP address of 10.0.0.1.
To configure TCP/IP properties
1. Log on to CONTOSO-DC with the CONTOSO-DC\Administrator account.
2. Click Start, click Control Panel, click Network and Internet, click Network and Sharing
Center, click Change Adapter Settings, right-click Local Area Connection, and then
click Properties.
3. On the Networking tab, click Internet Protocol Version 4 (TCP/IPv4), and then
click Properties.
4. Click Use the following IP address. In the IP address box, type 10.0.0.1. In the Subnet
mask box, type 255.255.255.0. In the Default gateway box, type 10.0.0.1.
5. In the Preferred DNS server box, type 10.0.0.1, and then click OK.
6. On the Networking tab, clear the Internet Protocol Version 6 (TCP/IPv6) check box, and
then click Close.
Next, configure the computer as a domain controller running Windows Server 2008 R2.
To configure CONTOSO-DC as a domain controller running Windows Server 2008
1. Click Start, and then click Run. In the Open box, type dcpromo, and then click OK.
2. On the Welcome to the Active Directory Domain Services Installation Wizard page,
click Next, and then click Next again.
3. Click Create a new domain in a new forest, and then click Next.
4. In the FQDN of the forest root domain box, type contoso.com, and then click Next.
5. Leave the default value in the Domain NetBIOS name box, and then click Next.
6. In the Forest functional level list, click Windows Server 2003, and then click Next.
7. In the Domain functional level list, click Windows Server 2003, and then click Next.
8. Ensure that the DNS server check box is selected, and then click Next.
9. Click Yes, confirming that you want to create a delegation for this DNS server.
10. On the Location for Database, Log Files, and SYSVOL page, click Next.
11. In the Password and Confirm password boxes, type a strong password, and then
click Next.
12. On the Summary page, click Next to start the installation.
13. When the installation is complete, click Finish, and then click Restart Now.

Note
 You must restart the computer after you complete this procedure.

To create a Finance OU in contoso.com

1. Log on to CONTOSO-DC with the CONTOSO-DC\Administrator account.
2. Click Start, click Control Panel, double-click Administrative Tools, and then double-
click Active Directory Users and Computers.
3. In the console tree, right-click contoso.com, point to New, and then click Organizational
Unit.
4. Type the name of the new OU, Finance, and then click OK.
Configure the Windows Server 2008 R2 member server (CONTOSO-SRV)
To configure the member server, CONTOSO-SRV, you must:

Install Windows Server 2008 R2.

Configure TCP/IP properties.

Join CONTOSO-SRV to the domain contoso.com.

Add CONTOSO-SRV to the Finance OU.

Install the GPMC.

First, install Windows Server 2008 R2 as a stand-alone server.

To install Windows Server 2008 R2
1. Start your computer by using the Windows Server 2008 R2 product CD.
2. When prompted for a computer name, type CONTOSO-SRV.
3. Follow the rest of the instructions that appear on your screen to finish the installation.
Next, configure TCP/IP properties so that CONTOSO-SRV has a static IP address of 10.0.0.2. In
addition, configure the DNS server by using the IP address of CONTOSO-DC (10.0.0.1).
To configure TCP/IP properties
1. Log on to CONTOSO-SRV with the CONTOSO-SRV\Administrator account or another user
account in the local Administrators group.
2. Click Start, click Control Panel, double-click Network and Sharing Center, click Manage
Network Connections, right-click Local Area Connection, and then click Properties.
3. On the Networking tab, click Internet Protocol Version 4 (TCP/IPv4), and then
click Properties.
4. Click Use the following IP address. In the IP address box, type 10.0.0.2. In the Subnet
mask box, type 255.255.255.0. In the Default gateway box, type 10.0.0.1.
5. Click Use the following DNS server addresses. In Preferred DNS server, type 10.0.0.1.
6. Click OK, and then click Close to close the Local Area Connection Properties dialog box.
Next, join CONTOSO-SRV to the contoso.com domain.
To join CONTOSO-SRV to the contoso.com domain
1. Click Start, right-click Computer, and then click Properties.
2. Click Change settings (on the right under Computer name, domain, and workgroup
settings), and then click Change.
 3. In the Computer Name/Domain Changes dialog box, click Domain, and then
type contoso.com.
4. Click More, and in the Primary DNS suffix of this computer box, type contoso.com.
5. Click OK, and then click OK again.
6. When a Computer Name/Domain Changes dialog box appears prompting you for
administrative credentials, provide the credentials for CONTOSO\Administrator, and then
click OK.
7. When a Computer Name/Domain Changes dialog box appears welcoming you to the
contoso.com domain, click OK.
8. When a Computer Name/Domain Changes dialog box appears telling you that the
computer must be restarted, click OK, and then click Close.
9. Click Restart Now.
After the computer has restarted, add CONTOSO-SRV to the Finance OU.
To add a computer to the Finance OU
1. Log on to CONTOSO-DC with the CONTOSO-DC\Administrator account.
2. Click Start, click Control Panel, double-click Administrative Tools, and then double-
click Active Directory Users and Computers.
3. In the console tree, right-click contoso.com.
4. In the console tree, right-click the Finance OU, point to New, and then click Group.
5. Type the name of the new group, Computers, and then in Group scope, click Domain
local, and in Group type, click Security group.
6. Right-click Computers, and then click Properties. On the Members tab, click Add.
7. In Enter the object names to select, type CONTOSO-SRV, and then click OK.
Finally, install the GPMC on CONTOSO-SRV by using Server Manager. This will be used to configure
the advanced security audit policy settings.
To install the GPMC
1. Log on to CONTOSO-SRV as a member of the local Administrators group.
2. Click Start, point to Administrative Tools, and then click Server Manager.
3. Under Feature Summary, click Add Features.
4. Select the Group Policy Management check box, and then click Install.
5. Close Server Manager.
Configure the client computer (CONTOSO-CLNT)
To configure CONTOSO-CLNT, you must:

Install Windows 7.

Configure TCP/IP properties.

Join CONTOSO-CLNT to the domain contoso.com.

To install Windows 7
1. Start your computer by using the Windows 7 product CD.
2. Follow the instructions that appear on your screen, and when prompted for a computer
name, type CONTOSO-CLNT.
Next, configure TCP/IP properties so that CONTOSO-CLNT has a static IP address of 10.0.0.3. In
addition, configure the DNS server of CONTOSO-DC (10.0.0.1).
To configure TCP/IP properties
 1. Log on to CONTOSO-CLNT with the CONTOSO-CLNT\Administrator account or another
user account in the local Administrators group.
2. Click Start, click Control Panel, click Network and Internet, and then click Network and
Sharing Center.
3. Click Change adapter settings, right-click Local Area Connection, and then
click Properties.
4. If the User Account Control dialog box appears, confirm that the action it displays is what
you want, and then click Yes.
5. On the Networking tab, click Internet Protocol Version 4 (TCP/IPv4), and then
click Properties.
6. Click Use the following IP address. In IP address, type 10.0.0.3. In Subnet mask,
type 255.255.255.0.
7. Click Use the following DNS server addresses. In Preferred DNS server, type 10.0.0.1.
8. Click OK, and then click Close to close the Local Area Connection Properties dialog box.
Next, join CONTOSO-CLNT to the contoso.com domain.
To join CONTOSO-CLNT to the contoso.com domain
1. Click Start, right-click Computer, and then click Properties.
2. Under Computer name, domain, and workgroup settings, click Change settings.
3. If the User Account Control dialog box appears, confirm that the action it displays is what
you want, and then click Yes.
4. On the Computer Name tab, click Change.
5. In the Computer Name/Domain Changes dialog box, click Domain, and then
type contoso.com.
6. Click More, and in the Primary DNS suffix of this computer box, type contoso.com.
7. Click OK, and then click OK again.
8. When a Computer Name/Domain Changes dialog box appears prompting you for
administrative credentials, provide the credentials, and then click OK.
9. When a Computer Name/Domain Changes dialog box appears welcoming you to the
contoso.com domain, click OK.
10. When a Computer Name/Domain Changes dialog box appears telling you that the
computer must be restarted, click OK, and then click Close.
11. In the System Settings Change dialog box, click Yes to restart the computer.

Step 2: Creating and verifying an advanced audit policy

The nine basic audit policies under Computer Configuration\Policies\Windows Settings\Security
Settings\Local Policies\Audit Policy allow you to configure security audit policy settings for broad
sets of behaviors, some of which generate many more audit events than others. An administrator
has to review all events that are generated, whether they are of interest or not.
In Windows Server 2008 R2 and Windows 7, administrators can audit more specific aspects of client
behavior on the computer or network, thus making it easier to identify the behaviors that are of
greatest interest. For example, in Computer Configuration\Policies\Windows Settings\Security
Settings\Local Policies\Audit Policy, there is only one policy setting for logon events, Audit
logon events. In Computer Configuration\Policies\Windows Settings\Security
Settings\Advanced Audit Policy Configuration\System Audit Policies, you can instead choose
from eight different policy settings in the Logon/Logoff category. This provides you with more
detailed control of what aspects of logon and logoff you can track.
A default domain policy is automatically generated when a new domain is created. In this section,
we will edit the default domain policy and add an advanced security audit policy setting that audits
when a user either successfully or unsuccessfully logs on to a computer in the CONTOSO domain.
To configure, apply, and validate an advanced domain logon audit policy setting, you must:

Configure an advanced domain logon policy setting.

Ensure that Advanced Audit Policy Configuration settings are not overwritten.

Update Group Policy settings.

Verify that the advanced logon security audit policy settings were applied correctly.

To configure an advanced domain logon audit policy setting

1. Log on to CONTOSO-SRV as a member of the local Administrators group.
2. Click Start, point to Administrative Tools, and then click Group Policy Management.
3. In the console tree, double-click Forest: contoso.com, double-click Domains, and then
double-click contoso.com.
4. Right-click Default Domain Policy, and then click Edit.
5. Double-click Computer Configuration, double-click Policies, and then double-
click Windows Settings.
6. Double-click Security Settings, double-click Advanced Audit Policy Configuration, and
then double-click System Audit Policies.
7. Double-click Logon/Logoff, and then double-click Logon.
8. Select the Configure the following audit events check box, select the Success check box,
select the Failure check box, and then click OK.
When you use Advanced Audit Policy Configuration settings, you need to confirm that these
settings are not overwritten by basic audit policy settings. The following procedure shows how to
prevent conflicts by blocking the application of any basic audit policy settings.
To ensure that Advanced Audit Policy Configuration settings are not
overwritten
1. On CONTOSO-SRV, click Start, point to Administrative Tools, and then click Group Policy
Management.
2. In the console tree, double-click Forest: contoso.com, double-click Domains, and then
double-click contoso.com.
3. Right-click Default Domain Policy, and then click Edit.
4. Double-click Computer Configuration, double-click Policies, and then double-
click Windows Settings.
5. Double-click Security Settings, and then click Security Options.
6. Double-click Audit: Force audit policy subcategory settings (Windows Vista or later) to
override audit policy category settings, and then click Define this policy setting.
7. Click Enabled, and then click OK.
Before you can verify the functionality of advanced security audit policy settings in the contoso.com
domain, you will log on to CONTOSO-CLNT as the domain administrator of the contoso.com
domain and ensure that the Group Policy settings have been applied.
To update Group Policy settings
1. Log on to CONTOSO-CLNT as CONTOSO\Administrator.
 2. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and
then click Run as administrator.
3. If the User Account Control dialog box appears, confirm that the action it displays is what
you want, and then click Yes.
4. Type gpupdate, and then press ENTER.
After the Group Policy settings have been applied, you can verify that the audit policy settings were
applied correctly.
To verify that the advanced logon security audit policy settings were applied
correctly
1. Log on to CONTOSO-CLNT as CONTOSO\Administrator.
2. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and
then click Run as administrator.
3. If the User Account Control dialog box appears, confirm that the action it displays is what
you want, and then click Yes.
4. Type auditpol.exe /get /category:*, and then press ENTER.
5. Verify that Success, Failure, or Success and Failure are shown to the right of Logon.

Step 3: Creating and verifying an audit policy that

provides the reason for object access
One of the most common auditing needs is to track access to a particular file or folder. For example,
you might need to identify an activity such as a user writing to a file that he or she should not have
had access to. By enabling "reason for access" auditing, not only will you be able to track this type
of activity, but you will also be able to identify the exact access control entry that allowed the
undesired access, which can significantly simplify the task of modifying access control settings to
prevent similar undesired object access in the future.
To configure, apply, and validate a reason for object access policy, you must:

Configure the file system audit policy.

Enable auditing for a file or folder.

Enable the handle manipulation audit policy.

Ensure that Advanced Audit Policy Configuration settings are not overwritten.

Update Group Policy settings.

Review and verify reason for access auditing data.

To configure the file system audit policy

1. Log on to CONTOSO-SRV as a member of the local Administrators group.
2. Click Start, point to Administrative Tools, and then click Group Policy Management.
3. In the console tree, double-click Forest: contoso.com, double-click Domains, and then
double-click contoso.com.
4. Right-click Default Domain Policy, and then click Edit.
5. Double-click Computer Configuration, double-click Policies, and then double-
click Windows Settings.
 6. Double-click Security Settings, double-click Advanced Audit Policy Configuration, and
then double-click System Audit Policies.
7. Double-click Object Access, and then double-click File System.
8. Select the Configure the following events check box, and then select the Success, Failure,
or both Success and Failure check boxes.
9. Click OK.
The file system audit policy is only used to monitor objects for which auditing SACLs have been
configured. The following procedure shows how to configure auditing for a file or folder.
To enable auditing for a file or folder
1. Log on to CONTOSO-CLNT as a member of the local Administrators group.
2. Create a new folder or .txt document.
3. Right-click the new object, click Properties, and click the Security tab.
4. Click Advanced, and then click the Auditing tab.
5. If the User Account Control dialog box appears, confirm that the action it displays is what
you want, and then click Yes.
6. Click Add, type a user name or computer name in the format contoso\user1, and then
click OK.
7. In the Auditing Entries for dialog box, select the permissions that you want to audit, such
as Full Control or Delete.
8. Click OK four times to complete configuration of the object SACL.
In Windows 7 and Windows Server 2008 R2, the reason why someone has been granted or denied
access is added to the open handle event. This makes it possible for administrators to understand
why someone was able to open a file, folder, or file share for a specific access. To enable this
functionality, the handle manipulation audit policy also needs to be enabled so that success events
record access attempts that were allowed and failure events record access attempts that were
denied.
To enable the handle manipulation audit policy
1. Log on to CONTOSO-SRV as a member of the local Administrators group.
2. Click Start, point to Administrative Tools, and then click Group Policy Management.
3. In the console tree, double-click Forest: contoso.com, double-click Domains, and then
double-click contoso.com.
4. Double-click the Finance OU, right-click Finance Audit Policy, and click Edit.
5. Double-click Computer Configuration, double-click Policies, and then double-
click Windows Settings.
6. Double-click Security Settings, double-click Advanced Audit Policy Configuration, and
then double-click System Audit Policies.
7. Double-click Object Access, right-click Handle Manipulation, and click Properties.
8. Select the Configure the following audit events check box, select
the Success and Failure check boxes, and then click OK.
After you have created this audit policy, confirm that these advanced audit policy settings cannot be
overwritten. For more information, see the "To ensure that Advanced Audit Policy Configuration
settings are not overwritten" procedure in the Step 2: Creating and verifying an advanced audit
policy section.
Then apply the Group Policy updates by using the "To update Group Policy settings" procedure in
the Step 2: Creating and verifying an advanced audit policy section.
After the updated Group Policy settings have been applied, be sure to log on to and log off from
CONTOSO-CLNT and complete some tasks that will generate reason for object access events. Once
you have completed these steps, you can review the auditing data that provides the reason for
access.
To review reason for access auditing data
1. On CONTOSO-CLNT, click Start, point to Administrative Tools, and then click Event
Viewer.
2. Click Windows Logs, and then click Security.
3. In the Actions pane, click Clear Log.
4. Find the file or folder that you configured in the domain-level object access procedure, and
modify the file or folder by using the permissions that you configured for the user account.
5. Go back to Event Viewer, and in the Actions pane, click Refresh.
6. In the Event ID column, click the event or events titled 4656, scroll down to the Access
Request Information section, and confirm the permissions that were used to perform the
task.

Step 4: Creating and verifying a global object access

policy
A global object access audit policy can be used to enforce object access audit policy for a computer,
file share, or registry without having to configure and propagate conventional SACLs. Configuring
and propagating SACLs is a more complex administrative task and is difficult to verify, particularly if
you need to verify to an auditor that security policy is being enforced. By using a global object
access audit policy, you can enforce a security policy such as "Log all administrative Write activity on
servers containing Finance information" and verify that critical assets are being protected.
In this case, you will be auditing any changes made to registry keys by members of a specified
group rather than changes made to file system objects.
To configure, apply, and validate a global object access audit policy, you must:

Configure a domain global object access audit policy.

Ensure that Advanced Audit Policy Configuration settings are not overwritten.

Update Group Policy settings.

Confirm that global object access auditing is taking place.

To configure a domain global object access audit policy

1. Log on to CONTOSO-SRV as a member of the local Administrators group.
2. Click Start, point to Administrative Tools, and then click Group Policy Management.
3. In the console tree, double-click Forest: contoso.com, double-click Domains, and then
double-click contoso.com.
4. Right-click Default Domain Policy, and then click Edit.
5. Double-click Computer Configuration, double-click Policies, and then double-
click Windows Settings.
6. Double-click Security Settings, double-click Advanced Audit Policy Configuration, and
then double-click System Audit Policies.
7. Double-click Object Access, and then double-click Registry.
8. Select the Configure the following events check box, select the Success and Failure check
boxes, and then click OK.
 9. Double-click Global Object Access Policies, and then double-click Registry.
10. Select the Define this policy setting check box, and click Configure.
11. In the Advanced Security Settings for Registry SACL box, click Add.
12. Type a user name or computer name in the format contoso\user1, user1@contoso.com,
or CONTOSO-CLNT, and click OK.
13. In the Auditing Entry for Global Registry SACL box, select
the Successful or Failed activities for which you want to log audit entriesfor
example, Create Subkey, Delete, or Read.
14. Click OK three times to complete the audit policy configuration.
After you have created the audit policy, confirm that these advanced audit policy settings cannot be
overwritten. For more information, see the "To ensure that Advanced Audit Policy Configuration
settings are not overwritten" procedure in the Step 2: Creating and verifying an advanced audit
policy section.
Then apply the Group Policy updates by using the "To update Group Policy settings" procedure in
the Step 2: Creating and verifying an advanced audit policy section. After the updated Group Policy
settings have been applied, log on to and log off from CONTOSO-CLNT.
To verify that the global object access policy has been applied
1. Open Registry Editor, and create and modify one or more registry settings.
2. Delete one or more of the registry settings that you created.
3. Open Event Viewer, and confirm that your activities resulted in audit events, even though
you did not set explicit auditing SACLs on the registry settings that you created, modified,
and deleted.

Step 5: Creating and verifying additional advanced

audit policies
Now that you have created, applied, and validated the three basic types of advanced security audit
policy settings, continue to identify and test additional advanced security audit policy settings by
using the basic procedures outlined in the previous sections.
To identify additional settings of potential interest to your organization, review the information
in What's New in Windows Security Auditing.
Additional information is available in Computer Configuration\Policies\Windows
Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies by
right-clicking individual settings, clicking Properties, and clicking the Explain tab.
As you apply and test additional settings, consider how the audit event data that is generated can
help you create a more secure network. In particular, consider the following:

Is the information provided by these audit events useful?

Is sufficient information provided by the audit data?

Is too much information provided by the audit data?

How can I adjust these audit policy settings to get only the information that I need?

Security auditing is a critical and essential tool to help you ensure that your network assets are
secure. You should spend as much time as necessary to explore and understand the new advanced
security audit policy settings in Windows 7 and Windows Server 2008 R2.
Managing per-user auditing in Windows 7 and
Windows Server 2008 R2
Security audit policy settings in Windows 7 and Windows Server 2008 R2 can be configured and
used only on a per-computer basis, not a per-user basis. However, there are several ways to apply
audit settings to specific users:

Where available, configure the advanced security permissions on the object being audited
so that the audit policy applies only to a specific group. For example, if you want the Object
Access policy setting to apply to a file or folder, you can configure permissions on the file
or folder so that object access is only tracked for the individuals or groups you specify. The
procedure titled "To enable auditing for a file or folder" earlier in this document describes
how to complete this task.

Define and deploy per-user audit settings by using an audit policy text file, a logon script,
and the Auditpol.exe command-line tool.

Important

Per-user auditing based on logon scripts can only be applied to individual users,
not groups. You cannot use logon scripts to exclude subcategories or categories
of audit policy settings for administrators.

The following procedure describes how to create an audit policy text file that can be deployed by
using a logon script. For more information about using logon scripts to deploy an audit policy,
see article 921469 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkID=82447).
To create an audit policy text file
1. At a command prompt, type auditpol /set
/user:securityprincipalname/category:"subcategoryname" /include /Success or
Failure:enable to add a per-user audit setting. Repeat this step for each audit policy
subcategory and user or group that you want to add to your audit policy text file.

Note
 To obtain a list of possible audit settings in report format, open a Command
Prompt window, type auditpol /list /subcategory:* /r, and press ENTER. For
more information about using Auditpol, see Auditpol set and Auditpol list.

2. At a command prompt, type auditpol /backup /file: auditpolicyfilename.txt to export the

policy.
3. Format your policy by opening auditpolicyfilename.txt and removing all lines except the first
line of text and the per-user audit lines of text.

Note

Per-user audit policy text will be in the form: ComputerName,S-1-

XXXX,SubcategoryName,GUID,TextIncludeSettings,TextExcludeSettings,#.
System settings will be in the
form: ComputerName,System,SubcategoryName,GUID,TextAuditSettings,#.
Also, be sure to remove the last six lines, which contain audit option settings.

4. When you have finished creating your file, on the File menu, click Save As, and confirm
that ANSI is selected in the Encoding list. Click OK.
5. At a command prompt, type auditpol /restore /file: auditpolicyfilename.txt, and press
ENTER to confirm that the desired audit settings are configured. Type auditpol /list /user,
and press ENTER to list any users with per-user audit settings.
6. Copy the auditpolicyfilename.txt file to the Netlogon share of the domain controller that
holds the primary domain controller (PDC) emulator role in the domain.

Important

Do not import audit policies containing per-user auditing settings directly into a
Group Policy object (GPO). When per-user audit settings are deployed through
Group Policy and not through logon scripts as described in this procedure, this
can cause unexpected levels of failure events to appear in your security audit
logs.

Optional section: Roll back security audit policy from

Advanced Audit Policy to basic audit policy
Applying advanced audit policy settings replaces any comparable basic security audit policy
settings. If you subsequently change the advanced audit policy setting to Not configured, you will
need to complete the following steps to restore the original basic security audit policy settings:

1. Set all Advanced Audit Policy sub-categories to Not configured.

2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.

3. Reconfigure and apply the basic audit policy settings.

Unless you complete all of these steps, the basic audit policy settings will not be restored.
 Windows Server 2012 Active Directory Security
Changes
Dynamic Access Control presents a major shift
Feb 4, 2013Jan De Clercq

O EMAIL
INSHARE

COMMENTS 0

Microsoft has positioned its most recent server OS, Windows Server 2012, as a
fundamental building block for private cloud environments. The new server OS
includes numerous changes to the Hyper-V virtual machine manager, including new
security features to allow for better and more flexible network isolation between the
virtual machines (VMs) of tenants that use the same Hyper-V instance. But Server
2012 also includes important changes to another crucial element of Microsoft-rooted
private clouds: Active Directory (AD).

In this article, I focus on some key security changes that Microsoft bundles with Server
2012 AD. There's much to say about Dynamic Access Control, which represents a big
shift in the Windows and AD authorization model. In addition, Server 2012 AD
includes some smaller but no less important security-related changes.

Dynamic Access Control: All About Claims

Dynamic Access Control is probably the most fundamental security change that
Microsoft incorporates in Server 2012. Dynamic Access Control integrates the claims-
based access control (CBAC) model with the Windows OS and AD. Claims are
statements about users or devices (e.g., "My account name is JanDC," "I am a member
of the sales department") and are issued by a trusted authority. Microsoft first
introduced CBAC in Active Directory Federation Services version 1 (ADFS v1), which
was bundled with Windows Server 2003.

Claims can provide a flexible mechanism for exchanging trustworthy identity attributes
between ADFS servers. Organizations can now use claims to protect the file and folder
data stored on domain-joined Server 2012 or Windows 8 machines. Server 2012
domain controllers (DCs) can issue claim statements as part of the user and machine
authentication process, by embedding the claims in the user's or machine's
 authentication ticket. (For more information on claims and how Microsoft leverages
them, read "A Guide to Claims-based Identity and Access Control.")

Dynamic Access Control is built on several new and enhanced Windows data-
authorization features for classifying and labeling data, applying CBAC settings,
auditing access to data, and encrypting data. Under the hood, Dynamic Access Control
relies on numerous Microsoft engineering changes to key Windows components,
services, and protocols. These include AD, Group Policy Objects (GPOs), DNS,
Kerberos, the Local Security Authority (LSA), and the Netlogon processes, as well as
network protocols such as Server Message Block (SMB), LDAP, and remote procedure
call (RPC). Microsoft has made several Dynamic Access Controldriven changes in
Server 2012, including the following:

Extending the DC and Kerberos Key Distribution Center (KDC) logic, to enable the issuing of
claims in authentication tokens
Changing the Kerberos token format, to enable the transportation of claims
Adding alternate data streams (ADS) in NTFS, to attach custom properties to files and folders
Enabling the storage of conditional expressions in the ACLs of file and folders, to enable more
flexible access control and auditing settings
Extending the AD schema, to allow centralized storage of Dynamic Access Control properties
and policies

Dynamic Access Control can leverage AD to store central access policies (CAPs) and
GPOs and to push these policies to domain members. Microsoft also added a Central
Policy tab (which Figure 1 shows) in the Advanced Security Settings dialog box for
folders.

Figure 1: The Central Policy Tab

From this tab, administrators can choose the CAP that they want to assign to a given
folder. Thanks to these changes, you can now grant access to files and folders in your
domain or forest, based on the values of standard or custom attributes of your AD user
and machine objects. For example, you can now refuse a user access to a file server
share if the Department attribute of the AD user object doesn't contain the value
"Sales" or "Marketing." This new flexible authorization logic is very different from the
user- and group-SIDbased logic that we've been using for years.
You can define CAPs from the Dynamic Access Control container in the revamped
Active Directory Administrative Center (ADAC), which Figure 2 shows, or by using
Windows PowerShell cmdlets.

Figure 2: The Dynamic Access Control Container

You can call on the same tools to enable claim support for an AD user or machine
object attribute and to add values to these attributes. A Server 2012 DC will add claim
statements to user and computer authentication tokens only for the user and computer
object attributes that actually contain information and that are linked to an enabled
claim type. Before your Server 2012 DCs can issue claims, you must explicitly enable
them to issue claim statements; indeed, Server 2012 DCs are disabled for CBAC by
default. To enable CBAC, use the Domain Controller support for Dynamic Access
Control and Kerberos armoring GPO setting in the \Computer
Configuration\Policies\Administrative Templates\System\KDC container. To use
GPOs to push CAPs to your machines, you can use the new Central Access Policy GPO
option in the \Computer Configuration\Policies\Windows Settings\Security
Settings\File System container.

Dynamic Access Control brings the flexibility of claims not only to file and folder access
control, but also to file and folder access auditing. For example, in Server 2012 you can
configure an audit rule to track all users that were allowed or denied access to folders
that are marked with the "confidential" property. To centrally define claim-based
auditing settings for files and folders, you must call on the GPO Global Object Access
Auditing feature that Microsoft introduced in Windows Server 2008 R2 and has now
extended with Dynamic Access Control support.

Administrators can also define flexible access control and auditing settings on files and
folders, in addition to or independent of the centrally defined CAPs. Microsoft changed
the Advanced Security Settings dialog boxes in Windows 8 and Server 2012 to allow
you to configure conditional expressions in the authorization and auditing settings of
files and folders. Figure 3 shows this new interface, illustrating the definition of a
permission that includes a conditional expression on a folder named SharedData.
Figure 3: The Advanced Security Editor

Besides access control and auditing, Dynamic Access Control also provides new,
flexible data-classification mechanisms. A good example is the ability to add custom
file and folder properties, called global resource properties, to the access control and
auditing setting dialog boxes of files and folders. Again, you can do this by using ADAC
or PowerShell cmdlets. To propagate these custom properties to your domain
machines, Microsoft equipped Windows 8 and Server 2012 clients with a special
extension that uses LDAP to connect to AD and retrieve these properties. This new
data classification feature gives you the flexibility to classify data based on your
selected attributes and to apply protection accordingly.

You can classify files and folders manually by using the Classification tab in the
properties of a file or folder, as Figure 4 shows. The Classification tab appears only on
systems that have the Desktop Experience feature installed or that host the File Server
Resource Manager role service.

Figure 4: The Classification Tab

For files, you can also automate the classification process by using the File
Classification Infrastructure (FCI) feature. Introduced in Server 2008 R2, the FCI
allows administrators to define custom classification labels, set up classification and
expiration rules, and report on classifications. Administrators can manage FCI from
the File Server Resource Manager (FSRM). FCI can also be used with the RMS Bulk
Protection Tool to automatically apply RMS protection to files.

This is a very short introduction to Dynamic Access Control. You can find plenty more
information, including how to set up, configure, and troubleshoot Dynamic Access
Control, in the Microsoft white paper "Understand and Troubleshoot Dynamic Access
Control in Windows Server 8 Beta."

New Security Management Functions in ADAC

In Server 2012, ADAC has become the main AD administration interface. ADAC even
outpaces its predecessor -- the Microsoft Management Console (MMC) Active
Directory Users and Computers snap-in -- on the level of administrative features. Two
new features that many administrators will welcome are ADAC's GUI support for
 recovering deleted AD objects and for configuring fine-grained password policy
(FGPP) settings.

The AD Recycle Bin was introduced in Server 2008 R2, to enable the recovery of
deleted AD objects and their attributes. An important shortcoming of the Server 2008
R2 AD Recycle Bin was its lack of a GUI. Administrators were forced to use either
ldp.exe or PowerShell cmdlets, two tools that complicate AD object recovery and slow
down the recovery process.

As Figure 5 shows, Microsoft has integrated a Deleted Objects container in the Server
2012 ADAC interface.

Figure 5: The Deleted Objects Container

You can now easily restore a deleted user object by using the Restore or Restore To
links in the right pane of ADAC. In Server 2012, the same restrictions apply to the use
of AD Recycle Bin:

It isn't enabled by default (you can enable it from ADAC).

Your AD forest must be at least at the Server 2008 R2 functional level.
You can restore deleted objects only within their Deleted Object Lifetime (DOL), which is 180
days by default.

For more information about the AD Recycle Bin, see the "Active Directory Recycle Bin
Step-by-Step Guide."

The second useful GUI addition in ADAC relates to FGPP configuration. Microsoft
introduced FGPPs in Server 2008 to allow the definition of multiple Windows domain
password and account lockout policies that are linked to different AD user or
administrator groups. Before that, Windows Server could support only a single domain
password policy. To support FGPPs, Microsoft introduced a new AD object type called
the Password Settings Object (PSO).

As for the Recycle Bin, Microsoft didn't provide a GUI to configure FGPPs in the Server
2008 release. Administrators needed to call on tools such as PowerShell cmdlets, ADSI
Edit, or LDIFDE to define PSOs. In Server 2012, you can use the ADAC GUI to define
new FGPPs and PSOs from the new Password Settings Container that's underneath the
System container, as Figure 6 shows.

Figure 6: Defining Fine-Grained Password Policies

Just as before, your domain must be at least at Server 2008 domain functional level to
use FGPPs. For more details, see "AD DS Fine-Grained Password Policy and Account
Lockout Step-by-Step Guide."

Group Managed Service Accounts

Managed Service Accounts (MSAs) are a special type of domain account that Microsoft
supports in Server 2008 R2 AD and later. MSAs overcome the password-management
problems that administrators encounter when they set up a custom domain account for
authenticating a service. Administrators prefer to define custom accounts, which allow
them to better isolate the privileges of an application than when using a built-in high-
privilege local account (i.e., Local System, Local Service, Network Service) as the
service account. But unlike these built-in local accounts, custom accounts don't have
automatic password management. Therefore, when you use custom service accounts,
you need to manually manage their passwords or create a custom management
solution.

MSAs resolve this problem by providing automatic password management. They also
simplify the setup of Service Principal Names (SPNs) for a service. Unfortunately, the
MSAs that are introduced in Server 2008 R2 could not be used by clustered or load-
balanced services (e.g., services in a web farm) that want to share one service account
and password. In these scenarios, administrators needed to manually synchronize the
passwords of the service instances or implement a custom solution for automatic
password synchronization.

Server 2012 group MSAs (gMSAs) resolve this problem for load-balanced services in
web farms. Unfortunately, at the time of writing, the MSAs don't yet work for services
that are part of a failover cluster.

Behind gMSAs, a new service called the Microsoft Key Distribution Service runs on
every Server 2012 DC. This service ensures that the password of the single service
account that the web farm service instances use is kept in sync between instances. To
use gMSAs, your AD schema must be updated to Server 2012, and you need one or
more Server 2012 DCs running the Microsoft Key Distribution Service. The service is
automatically installed on every DC but defaults to a manual startup. Only services that
run on Server 2012 can use gMSAs. You can create and administer gMSAs by using a
set of PowerShell cmdlets. For more information on gMSAs, see "Getting Started with
Group Managed Service Accounts."

Primary Computers for Folder Redirection and Roaming Profiles

The last new, powerful feature that I want to discuss in this article is the ability to label
AD computer objects as the primary computers of certain domain users. You can use
this feature to control the computers to which users' roaming profiles are downloaded
and on which users receive access to their redirected folders. On computers that
haven't been labeled as primary computers, users will have a local profile and won't
have access to their redirected folders.

In the age of the consumerization of IT and trends such as Bring Your Own Device
(BYOD), this method is a powerful way to associate or dissociate user data and settings
with particular computers or devices and to improve corporate data security.
Designating primary computers reduces the security and privacy risks of downloading
or leaving personal or corporate data on personal or public computers to which the
user has logged on.

The Primary Computer feature is based on a set of new GPO settings and an AD
schema extension. When a user logs on to a Windows 8 or Server 2012 machine, the
logon logic checks the status of the Download roaming profiles on primary computers
only and Redirect folders on primary computers only GPO-controlled settings. The
status determines whether the msDS-PrimaryComputer attribute, which is linked to
the user's AD user account object, should influence the decision to roam the user's
profile or to apply Folder Redirection. The new GPO settings are in the \User
Configuration\Policies\Administrative Templates\System\Folder Redirection and the
\User Configuration\Policies\Administrative Templates\System\User Profiles GPO
containers.

You can use the ADAC or PowerShell cmdlets to populate an AD user object's msDS-
PrimaryComputer attribute with a list of DistinguishedNames of computer accounts
that should be marked as the user's primary computers. Figure 7 shows how you can
leverage ADAC and its built-in attribute editor to set the msDS-PrimaryComputer
attribute for a user named Jack.

Figure 7: Setting a User's Primary Computer

The support for the Primary Computer feature requires that your AD schema be
upgraded to Server 2012. The feature can be leveraged only on domain-joined Server
2012 and Windows 8 machines. For more details on how to set up this feature, I advise
you to read the Storage Team Blog post "Configuring Primary Computers for Folder
Redirection and Roaming Profiles in Windows Server 8 Beta."

A Model Shift

Dynamic Access Control represents the biggest shift in the authorization and auditing
model for Windows files and folders since the introduction of AD, and maybe even
since the introduction of NTFS. The support for Dynamic Access Control is certainly
the biggest security change in Server 2012 and AD, not only for the Microsoft engineers
who developed it but also for anyone who decides to use it. If you're a Windows or AD
administrator or architect, I advise you to test Dynamic Access Control thoroughly and
become familiar with it before you start using it.

ADAC and PowerShell also enter prime time for general and security-related AD
management tasks in Server 2012 AD. Like Dynamic Access Control, ADAC and
PowerShell are primarily about adding more flexibility and making it easier for the
people who administer and configure AD day-in and day-out.