Event ID: 0 may be logged when you configure a Web Services Enhancements 3.0-based Web service to use a secure conversation: "An error occured processing an outgoing fault response"


Symptoms


Consider the following scenario. You configure a Microsoft Web Services Enhancements 3.0 (WSE 3.0)-based Web service to use a secure conversation. You configure the application pool in Internet Information Services (IIS) to use a custom user account to run the Web service. In this scenario, the following Error events may be logged:
Event 1
Event 2
Note In these events, the word "occured" is a misspelling for the word "occurred."

Cause


By default, WSE 3.0 uses the stateful SecurityContextToken object if you configure the Web service to use a secure conversation by setting the EstablishSecurityContext property of the policy to true. WSE 3.0 uses the Data Protection API (DPAPI) to encode the state of the SecurityContextToken object and to decode the state of the SecurityContextToken object. Or, WSE 3.0 uses the DPAPI to encode the cookie of the SecurityContextToken object and to decode the cookie of the SecurityContextToken object.

This problem occurs because WSE 3.0 cannot call the DPAPI if the user profile of the application pool identity is not loaded.

Workaround


To work around this problem, use one of the following methods.

Method 1

Configure the application pool identity to run as a user account for which the user profile is already loaded. For example, configure the application pool identity to run as the Network Service account.

Method 2

Manually load the user profile of the application pool identity. To do this, use one of the following methods.

Method A

Follow these steps:
  1. Use a user account to log on to the computer, and then do not change the user account.
  2. Under this user account, create a Microsoft Windows service, or run a Windows service.
  3. Configure the Windows service so that the user account can interact with the desktop.

Method B

To load the user profile, call the LoadUserProfile function.

Method 3

Disable the stateful SecurityContextToken object of the Web service by configuring the statefulSecurityContextToken element. For example, you can use the application configuration file that contains the following code to disable the stateful security tokens.
<tokenIssuer>
<statefulSecurityContextToken enabled="false"/>
</tokenIssuer>

Method 4

To configure the Web service to use a secure conversation, use an X509 certificate, or use another security token type instead of using the default DPAPI implementation. To do this, configure the serviceToken element in the application configuration file of each Web server. For example, the following code configures the Web service to use an X509 certificate instead of using the default DPAPI implementation.
<microsoft.web.services3>
<tokenIssuer>
<statefulSecurityContextToken enabled="true"/>
<serviceToken>
<add>
<KeyInfo>
<wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">bBwPfItvKp3b6TNDq+14qs58VJQ=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</KeyInfo>
</add>
</serviceToken>
</tokenIssuer>
</microsoft.web.services3>

Status


Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

More Information


When you send a SOAP message, the stateful SecurityContextToken object is serialized together with an encrypted key that can be retrieved only by the Web service. On the contrary, the encrypted key of the stateless SecurityContextToken object is cached by the client and by the Web service. Therefore, a unique string that represents the cached SecurityContext security token must be sent in the SOAP message. When the caches are available, no problem occurs. If you use the stateless SecurityContextToken object and if the application domain that is hosting the Web service is reset, the caches are destroyed. Therefore, a SOAP error occurs.

Note Some virus scanners may cause the application domain to be reset.

Steps to reproduce the problem

  1. Open the WSE 3.0 Secure Conversation Quickstart sample. By default, this sample is in the following location:
    drive:\Program Files\Microsoft WSE\v3.0\Samples\CS\QuickStart\Security\SecureConversation\Policy
  2. Configure an application pool to use a custom user account to run the Web service in this sample. The user profile of the application pool identity is not loaded yet.
  3. Run the WSE 3.0 Secure Conversation Quickstart sample.

References


For more information about how to troubleshoot the DPAPI, click the following article number to view the article in the Microsoft Knowledge Base:

309408 How to troubleshoot the Data Protection API (DPAPI)

For more information about Windows data protection, visit the following Microsoft Developer Network (MSDN) Web site:For more information about the LoadUserProfile function, visit the following MSDN Web site: