Question

enter code hereHi All,

I have a simple windows service application that connects to a WCF service. The windows service is deployed on our Development Application Server, and the WCF service onto our DEV Web Server. The service is setup to run under the appropriate service account (we have a couple of other services that also communicate with WCF services located on the same servers running under the same account).

My problem is that when the service tries to connect to the WCF service it errors with the following error message (gleamed from the service trace logs):

The SecurityContextSecurityToken with context-id=urn:uuid:a02a1879-3297-4dee-8035-68eb30ed4195 (key generation-id=) is not registered.

The service works fine when running off of my local machine (I then run the service using my own domain account), and yes the service worked fine yesterday after it was deployed. But since today, it suddenly doesn’t 🙁

The WCF service config is setup as follows :

<system.serviceModel>
<diagnostics>
  <messageLogging logMalformedMessages="true" logMessagesAtTransportLevel="true" />
</diagnostics>
<services>
  <service name="Calm.Leads.ImportService.LeadImportService" 
  behaviorConfiguration="Calm.Leads.ImportService.LeadImportService">
    <!-- Service Endpoints -->
    <endpoint address="" binding="wsHttpBinding" contract="Calm.Leads.ImportService.ILeadImportService">
      <!-- 
          Upon deployment, the following identity element should be removed or replaced to reflect the 
          identity under which the deployed service runs.  If removed, WCF will infer an appropriate identity 
          automatically.
      -->
      <identity>
        <dns value="localhost"/>
      </identity>
    </endpoint>
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
  </service>
</services>
<behaviors>
  <serviceBehaviors>
    <behavior name="Calm.Leads.ImportService.LeadImportService">
      <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
      <serviceMetadata httpGetEnabled="true"/>
      <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
      <serviceDebug includeExceptionDetailInFaults="false"/>
    </behavior>
  </serviceBehaviors>
</behaviors>

The client side config is as follows:

<system.serviceModel>
<bindings>
  <wsHttpBinding>
    <binding name="WSHttpBinding_ILeadImportService" closeTimeout="00:01:00" openTimeout="00:01:00" 
    receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false" transactionFlow="false" 
    hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" 
    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
      <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
      maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false" />
      <security mode="Message">
        <transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
        <message clientCredentialType="Windows" negotiateServiceCredential="true" 
        algorithmSuite="Default" establishSecurityContext="true" />
      </security>
    </binding>
  </wsHttpBinding>
</bindings>
<client>
  <endpoint address="http://calm.intranet.dev/LeadsImportService/LeadImportService.svc" 
  binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ILeadImportService" 
  contract="LeadImportService.ILeadImportService" name="WSHttpBinding_ILeadImportService">
    <identity>
      <dns value="localhost" />
    </identity>
  </endpoint>
</client>

And then finally the trace of the exception is as follows:

The SecurityContextSecurityToken with context-id=urn:uuid:a02a1879-3297-4dee-8035-68eb30ed4195 (key generation-id=) is not registered.

at System.ServiceModel.Security.WSSecureConversation.SecurityContextTokenEntry.ReadTokenCore(XmlDictionaryReader reader,
SecurityTokenResolver tokenResolver)
at System.ServiceModel.Security.WSSecurityTokenSerializer.ReadTokenCore(XmlReader reader, SecurityTokenResolver tokenResolver)
at System.IdentityModel.Selectors.SecurityTokenSerializer.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver)
at System.ServiceModel.Security.ReceiveSecurityHeader.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver, IList1
allowedTokenAuthenticators, SecurityTokenAuthenticator& usedTokenAuthenticator)
at System.ServiceModel.Security.ReceiveSecurityHeader.ReadToken(XmlDictionaryReader reader, Int32 position, Byte[] decryptedBuffer,
SecurityToken encryptionToken, String idInEncryptedForm, TimeSpan timeout)
at System.ServiceModel.Security.ReceiveSecurityHeader.ExecuteFullPass(XmlDictionaryReader reader)
at System.ServiceModel.Security.StrictModeSecurityHeaderElementInferenceEngine.ExecuteProcessingPasses(ReceiveSecurityHeader securityHeader,
XmlDictionaryReader reader)
at System.ServiceModel.Security.ReceiveSecurityHeader.Process(TimeSpan timeout)
at System.ServiceModel.Security.MessageSecurityProtocol.ProcessSecurityHeader(ReceiveSecurityHeader securityHeader, Message& message,
SecurityToken requiredSigningToken, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates)
at System.ServiceModel.Security.SymmetricSecurityProtocol.VerifyIncomingMessageCore(Message& message, String actor, TimeSpan timeout,
SecurityProtocolCorrelationState[] correlationStates)
at System.ServiceModel.Security.MessageSecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout,
SecurityProtocolCorrelationState[] correlationStates)
at System.ServiceModel.Channels.SecurityChannelListener1.ServerSecurityChannel1.VerifyIncomingMessage(Message& message, TimeSpan
timeout, SecurityProtocolCorrelationState[] correlationState)
at System.ServiceModel.Channels.SecurityChannelListener1.SecurityReplyChannel.ProcessReceivedRequest(RequestContext requestContext, TimeSpan
timeout)
at System.ServiceModel.Channels.SecurityChannelListener1.ReceiveRequestAndVerifySecurityAsyncResult.ProcessInnerItem(RequestContext
innerItem, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelListener1.ReceiveItemAndVerifySecurityAsyncResult2.OnInnerReceiveDone()
at
System.ServiceModel.Channels.SecurityChannelListener1.ReceiveItemAndVerifySecurityAsyncResult2.InnerTryReceiveCompletedCallback(IAsyncResult
result)
at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.InputQueue1.AsyncQueueReader.Set(Item item)
at System.ServiceModel.Channels.InputQueue1.Dispatch()
at System.ServiceModel.Channels.InputQueue1.OnDispatchCallback(Object state)
at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.WorkItem.Invoke2()
at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.WorkItem.OnSecurityContextCallback(Object o)
at System.Security.SecurityContext.Run(SecurityContext securityContext, ContextCallback callback, Object state)
at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.WorkItem.Invoke()
at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.ProcessCallbacks()
at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.CompletionCallback(Object state)
at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.ScheduledOverlapped.IOCallback(UInt32 errorCode, UInt32 numBytes,
NativeOverlapped* nativeOverlapped)
at System.ServiceModel.Diagnostics.Utility.IOCompletionThunk.UnhandledExceptionFrame(UInt32 error, UInt32 bytesRead, NativeOverlapped*
nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

Both the Web and App servers are Windows Server 2003 SP1 machines, with the web server running IIS 6.

Has anyone had a similar issue? Anyone knows what might be causing it?

Answer 1

Found the following which may help. Seems to be an unaddressed bug in IIS. Suspect its been fixed in 2008 (v7), but not 2003 (v6), as it was only been on the go since 2004. Security token seems to get lost if your running more that 1 worker process. Here is the problem of context getting lost with NLB, and here is a link to sticky sessions and NLB, if you are using it, which may help. Sticky Sessions in NLB in win 2k3 IIS6

SecurityContextSecurityToken is not registered

Hope that helps.
scope_creep