The security timestamp is invalid because its creation time ('11/9/2007 10:37:07 PM') is in the future. Current time is '11/9/2007 10:28:52 PM' and allowed clock skew is '00:05:00'.
After fixing the user's clock, which was roughly 8 minutes fast, everything worked great. The next question is "How do I increase the maximum skew time"? It took a bit of searching to figure out that I need to create a custom binding to change the values. Here is an example of how to do it:
<bindings>
<customBinding>
<binding name="MaxClockSkewBinding">
<textMessageEncoding />
<security authenticationMode="Kerberos">
<localClientSettings maxClockSkew="00:07:00" />
<localServiceSettings maxClockSkew="00:07:00" />
<secureConversationBootstrap />
</security>
<httpTransport />
</binding>
</customBinding>
</bindings>
For more information, see How To: Set a Max Clock Skew on MSDN.
More References:
- Custom Bindings page on MSDN shows the proper way to stack your collection of binding elements.
- How To: Create a Custom Binding Using the SecurityBindingElement which shows how to build the a custom binding.
3 comments:
Extending the clock skew is the wrong answer. The local time needs to fixed by using ntp pointed at time server. Preferably at the DC issuing the kerberos ticket.
My issue is not that our servers are out-of-sync. The problem is that our many USERS on their home computers or laptops are not using a time server.
right one Dave ... there's gotta be an option to disable the timestamp check all together. MSFT??
Post a Comment