Authentication failed on the remote side

Every so often in version: 10.1.400.24 day 1 of a GO LIVE we are encountering the following random error on different clients.

Any thoughts or clues as to what’s causing this?

Exception caught in: mscorlib

Error Detail

Message: Authentication failed on the remote side (the stream might still be available for additional authentication attempts).
Inner Exception Message: Authentication failed on the remote side (the stream might still be available for additional authentication attempts).
Program: CommonLanguageRuntimeLibrary
Method: HandleReturnMessage

Client Stack Trace

Server stack trace:
at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeInitiator.OnInitiateUpgrade(Stream stream, SecurityMessageProperty& remoteSecurity)
at System.ServiceModel.Channels.StreamSecurityUpgradeInitiatorBase.InitiateUpgrade(Stream stream)
at System.ServiceModel.Channels.ConnectionUpgradeHelper.InitiateUpgrade(StreamUpgradeInitiator upgradeInitiator, IConnection& connection, ClientFramingDecoder decoder, IDefaultCommunicationTimeouts defaultTimeouts, TimeoutHelper& timeoutHelper)
at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment1 preamble, TimeoutHelper& timeoutHelper) at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper) at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout) at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Channels.SecurityChannelFactory1.ClientSecurityChannel`1.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.CommunicationObject.Open()

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 System.ServiceModel.ICommunicationObject.Open()
at Epicor.ServiceModel.Channels.ChannelEntry1.CreateNewChannel() at Epicor.ServiceModel.Channels.ChannelEntry1.CreateChannel()
at Epicor.ServiceModel.Channels.ChannelEntry1.GetContract() at Epicor.ServiceModel.Channels.ImplBase1.GetChannel()
at Epicor.ServiceModel.Channels.ImplBase`1.HandleContractBeforeCall()
at Ice.Proxy.BO.ReportMonitorImpl.GetRowsKeepIdleTime(String whereClauseSysRptLst, Int32 pageSize, Int32 absolutePage, Boolean& morePages)
at Ice.Adapters.ReportMonitorAdapter.GetRowsKeepIdleTime(SearchOptions opts, Boolean& MorePages)

Inner Exception

Authentication failed on the remote side (the stream might still be available for additional authentication attempts).

Inner Stack Trace

at System.Net.Security.NegoState.ProcessReceivedBlob(Byte[] message, LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.StartReceiveBlob(LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.CheckCompletionBeforeNextReceive(LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.StartSendBlob(Byte[] message, LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.CheckCompletionBeforeNextSend(Byte[] message, LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.ProcessReceivedBlob(Byte[] message, LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.StartReceiveBlob(LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.CheckCompletionBeforeNextReceive(LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.StartSendBlob(Byte[] message, LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, ChannelBinding binding, String targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel allowedImpersonationLevel)
at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, String targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel allowedImpersonationLevel)
at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeInitiator.OnInitiateUpgrade(Stream stream, SecurityMessageProperty& remoteSecurity)

Inner Exception

No authority could be contacted for authentication

Inner Stack Trace

Have you tried opening a support call? I imagine they’ve seen these before.

That’s the next step if no one on here has a clue.

What kind of authentication are you doing? Windows?

Yes

“No authority could be contacted for authentication” - looks like IIS cannot speak to domain controller.

If running Windows then make sure the Client and Server both are on the same domain or at least have a trust relationship. This is a vanilla Windows Auth issue nothing to do with ERP 10. Try just doing a file share on the server and see if the client can connect - I assume not.

We are having a similar issue but are NOT using SSO and we are using ‘usernamewindowschannel’ authentication. We have double checked that the appservers binding is set to ‘usernamewindowschannel’ we also made sure the task agent is using the same binding and it is. We also looked at the .config file in the client deployment to make sure it to is set to the same binding, it is also. Could a user selecting the ‘require sso’ checkbox in user account maintenance cause this error even though the appserver isn’t setup for sso and it’s trying to use sso?

usernamewindowschannel still uses domain security, so I’d check why this error is happening.
Google the error “No authority could be contacted for authentication” - the simplest soultion is to Unregister and register the server with Domain. - "No authority could be contacted for authentication"
but there are others…

Correct - Windows domains are used to secure communications client to server similar to SSL. It just does not use Windows Identities.

Hi Guys,

Did any one find a solution to this Authentication problem?

There are variations to these kinds of errors and their solution depending on which protocol binding you are using.
Is it a Windows flavor or a SSL flavor?

In general there is a trust problem - In a Windows world, it would be the client and server are not trusting the same domain.
In a SSL world, the client does not trust the servers certificate (Like you get in a browser when a certificate is bad).

Which version issue are you having?

Hi Bart,

This is a windows situation, both Client and server are on same domain. The thing is we see this error when we use server name in net.tcp url, if we use IP address it is not a problem. we are currently on 10.1.600.13

Windows and Username token over Window encrypted channel both just use default Windows security to access the server - just like browsing for a file on a file server. Something is going on at the domain level - what’s the exact error being received on the client? Logged to Windows Event Log?

No issues accessing the fileserver. This is the message we get in event log of server

Transport authentication failed.
Service: net.tcp://Servername/ERP1016001/Ice/BO/ZDataTable.svc
ClientIdentity:
ActivityId:
SecurityNegotiationException: Authentication failed on the remote side (the stream might still be available for additional authentication attempts). —> AuthenticationException: Authentication failed on the remote side (the stream might still be available for additional authentication attempts). —> Win32Exception: The target principal name is incorrect

On your server, are you using NTLM or Kerberos? More explicitly, are you disabling one?

This is how it looks on the server IIS

[/uploads/default/original/2X/2/221e1e1ef161ce082e4a821996720bcad9c3c029.png]

Thanks,
Akbar

hmm… odd.

There was an issue with SSPI back in the day that we fixed in 10.1.0 timeframe. I think you should open a ticket and reference SCR #127612. That is similar. Something is odd with NTLM and how it’s interacting with your domain security.

Thanks Bart, I will open up a service request.

Thanks,
Akbar