Auditing Security Events

Applications created with Windows Communication Foundation (WCF) can log security events (either success, failure, or both) with the auditing feature. The events are written to the Windows system event log and can be examined using the Event Viewer.

Auditing provides a way for an administrator to detect an attack that has already occurred or is in progress. In addition, auditing can help a developer to debug security-related problems. For example, if an error in the configuration of the authorization or checking policy accidentally denies access to an authorized user, a developer can quickly discover and isolate the cause of this error by examining the event log.

For more information about WCF security, see Security Overview. For more information about programming WCF, see Basic WCF Programming.

Audit Level and Behavior

Two levels of security audits exist:

• Service authorization level, in which a caller is authorized.

• Message level, in which WCF checks for message validity and authenticates the caller.

You can check both audit levels for success or failure, which is known as the audit behavior.

Audit Log Location

Once you determine an audit level and behavior, you (or an administrator) can specify a location for the audit log. The three choices include: Default, Application, and Security. When you specify Default, the actual log depends on which system you are using and whether the system supports writing to the security log. For more information, see the "Operating System" section later in this topic.

To write to the Security log requires the SeAuditPrivilege. By default, only Local System and Network Service accounts have this privilege. To manage the Security log functions read and delete requires the SeSecurityPrivilege. By default, only administrators have this privilege.

In contrast, authenticated users can read and write to the Application log. Windows XP writes audit events to the Application log by default. The log can also contain personal information that is visible to all authenticated users.

Suppressing Audit Failures

Another option during auditing is whether to suppress any audit failure. By default, an audit failure does not affect an application. If required, however, you can set the option to false, which causes an exception to be thrown.

Programming Auditing

You can specify auditing behavior either programmatically or through configuration.

Auditing Classes

The following table describes the classes and properties used to program auditing behavior.

For an example of setting up an application to log audit events, see How to: Audit Security Events.

Configuration

You can also use configuration to specify auditing behavior by adding a <serviceSecurityAudit> under the <behaviors>. You must add the element under a <behavior> as shown in the following code.

<configuration>  
  <system.serviceModel>  
    <behaviors>  
      <behavior>  
        <!-- auditLogLocation="Application" or "Security" -->  
        <serviceSecurityAudit  
                  auditLogLocation="Application"  
                  suppressAuditFailure="true"  
                  serviceAuthorizationAuditLevel="Failure"  
                  messageAuthenticationAuditLevel="SuccessOrFailure" />
      </behavior>  
    </behaviors>  
  </system.serviceModel>  
</configuration>  

If auditing is enabled and an auditLogLocation is not specified, the default log name is "Security" log for the platform supporting writing to the Security log; otherwise, it is "Application" log. Only the Windows Server 2003 and Windows Vista operating systems support writing to the Security log. For more information, see the "Operating System" section later in this topic.

Security Considerations

If a malicious user knows that auditing is enabled, that attacker can send invalid messages that cause audit entries to be written. If the audit log is filled in this manner, the auditing system fails. To mitigate this, set the SuppressAuditFailure property to true and use the properties of the Event Viewer to control the auditing behavior.

Audit events that are written to the Application Log on Windows XP are visible to any authenticated user.

Choosing Between Application and Security Event Logs

The following tables provide information to help you choose whether to log into the Application or the Security event log.

Operating System

Other Factors

In addition to the operating system, the following table describes other settings that control the enablement of logging.

See also

• ServiceSecurityAuditBehavior
• AuditLogLocation
• Security Overview
• Basic WCF Programming
• How to: Audit Security Events
• <serviceSecurityAudit>
• <behaviors>
• Security Model for Windows Server App Fabric