03-06-2013 05:36 PM
Hello,
I noticed this on multiple instances, when CPO console in one timezone (example: CST) tries to access a CPO Server in a totally different timezone, the console is not able to login to the CPO Server and I see this error message:
"An error occurred when verifying security for the message"
Is there any known issue with console accessing the CPO server and some handshake happening?
From the logs:
@@Logging from process Tidal.Automation.Console.Loader.exe(id=13248)
||8|2013/03/06 19:20:00.365|13736||||Could not get server ID for assembly store connection:
||9|2013/03/06 19:20:00.366|13736||||EXCEPTION (System.ServiceModel.Security.MessageSecurityException): An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
Stack Trace:
Server stack trace:
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)
at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Tidal.Automation.Common.AssemblyManager.IAssemblyManager.GetServerId()
at Tidal.Automation.WinForms.Loader.AssemblyStore.GetRequiredFiles()
||10|2013/03/06 19:20:00.366|13736|||| INNER EXCEPTION (System.ServiceModel.FaultException): An error occurred when verifying security for the message.
Stack Trace:
||11|2013/03/06 19:20:37.696|13736||||Could not get server ID for assembly store connection:
||12|2013/03/06 19:20:37.696|13736||||EXCEPTION (System.ServiceModel.Security.MessageSecurityException): An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
Stack Trace:
Server stack trace:
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)
at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Tidal.Automation.Common.AssemblyManager.IAssemblyManager.GetServerId()
at Tidal.Automation.WinForms.Loader.AssemblyStore.GetRequiredFiles()
||13|2013/03/06 19:20:37.696|13736|||| INNER EXCEPTION (System.ServiceModel.FaultException): An error occurred when verifying security for the message.
Stack Trace:
Solved! Go to Solution.
03-06-2013 06:21 PM
More important than whether their timezones differ is whether their *times* differ.
12:00 in EST = 9:00 in PST as far as everyone (including Windows) is concerned.
If both are showing 12:00 then time sync is the problem, and this would cause authentication handshake issues. NT authentication only allows something like 10 minutes of clock skew. My example here has 180 minutes of clock skew.
03-07-2013 05:41 AM
We do not support PO in a workgroup. Within a domain, the domain controllers serve as the time authority.
http://support.microsoft.com/kb/307897
Typically the domain controller is set up to sync to an internet time service so that all computers in the domain are perfectly on time.
03-06-2013 05:42 PM
03-06-2013 06:21 PM
More important than whether their timezones differ is whether their *times* differ.
12:00 in EST = 9:00 in PST as far as everyone (including Windows) is concerned.
If both are showing 12:00 then time sync is the problem, and this would cause authentication handshake issues. NT authentication only allows something like 10 minutes of clock skew. My example here has 180 minutes of clock skew.
03-07-2013 05:41 AM
We do not support PO in a workgroup. Within a domain, the domain controllers serve as the time authority.
http://support.microsoft.com/kb/307897
Typically the domain controller is set up to sync to an internet time service so that all computers in the domain are perfectly on time.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide