Authorization Manager auditing

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Authorization Manager auditing

You need the Generate security auditsprivilege and the Manage auditing and security log privilege to do auditing. For more information about these privileges, see Privileges.

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

Runtime auditing

When you enable runtime auditing, applications generate audits when they use policy that is defined in the authorization store. You can configure auditing to log successes, failures, or both. Runtime auditing records client context and access checks. 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 at the Microsoft Web site.

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) and Active Directory. The APIs upon which Authorization Manager is based are flexible enough to allow for the use of the Windows registry, Exchange Server, and SQL Server.

Auditing availability

The availability of auditing depends on the following:

• Whether the authorization store is based on Active Directory or XML.

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

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

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.

If the authorization store is based on XML, you also have to specify object access auditing. If the authorization store is based on Active Directory, you also have to specify directory service access auditing.

Important

• By default, object access auditing is turned off. Auditing for XML-based authorization stores only works if you turn on object access auditing. To do this, you need to use Group Policy at the domain, domain controller, or other applicable organizational unit level in Active Directory, or through 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, edit the local Group Policy object for that computer to set local security policy, or edit another Group Policy object that applies to the computer through Active Directory. For more information about Active Directory, see Active Directory.

  To enable object access auditing, double-click Audit object access.

  Where?

  • Group Policy object name (for example: Default Domain Controllers Policy)/Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy/Audit object access

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

  Notes

  • If you are editing the local Group Policy object, the Define these policy settings check box does not appear in the Group Policy Object Editor. It only appears if you are editing Group Policy objects that are stored in Active Directory.

  • 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 Active Directory. 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 Group Policy objects (GPOs) that affect this computer.

Important

• By default, directory service access auditing is turned off. To use auditing for authorization stores that are stored in Active Directory, you must turn on directory service access auditing. You do this through Group Policy at the domain, domain controllers, or other applicable organizational unit level in Active Directory. The Default Domain Controllers Policy Group Policy object is usually the most appropriate place to turn on directory service-based access auditing. For more information about Group Policy, see Group Policy (pre-GPMC).

  To enable directory service access auditing, double-click Audit directory service access in Group Policy.

  Where?

  • Group Policy object name (for example: Default Domain Controllers Policy)/Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy/Audit directory service access

  Notes

  • If you are editing the local Group Policy object, the Define these policy settings check box does not appear in Group Policy. It only appears if you are editing Group Policy objects that are stored in Active Directory.

  • 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 Active Directory. 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 Group Policy objects (GPOs) that affect this computer.

After editing the Group Policy objects, run the gpupdate command to ensure that the changes take effect immediately. For more information, see Gpupdate.

Auditing event logging

All Authorization Manager audits are written to the Security section of the Event Viewer. For more information about Event Viewer, see Event Viewer.

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 Active Directory, auditing policy can be inherited from a parent organizational unit in Active Directory. In the case of an XML-based authorization store, audit policy on the folder containing the XML file is applicable.

For more information about auditing, see Auditing Security Events.