# Authentication failed on the remote side **Category:** [Epicor ERP 10](https://www.epiusers.help/c/e10/5) **Created:** 2017-01-03 19:49 UTC **Views:** 15193 **Replies:** 18 **URL:** https://www.epiusers.help/t/authentication-failed-on-the-remote-side/36769 --- ## Post #1 by @anon43228453 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, ArraySegment`1 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.SecurityChannelFactory`1.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.ChannelEntry`1.CreateNewChannel() at Epicor.ServiceModel.Channels.ChannelEntry`1.CreateChannel() at Epicor.ServiceModel.Channels.ChannelEntry`1.GetContract() at Epicor.ServiceModel.Channels.ImplBase`1.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 ================= --- ## Post #2 by @josecgomez [quote="EpiInfo, post:1, topic:36769"] Authentication failed on the remote side (the stream might still be available for additional authentication attempts). [/quote] Have you tried opening a support call? I imagine they've seen these before. --- ## Post #3 by @anon43228453 That's the next step if no one on here has a clue. --- ## Post #4 by @Noffie What kind of authentication are you doing? Windows? --- ## Post #5 by @anon43228453 Yes --- ## Post #6 by @Olga "No authority could be contacted for authentication" - looks like IIS cannot speak to domain controller. --- ## Post #7 by @Bart_Elia 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. --- ## Post #8 by @anon37088009 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? --- ## Post #9 by @Olga 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. - https://forums.asp.net/t/1262572.aspx but there are others... --- ## Post #10 by @Bart_Elia Correct - Windows domains are used to secure communications client to server similar to SSL. It just does not use Windows Identities. --- ## Post #11 by @alakhani Hi Guys, Did any one find a solution to this Authentication problem? --- ## Post #12 by @Bart_Elia 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? --- ## Post #13 by @alakhani [quote="Bart_Elia, post:12, topic:36769"] eral 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). [/quote] 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 --- ## Post #14 by @Bart_Elia 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? --- ## Post #15 by @alakhani 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 --- ## Post #16 by @Bart_Elia On your server, are you using NTLM or Kerberos? More explicitly, are you disabling one? --- ## Post #17 by @alakhani This is how it looks on the server IIS [/uploads/default/original/2X/2/221e1e1ef161ce082e4a821996720bcad9c3c029.png] Thanks, Akbar![image001|690x352](upload://4ROLas0gsFVryXTBj8C1KDXSYcN.png) --- ## Post #18 by @Bart_Elia 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. --- ## Post #19 by @alakhani Thanks Bart, I will open up a service request. Thanks, Akbar --- **Canonical:** https://www.epiusers.help/t/authentication-failed-on-the-remote-side/36769 **Original content:** https://www.epiusers.help/t/authentication-failed-on-the-remote-side/36769