Export (0) Print
Expand All
1 out of 1 rated this helpful - Rate this topic

Understanding Authorization Manager Auditing

Applies To: Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012

Monitoring the access to controlled resources and any changes to an authorization policy gives you a way to track potential security problems, helps to ensure user accountability, and provides evidence in the event of a security breach.

Types of auditing

With Authorization Manager, you can use two kinds of auditing: run-time auditing and authorization store change auditing.

Run-time auditing

There are two aspects to run-time auditing:

  • Run-time application initialization auditing, which generates audits when an application is opened.

  • Run-time client context and access check auditing, which generates audits when a client context is created and each time that the client calls for an access check. Access checks are based on the AccessCheck method described in the Authorization section of the Platform SDK. For more information about authorization-related application programming interfaces (APIs), see Authorization (http://go.microsoft.com/fwlink/?linkid=64031).

You can configure run-time auditing to log successes, failures, or both successes and failures.

Authorization store change auditing

When you enable authorization store change auditing, audits are generated every time the authorization store is modified. The audit logs all events, successes, and failures.

For authorization store change auditing, Authorization Manager supports the NTFS file system (for XML-based authorization stores), Active Directory Domain Services (AD DS), Active Directory Lightweight Directory Services (AD LDS), and Microsoft SQL Server.

Locating audit events

To view audit events generated by Authorization Manager, view the event logs on the appropriate computer:

  • Run-time auditing events are in the security log of the client computer where the application is running.

  • Authorization store change auditing events are in the security log of the computer where the store resides.

    • In the case of an XML-based authorization store, the audit records will be found in the Event Viewer of the computer where the XML file is stored.

    • In the case of an authorization store that uses AD DS or AD LDS, audit records will be found on the Event Viewer of the domain controller or AD LDS server being accessed.

    • In the case of a SQL-based authorization store, audit records will be found in the Event Viewer of the computer hosting SQL Server.

Auditing availability

The availability of auditing depends on the following:

  • Whether the authorization store is based on AD DS, AD LDS, XML, or SQL.

  • Whether auditing is configured at the authorization store level, the application level, or the scope level.

The following table describes the availability of the two auditing types.

 

Level Run-time auditing is available in Run-time auditing can be configured at this level in Authorization store change auditing is available in

Authorization store

  • XML

  • AD DS and AD LDS

  • SQL Server

  • XML

  • AD DS and AD LDS

  • SQL Server

  • XML

  • AD DS and AD LDS

  • SQL Server

Application

  • XML

  • AD DS and AD LDS

  • SQL Server

  • XML

  • AD DS and AD LDS

  • SQL Server

  • AD DS and AD LDS

  • SQL Server

Scope

  • XML

  • AD DS and AD LDS

  • SQL Server

Not available (configured at the application level)

  • AD DS and AD LDS

  • SQL Server

To use auditing, you have to select the appropriate check box on the Auditing tab. To enable run-time auditing, select the Runtime application initialization auditing check box. To enable authorization store change auditing, select the Runtime client context and access check auditing check box.

Configuring the system to allow auditing

Before you implement auditing, you must decide on an auditing policy. An auditing policy specifies categories of security-related events that you want to audit. By default, when Windows is first installed, all auditing categories are disabled.

In order to configure which application and scopes are to be audited, you must have the Manage auditing and security log privilege on the computer where the authorization store resides. This is usually accomplished by being logged on as a member of the built-in Administrators group, or providing an administrator's password when prompted.

If the authorization store is based on XML, you have to specify object access auditing. If the authorization store is based on AD DS or AD LDS, you have to specify directory service access auditing.

In order to generate run-time client context and access check audits, users of applications that use Authorization Manager must be granted the Generate security audits privilege. If users of the application do not hold this privilege, no audit events will be recorded.

Enabling object access auditing

By default, object access auditing is turned off. To turn it on, you need to use Group Policy at the domain, domain controller, or other applicable organizational-unit level in AD DS or AD LDS. You can also use the local security policy.

If the XML-based authorization store is located on a domain controller, the Default Domain Controllers Policy Group Policy object (GPO) is the most appropriate place to turn on object access auditing. If the XML-based authorization store is located on a workstation or member server, you can edit the local GPO for that computer to set the local security policy, but those settings will only apply until the next refresh of Group Policy security settings. This may be useful if you are only generating the audits one time. However, if you plan to generate security audits regularly you should edit another GPO that applies to the computer through AD DS.

To enable object access auditing, configure the following objects:

  • For a local computer

    1. Open the Local Group Policy Editor.

    2. In the console tree, double-click Computer Configuration , Windows Settings , Security Settings , Local Policies , and Audit Policy.

    3. Click Audit object access.

    4. In the details pane, select the Define these policy settings check box, select the Success check box, and then select the Failure check box.

  • For only domain controllers

    1. Click Start , click All Programs , click Administrative Tools , and then double-click Domain Controller Security Policy .

    2. In the console tree, double-click Computer Configuration , Windows Settings , Security Settings , Local Policies , and Audit Policy.

    3. Click Audit object access.

    4. In the details pane, select the Define these policy settings check box, select the Success check box, and then select the Failure check box.

  • For a domain or organizational unit

    1. Open the Group Policy Management Console (GPMC).

    2. Right-click the GPO that you want to audit, and then click Edit .

    3. In the console tree, double-click Computer Configuration , Policies , Security Settings , Local Policies , and Audit Policy.

    4. Click Audit object access.

    5. In the details pane, select the Define these policy settings check box, select the Success check box, and then select the Failure check box.

Additional considerations

  • You must install the GPMC to edit domain-based policy settings. The GPMC is an additional feature of Windows Server 2008 that you can install by using Server Manager.

  • If you are editing the local GPO, the Define these policy settings check box does not appear in the Local Group Policy Editor. It only appears if you are editing GPOs that are stored in AD DS.

  • If the Success and Failure auditing check boxes are unavailable, the Define these policy settings check box has probably been selected through security policy that is acting at a higher level in the AD DS structure. In this situation, you need to find out where the Define these policy settings check box is selected and clear this setting. To find this setting, look in the GPOs that affect this computer.

Enabling directory access auditing

By default, directory service access auditing is turned off. To turn it on, you need to use Group Policy at the domain, domain controller, or other applicable organizational unit level in AD DS.

To enable object access auditing, expand the following nodes: Computer Configuration , Windows Settings , Security Settings , Local Policies , Audit Policy , and then double-click Audit directory service access .

Select the Define these policy settings check box, select the Success check box, and then select the Failure check box.

Additional considerations

  • If the Success and Failure auditing check boxes are unavailable, the Define these policy settings check box has probably been selected through a security policy that is acting at a higher level in AD DS. In this situation, you need to find out where the Define these policy settings check box is selected and clear the check box. To find this setting, look in the GPOs that affect the domain controller.

  • After editing the GPOs, run the gpupdate command to ensure that the changes take effect immediately.

Auditing that is enabled by inheritance

Any auditing obtained through inheritance takes place regardless of the local setting. For example, in the case of an authorization store that is stored in AD DS, auditing policy can be inherited from a parent organizational unit in AD DS. In the case of an XML-based authorization store, audit policy on the folder containing the XML file is applicable.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.