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.

Class	Description
ServiceSecurityAuditBehavior	Enables setting options for auditing as a service behavior.
AuditLogLocation	Enumeration to specify which log to write to. The possible values are Default, Application, and Security. When you select Default, the operating system determines the actual log location. See the "Application or Security Event Log Choice" section later in this topic.
MessageAuthenticationAuditLevel	Specifies which types of message authentication events are audited at the message level. The choices are None, Failure, Success, and SuccessOrFailure.
ServiceAuthorizationAuditLevel	Specifies which types of service authorization events are audited at the service level. The choices are None, Failure, Success, and SuccessOrFailure.
SuppressAuditFailure	Specifies what happens to the client request when auditing fails. For example, when the service attempts to write to the security log, but does not have SeAuditPrivilege. The default value of true indicates that failures are ignored, and the client request is processed normally.

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

Configuration

You can also use configuration to specify auditing behavior by adding a serviceSecurityAudit element under the Behaviors element. You must add the element under a Behavior element 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. For more information, see the Microsoft Support article on viewing and managing event logs by using the Event Viewer in Windows XP available at How to view and manage event logs in Event Viewer in Windows XP.

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

System	Application log	Security log
Windows XP SP2 or later	Supported	Not supported
Windows Server 2003 SP1 and Windows Vista	Supported	Thread context must possess SeAuditPrivilege

Other Factors

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

Factor	Application log	Security log
Audit policy management	Not applicable.	Along with configuration, the Security log is also controlled by the local security authority (LSA) policy. The "Audit object access" category must also be enabled.
Default user experience	All authenticated users can write to the Application log, so no additional permission step is needed for application processes.	The application process (context) must have SeAuditPrivilege.

See Also

Tasks

How to: Audit Windows Communication Foundation Security Events

Reference

ServiceSecurityAuditBehavior
AuditLogLocation

Concepts

Security Overview

Other Resources

Basic WCF Programming
serviceSecurityAudit element
Behaviors element
Security Model for Windows Server App Fabric