Erro de comunicação com servidor ao configurar CRM cliente: “Falha na autenticação porque o participante remoto fechou o fluxo de transporte”
Cliente encontra dificuldades para configurar o Microsoft Dynamics CRM for Outlook no ambiente Dynamics CRM On-Premises (publicado com IFD) ou Dynamics CRM Online.
Focando-se no ambiente On-premises, nota-se que a configuração ocorre com êxito na rede interna do cliente.
Característica comum é que a credencial não chega a ser solicitada.
Mensagem de erro na interface de usuário:
Há um problema na comunicação com o servidor do Microsoft Dynamics CRM. Talvez esse servidor não esteja disponível. Tente novamente mais tarde. Se o problema persistir, contate o administrador do sistema.
Mensagem de erro nos logs do CRM for Outlook:
Error connecting to URL: {0} Exception: {1}| https://crm.contoso.com/XRMServices/2011/Discovery.svc, System.InvalidOperationException: O metadados contém uma referência que não pode ser resolvida: 'https://crm.contoso.com/XRMServices/2011/Discovery.svc?wsdl&sdkversion=71'. ---> System.Net.WebException: A conexão subjacente estava fechada: Erro inesperado em um envio. ---> System.IO.IOException: Falha na autenticação porque o participante remoto fechou o fluxo de transporte.
em System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
em System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
em System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
em System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
em System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
em System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
em System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
em System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
em System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
em System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
em System.Net.ConnectStream.WriteHeaders(Boolean async)
--- Fim do rastreamento de pilha de exceções internas ---
em System.Net.HttpWebRequest.GetResponse()
em System.ServiceModel.Description.MetadataExchangeClient.MetadataLocationRetriever.DownloadMetadata(TimeoutHelper timeoutHelper)
em System.ServiceModel.Description.MetadataExchangeClient.MetadataRetriever.Retrieve(TimeoutHelper timeoutHelper)
--- Fim do rastreamento de pilha de exceções internas ---
em System.ServiceModel.Description.MetadataExchangeClient.MetadataRetriever.Retrieve(TimeoutHelper timeoutHelper)
em System.ServiceModel.Description.MetadataExchangeClient.ResolveNext(ResolveCallState resolveCallState)
em System.ServiceModel.Description.MetadataExchangeClient.GetMetadata(MetadataRetriever retriever)
em Microsoft.Xrm.Sdk.Client.ServiceMetadataUtility.RetrieveServiceEndpointMetadata(Type contractType, Uri serviceUri, Boolean checkForSecondary)
em Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1..ctor(Uri serviceUri, Boolean checkForSecondary)
em Microsoft.Xrm.Sdk.Client.ServiceConfigurationFactory.CreateConfiguration[TService](Uri serviceUri, Boolean enableProxyTypes, Assembly assembly)
em Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.DiscoverAuthUsingServiceMetadata(Uri endPoint, Uri webEndPoint)
em Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.GetAuthProviderForDeployment(Uri endPoint, Uri webEndPoint)
em Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo`1.DeploymentInfo`1.ValidateAuthProvider()
em Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo`1.SortAndValidateDeployments()
Mensagem de erro nos traces de Fiddler:
HTTP/1.1 200 Connection Established
FiddlerGateway: Direct
StartTime: 14:50:31.943
Connection: close
fiddler.network.https> HTTPS handshake to crm.contoso.com (for #7) failed. System.IO.IOException Falha na autenticação porque o participante remoto fechou o fluxo de transporte.
Ao coletar traces de Netmon na estação cliente, nota-se que o three hand shake é realizado com êxito, mas a conexão TLS é interrompida:
190 14:51:50 12/11/2015 4.1433287 IP-Origem IP-CRM TCP TCP:Flags=......S., SrcPort=57465, DstPort=HTTPS(443), PayloadLen=0, Seq=2154799555, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192
191 14:51:50 12/11/2015 4.1745046 IP-CRM IP-Origem TCP TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=57465, PayloadLen=0, Seq=719210808, Ack=2154799556, Win=8192 ( Negotiated scale factor 0x8 ) = 2097152
192 14:51:50 12/11/2015 4.1746501 IP-Origem IP-CRM TCP TCP:Flags=...A...., SrcPort=57465, DstPort=HTTPS(443), PayloadLen=0, Seq=2154799556, Ack=719210809, Win=64 (scale factor 0x8) = 16384
193 14:51:50 12/11/2015 4.1751226 IP-Origem IP-CRM TLS TLS:TLS Rec Layer-1 HandShake: Client Hello.
195 14:51:50 12/11/2015 4.1916129 IP-CRM IP-Origem TCP TCP:Flags=...A...F, SrcPort=HTTPS(443), DstPort=57465, PayloadLen=0, Seq=719210809, Ack=2154799691, Win=512 (scale factor 0x8) = 131072
196 14:51:50 12/11/2015 4.1917124 IP-Origem IP-CRM TCP TCP:Flags=...A...., SrcPort=57465, DstPort=HTTPS(443), PayloadLen=0, Seq=2154799691, Ack=719210810, Win=64 (scale factor 0x8) = 16384
197 14:51:50 12/11/2015 4.1923874 IP-Origem IP-CRM TCP TCP:Flags=...A...F, SrcPort=57465, DstPort=HTTPS(443), PayloadLen=0, Seq=2154799691, Ack=719210810, Win=64 (scale factor 0x8) = 16384
Este comportamento é explicado pelo fato do protocolo TLS 1.0 estar bloqueado em dispositivos da rede local, tais como Firewalls ou Proxies.
Importante relembrar que Microsoft .NET Framework tem como protocolo padrão SSL/TLS como TLS 1.0 | SSL 3.0.
Para solucionar o problema, deve-se aplicar o update de segurança para .NET Framework, conforme descrito nos artigos:
Microsoft security advisory: Vulnerability in the .NET Framework: May 13, 2014
https://support.microsoft.com/en-us/kb/2960358
Microsoft Security Advisory 2960358
https://technet.microsoft.com/en-us/library/security/2960358
Este update poderá ser aplicado de forma manual, através de chaves de registro:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001
Existem vulnerabilidades públicas para o TLS 1.0, tal como descrito no artigo:
TLS/SSL Security Considerations
Pontos relevantes para artigo do update de segurança para .NET Framework:
Microsoft Security Advisory 2960358
https://technet.microsoft.com/en-us/library/security/2960358
Existem pré-requisitos para instalar as atualizações abordadas neste aviso?
Sim. A pré-instalação da atualização 2868725, lançada em novembro de 2013, é um pré-requisito para instalar as atualizações abordadas neste aviso, com exceção das atualizações que se aplicam ao Windows 8.1, Windows Server 2012 R2 e Windows RT 8.1. Para obter mais informações sobre a atualização de pré-requisito, consulte o Artigo 2868725 (em inglês) da Microsoft Knowledge Base.
As atualizações estão disponíveis no Windows Update?
Não. Como as atualizações podem afetar a compatibilidade com aplicativos e serviços existentes ao desativar a cifra RC4 não protegida, a Microsoft está fornecendo as atualizações somente quando solicitadas (somente através do Centro de Download da Microsoft e do Catálogo do Microsoft Update). As atualizações não estão sendo fornecidas via Windows Update para que os clientes possam planejar e testar as novas configurações e desabilitar o RC4 antes da implementação em seus ambientes.
Qual é o escopo do comunicado?
O objetivo deste comunicado é notificar os clientes de que há uma atualização disponível para o Microsoft .NET Framework que desativa RC4 no protocolo TLS e que também altera o protocolo padrão SSL/TLS de TLS 1.0 | SSL 3.0 para TLS 1.2 | TLS 1.1 | TLS 1.0 se você está executando um aplicativo .NET no tempo de execução .NET 4.5 ou superior.
Para que um atacante pode usar a vulnerabilidade?
O uso do RC4 no TLS pode permitir que um atacante execute ataques a intermediários e recupere texto sem formatação de sessões criptografadas.
O que é um ataque de intermediário?
Um ataque de intermediário ocorre quando um atacante desvia a comunicação entre dois usuários pelo computador do atacante, sem o conhecimento dos dois usuários que se comunicam. Cada usuário na comunicação, sem saber, envia e recebe tráfego do atacante, achando que está se comunicando somente com o usuário pretendido.
O que a atualização faz?
A atualização aceita a remoção do RC4 como uma criptografia disponível em sistemas afetados por configurações do registro. A Microsoft recomenda que os clientes testem todas as configurações novas para desabilitar o RC4 antes de implementá-las em seus ambientes.
O que é TLS?
TLS (Transport Layer Security) é um protocolo padrão usado para fornecer comunicações seguras pela Web na Internet ou em intranets. Ele permite que os clientes autentiquem servidores ou que os servidores autentiquem clientes. Ele também fornece um canal seguro criptografando as comunicações. TLS é o sucessor do protocolo SSL (Secure Sockets Layer).
O que é RC4?
RC4 é uma cifra de fluxo usada na criptografia e na descriptografia.
Outros artigos interessantes:
TLS/SSL Settings
https://technet.microsoft.com/en-us/library/dn786418.aspx
TLS/SSL and .NET Framework 4.0
https://www.simple-talk.com/dotnet/.net-framework/tlsssl-and-.net-framework-4.0
Using TLS 1.2 with WCF
https://blogs.msdn.com/b/benjaminperkins/archive/2014/11/04/using-tls-1-2-with-wcf.aspx
Support for SSL/TLS protocols on Windows
https://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx
Fiddler and Modern TLS Versions
https://www.telerik.com/blogs/fiddler-and-modern-tls-versions