Understanding Authorization Manager Auditing
Applies To: Windows Server 2008
Important
Authorization Manager is available for use in the following versions of Windows: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows XP, Windows Vista, Windows 7, and Windows 8. It is deprecated as of Windows Server 2012 R2 and may be removed in subsequent versions.
Monitoring the access to controlled resources and any changes to the 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: runtime auditing and authorization store change auditing.
Runtime auditing
There are two aspects to runtime auditing:
Runtime application initialization auditing, which generates audits when an application is opened.
Runtime 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 the MSDN section of the Microsoft Web site (https://go.microsoft.com/fwlink/?linkid=64031).
You can configure runtime auditing to log successes, failures, or both.
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 SQL Server.
Locating Audit Events
To view audit events generated by Authorization Manager, view the Event Logs on the appropriate computer:
Runtime auditing events are logged in the security log of the computer where the application is running. In other words, on the "client."
Authorization store change auditing events are logged in the security log of the computer where the store itself resides.
In the case of an XML-based authorization store, the audit records will be found in the Event Viewer of the computer physically holding the XML file.
In the case of an authorization store that uses AD DS or AD LDS, they will be found on the Event Viewer of the domain controller or AD LDS server being accessed.
In the case of SQL-based authorization store, they will be found in the Event Viewer of the SQL Server computer.
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 | Runtime auditing is available in | Runtime auditing can be configured at this level in | Authorization store change auditing is available in |
|---|---|---|---|
Authorization store |
|
|
|
Application |
|
|
|
Scope |
|
Not available (configured at the application level) |
|
To use auditing, you have to select the appropriate check box on the Auditing tab. To enable runtime auditing, click the Runtime application initialization auditing check box. To enable authorization store change auditing, click 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 runtime 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 your local computer
Open the Local Group Policy Editor.
In the console tree, double-click Computer Configuration, Windows Settings, Security Settings, Local Policies, and Audit Policy.
Click Audit object access.
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
Open theDomain Controller Security Policy console from the Administrative Toolscontrol panel.
In the console tree, double-click Computer Configuration, Windows Settings, Security Settings, Local Policies, and Audit Policy.
Click Audit object access.
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
Open the Group Policy Management Console (GPMC).
Right-click the GPO that you want to audit, and then click Edit.
In the console tree, double-click Computer Configuration, Policies, Security Settings, Local Policies, and Audit Policy.
Click Audit object access.
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 click to clear the check box. 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 controllers, 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 click to clear the check box. To find this setting, look in the GPOs that affect the domain controller.
After editing the Group Policy objects, 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.