Auditing Message Queuing Objects

  • Article

Applies To: Windows Server 2008

Auditing Message Queuing objects

You can use auditing to record which users attempt to access Message Queuing objects, the type of operation attempted, and whether that access succeeded or failed. The security descriptor for an object specifies the various access events to be audited for the object. This part of the security descriptor is known as a system access control list (SACL). More specifically, a SACL specifies the following:

  • The users or groups to audit when accessing the object.

  • The access events to be audited for each group or user.

  • A Success or Failure attribute for each access event, based on the permissions granted to each group or user in the object's discretionary access control list (DACL).

For more information about auditing for Windows 7 and the Windows Server 2008 R2 family, see Auditing overview, in the Windows Help file.

The security log records audited operations, called security events, which you can view using Event Viewer.

Configuring auditing

To implement auditing, you must establish an audit policy. An audit policy specifies categories of security-related events that you want to audit. For instructions, see Define or modify auditing policy settings for an event category, in the Windows Help file. To audit "object open" security events such as Peek Message, Receive Message, and Send Message, you grant the Message Queuing service of a specific computer security permissions to access SACL information for its public queue. For more information, see Enable Message Queuing to Access SACL Information.

Next, you select the access entries to be audited for success or failure for a user or group on a specific object or resource. For information about how to set auditing options for a Message Queuing computer or queue object, see Audit Access to Computer and Queue Objects. For information about how to set auditing options for a routing link object, see Audit Access to Routing Link Objects.

If auditing options are specified for a Message Queuing object but an audit policy has not been established on the Message Queuing server that carries out the operation, a security event is not created.

Security events

Security events are created in the security log on the computer that performs the operation, which is not necessarily the computer that is the owner of the object. Because of this, audit messages for a single Message Queuing object can be scattered across a network. For example, in this figure, if the public test queue located on client 1 in the San Francisco site is deleted by client 2 in the Seattle site, the audit message is created on server 2 of the Seattle site. The following diagram illustrates this: