Freigeben über

Microsoft Dynamics 365 Customer Engagement (online), um TLS 1.2 für konnektivität erforderlich zu machen

  • Artikel

In Dynamics 365 (online) Version 9.x und Dynamics 365 (online) Government Version 8.2 werden wir damit beginnen, Verbindungen mit Kundenbindungsanwendungen zu verlangen, um TLS 1.2 (oder besser) Sicherheit zu nutzen. Dies entspricht aktualisierten Microsoft- und Branchensicherheitsrichtlinien und bewährten Methoden, und Möglicherweise müssen Sie Maßnahmen ergreifen, um die Konnektivität mit Dynamics 365 Customer Engagement-Anwendungen aufrechtzuerhalten. Überprüfen Sie die folgenden Informationen, um festzustellen, ob Sie betroffen sind und welche Schritte Sie möglicherweise ausführen müssen.

Gilt für: Microsoft Dynamics 365
Ursprüngliche KB-Nummer: 4051700

Was ist TLS?

TLS steht für Transport Layer Security und ist ein Protokoll, das zum Schutz der Privatsphäre der über das Internet kommunizierten Informationen dient. TLS kommt in vielen Webbrowsern und Anwendungen zum Einsatz, die über HTTPS und TCP kommunizieren.

Was ändert sich?

Heute unterstützen alle Dynamics 365 Customer Engagement Online-Versionen TLS 1.0, 1.1 und 1.2, aber ab der Version von Dynamics 365 (Online) Version 9.x und Dynamics 365 (online) Government Version 8.2 werden wir damit beginnen, Verbindungen mit dem aktualisierten Produkt von Clients oder Browsern zu blockieren, die TLS 1.0 und 1.1 verwenden.

Hinweis

Diese Änderung betrifft nur Microsoft Dynamics 365 Online Customer Engagement, nicht lokale Versionen.

Wie werden Sie oder Ihre Kunden betroffen sein?

Alle Verbindungen mit Dynamics 365 (Online) Version 9.x oder Dynamics 365 (online) Government Version 8.2 schlagen fehl, wenn sie das TLS 1.2-Sicherheitsprotokoll nicht verwenden. Dies wirkt sich auf mehrere Dynamics-Dienste (unten aufgeführt) aus, einschließlich des Zugriffs auf die Dynamics 365 Customer Engagement-Webanwendung.

Wie können Sie oder Ihre Kunden vermeiden, betroffen zu sein?

Für unterstützte Webbrowser

Alle unterstützten Browser für Dynamics 365 Customer Engagement (Versionen 7.x – Version 9.x) entsprechen derzeit den TLS 1.2-Standards und funktionieren weiterhin wie zuvor. Wenn Sie jedoch das TLS 1.2-Protokoll in Ihrem Browser deaktiviert haben, sind Sie betroffen und verlieren die Verbindung zu Organisationen.

Für Entwicklertools, die von Microsoft bereitgestellt werden

Schauen Sie sich die Neuerungen in der Entwicklerdokumentation für Customer Engagement in Version 9.0 an, um die neuesten Informationen zu unseren Entwicklertools zu erhalten. Aktualisieren Sie die Entwicklungswerkzeuge über NuGet auf die neueste Version. Beispiele für Entwicklertools sind das Plug-In-Registrierungstool und das Konfigurationsmigrationstool. Version 9.0 dieser Tools ist abwärtskompatibel und kann für Dynamics 365 (online) Version 8.2 Government verwendet werden.

Für Code, der mit dem Dynamics 365 SDK erstellt wurde

Kompilieren Sie Ihre Clientanwendungen neu mit .NET Framework 4.6.2 oder höher. Wenn Ihr Code bereits mit .NET 4.6.2 oder höher kompiliert wurde, ist keine Aktion erforderlich. Für benutzerdefinierte Plug-Ins und Workflowassemblys sollte .NET 4.5.2 weiterhin verwendet werden.

Bekanntes Problem mit Visual Studio 2015

Wenn Sie Ihr Projekt/Ihre Projektmappe in Visual Studio 2015 im Debugmodus ausführen, gibt es ein bekanntes Problem, bei dem Sie möglicherweise keine Verbindung mit Dynamics 365 (Online) Version 9.x oder Dynamics 365 (online) Version 8.2 Government herstellen können. Dies geschieht unabhängig davon, ob Sie ein Zielframework von 4.6.2 oder höher verwenden. Dies kann auftreten, da der Visual Studio-Hostingprozess mit .NET 4.5 kompiliert wird. Dies bedeutet, dass tls 1.2 standardmäßig nicht unterstützt wird. Sie können den Visual Studio-Hostingprozess als Problemumgehung deaktivieren. Klicken Sie mit der rechten Maustaste auf den Namen Ihres Projekts in Visual Studio, und klicken Sie dann auf "Eigenschaften". Auf der Registerkarte "Debuggen " können Sie die Option "Visual Studio-Hostingprozess aktivieren" deaktivieren.

Hinweis

Dies wirkt sich nur auf die Debugerfahrung in Visual Studio 2015 aus. Dies wirkt sich nicht auf die erstellten Binärdateien oder ausführbaren Dateien aus. Dasselbe Problem tritt in Visual Studio 2017 nicht auf.

Ein wichtiger Hinweis für .NET-basierte Apps

