Client and server clock needs to be synchronized?

I'v been trying to get wsHttpBinding to work over the internet, and finally found out why I always got errors.

In the trace log I got the following exception:

The security timestamp is invalid since its creation time ('20/06/2006 20:43:12') is in the future. The security timestamp is invalid since its creation time ('20/06/2006 20:43:12') is in the future. Current time is '20/06/2006 20:32:17' and allowed clock skew is '00:05:00'.

Setting the clock of my client system equal to the clock on the server solved my problems.

How is WCF supposed to work with machines that may not have their clock set correctly This is going to give a lot of pain at deployment time! The client gets an exception, but the information that his clock is out of sync is completely lost. At least this exception should be properly propagated to the client.

Also, I haven't seen any reference to this issue in the documentation. This should be clearly pointed out in the section about how to get the samples to work on different machines.

Answer this question

Client and server clock needs to be synchronized?

betobeto
A possible solution would be to use the windows time service to sync both computers.

Hital

If you use a custom binding you can usethe maxClockSkew on both the client and server.

<security>
  <localServiceSettings detectReplays="Boolean"
   issuedCookieLifeTime="TimeSpan"
   maxStatefulNegotiations="Integer"
      replayCacheSize="Integer"
   maxClockSkew="TimeSpan" 
   negotiationTimeout="TimeSpan"
   replayWindow="TimeSpan"
   inactivityTimeout="TimeSpan"
   sessionKeyRenewalInterval="TimeSpan"
   sessionKeyRolloverInterval="TimeSpan"
   reconnectOnTransportFailure="Boolean"
   maxConcurrentSessions="Integer"
   timestampValidityDuration="TimeSpan" />
</security>

A TimeSpan that specifies the maximum time difference between the system clocks of the two communicating parties. The default value is "00:05:00".

When this value is set to the default, the receiver accepts messages with send-time time stamps up to 5 minutes later or earlier than the time the message was received. Messages that do not pass the send-time test are rejected. This setting is used in conjunction with the replayWindow attribute.

Thanks,

Scott

kallzz
Yes, but my point is that if you 're providing a service to the general public, you have no control over their clock.
Jagadisk Kulkarni
Hi,

I am also using wsHttpbinding too, for my application but, i get a error saying
Unhandled Exception: System.ServiceModel.FaultException: The request for security token could not be satisfied because authentication failed.

Could you please help me out on how to resolve this issue...
Thank you
Sree
LHQ
I don't have any profound ideas for synching the clocks, hopefully the msft guys can come to the rescue here. A simple and naive solution is adjust the "allowed clock skew".

As for exception propagation, WCF is not going to just propagate all exceptions thrown on the server as they do not form a part of the contract that you define. To propagate any .NET exception back to the client you would be forcing all contracts to have a very large implicit chunk of faults that every method could return. When dealing with interoperability scenarios where the other end is not .NET then the clients would have to write a large chunk of code to deal with all these .NET exceptions. However you could have a look at the returnUnknownExceptionsAsFaults parameter in your server config file, e.g. add the following behaviours section:

<system.serviceModel>
<services>
<service name="YourServiceName"
behaviorConfiguration="ServiceBehavior">

</service>
</services>
<behaviors>
<behavior
name="ServiceBehavior"
returnUnknownExceptionsAsFaults="true" >
</behavior>
</behaviors>
</system.serviceModel>

However this is more of a debugging feature as is not really intended for production.

As for the documentation, it's a beta! I feel your pain, but until it's release documentation is going to continue to be sketchy.

Donovan
Venu_nair
Nico Vuyge wrote:
Also, I haven't seen any reference to this issue in the documentation. This should be clearly pointed out in the section about how to get the samples to work on different machines.

What security provider are you using

Clock skew problems are common when you're using Kerberos - it's very strict about it since security tickets have their expiration times based on it.

If you're going over the internet and using some other authentication model (basic auth, anonymous, whatever) I don't see why clock skew should be an issue, but I don't know if WCF doesn't add any checks of its own.
Client and server clock needs to be synchronized?

Answer this question