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.
- 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.
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 |
|
|
|
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 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
- 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.
- Open the Local Group Policy Editor.
- For only domain controllers
- Click Start, click All Programs, click
Administrative Tools, and then double-click Domain
Controller Security Policy .
- 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.
- Click Start, click All Programs, click
Administrative Tools, and then double-click Domain
Controller Security Policy .
- 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.
- Open the Group Policy Management Console (GPMC).
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.