Sie können das TLS 1.2-Protokoll mithilfe des folgenden Befehls erzwingen:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Dadurch wird das TLS 1.2-Sicherheitsprotokoll durchgängig erzwungen. Dies wird nicht empfohlen, da Sie das Risiko haben, dies zu aktualisieren, wenn ein neueres Sicherheitsprotokoll von der Branche übernommen wird.

Für vorhandenen Code, der nicht neu kompiliert werden kann

Sie können eine Registrierungseinstellung unter Windows verwenden, die .NET erzwingt, um den größtmöglichen Sicherheitsstandard zu nutzen.

Hinweis

Dies ist eine computerweite Einstellung und kann unerwünschte Auswirkungen haben. Es wird empfohlen, dass Sie oder Ihr Kunde die Methode zum Neukompilieren auf .NET 4.6.2 oder höher verwenden.

Um die Registrierungseinstellungen zu aktualisieren, die erzwingen, dass .NET 4.5.2 computerweit TLS 1.2 bevorzugt, wird im Artikel Microsoft Security Advisory 2960358 dokumentiert. Siehe Abschnitt "Vorgeschlagene Aktionen " unter "Manuelles Deaktivieren von RC4 in TLS auf Systemen mit .NET Framework 4.5/4.5.1/4.5.2".

Für Nicht-.NET-Software

Erkundigen Sie sich bei Ihrem Anbieter, wie TLS 1.2 aktiviert wird. Für die meisten Sprachen kann dies mit einem einfachen Konfigurationseintrag erfolgen.

Für PowerShell

Fügen Sie [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12 zu Ihrem PowerShell-Skript hinzu, bevor Sie Get-CrmConnection aufrufen.

Für Dynamics 365 für Microsoft Outlook

Dynamics 365 (online) Government Version 8.2 und Dynamics 365 (online) Version 9.x

Für Unified Service Desk (USD)

Laden Sie die neueste Version von Unified Service Desk herunter (Versionen 3.1, 3.2 und 3.3 sind TLS 1.2 kompatibel).

Wenn Sie weiterhin ältere Versionen von Unified Service Desk verwenden möchten, müssen Sie die Registrierungseinträge des Clientdesktops aktualisieren.

Für Dynamics 365 zur Berichterstellung

Dynamics 365 (online) Government Version 8.2

Dynamics 365 (Online) Version 9.x

Dynamics 365 für den E-Mail-Router

Dynamics 365 (online) Government Version 8.2

Dynamics 365 (Online) Version 9.x

Fehlerbeispiele

Nachfolgend finden Sie einige potenzielle Konnektivitätsfehler, die auftreten können, wenn ein Sicherheitsprotokoll von Nicht-TLS 1.2 verwendet wird:

Browserfehler

"Mit dieser Seite kann keine sichere Verbindung hergestellt werden.
Dies kann darauf zurückzuführen sein, dass die Website veraltete oder unsichere TLS-Sicherheitseinstellungen verwendet. Dies geschieht weiter, versuchen Sie, sich an den Besitzer der Website zu wenden."

Connectorfehler

Microsoft.Xrm.Tooling.CrmConnectControl Information: 8: Anmeldestatus in Connect ist = Verbindung zu Microsoft Dynamics CRM wird validiert...

Microsoft.Xrm.Tooling.Connector.CrmServiceClient Fehler: 2 : FEHLER BEIM ANFORDERN DES Tokens aus dem Authentifizierungskontext

Microsoft.Xrm.Tooling.Connector.CrmServiceClient-Fehler: 2: Quelle : mscorlib

Methode: ThrowIfExceptional

Fehler: Mindestens ein Fehler ist aufgetreten.

Stack Trace : at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)

at System.Threading.Tasks.Task'1.GetResultCore(Boolean waitCompletionNotification)

at System.Threading.Tasks.Task'1.get_Result()

at Microsoft.Xrm.Tooling.Connector.CrmWebSvc.ExecuteAuthenticateServiceProcess(Uri serviceUrl, ClientCredentials clientCredentials, UserIdentifier user, String clientId, Uri redirectUri, PromptBehavior promptBehavior, String tokenCachePath, Boolean isOnPrem, String authority, Uri& targetServiceUrl, AuthenticationContext& authContext, String& resource)

Innere Ausnahmeebene 1:

Quelle: Microsoft.IdentityModel.Clients.ActiveDirectory

Methode: Close

Fehler: Objektverweis wurde nicht auf eine Instanz eines Objekts festgelegt.

Stack Trace : at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebResponseWrapper.Close()

at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationParameters.<CreateFromResourceUrlCommonAsync>d__0.MoveNext()

--- Ende der Stapelablaufverfolgung von der vorherigen Position, an der die Ausnahme geworfen wurde ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationParameters.<CreateFromResourceUrlAsync>d__8.MoveNext()"

Entwicklungstools-Fehler

"Innere Ausnahmeebene 1:

Quelle : System

Methode: GetResponse

Fehler: Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden.

Stack Trace : at System.Net.HttpWebRequest.GetResponse()

at System.ServiceModel.Description.MetadataExchangeClient.MetadataLocationRetriever.DownloadMetadata(TimeoutHelper timeoutHelper)

at System.ServiceModel.Description.MetadataExchangeClient.MetadataRetriever.Retrieve(TimeoutHelper timeoutHelper)

Innere Ausnahmeebene 2:

Quellsystem :

Methode: Lesen

Fehler: Es ist nicht möglich, Daten aus der Transportverbindung zu lesen: Eine vorhandene Verbindung wurde vom entfernten Host gewaltsam geschlossen.

Stack Trace : at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)

at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)"

Zusatzinformation