Fehlerbehebung bei Sicherheits- und Zugriffskontrollproblemen in Azure Data Factory und Synapse Analytics

GILT FÜR: Azure Data Factory Azure Synapse Analytics

Tipp

Testen Sie Data Factory in Microsoft Fabric, eine All-in-One-Analyselösung für Unternehmen. Microsoft Fabric deckt alle Aufgaben ab, von der Datenverschiebung bis hin zu Data Science, Echtzeitanalysen, Business Intelligence und Berichterstellung. Erfahren Sie, wie Sie kostenlos eine neue Testversion starten!

In diesem Artikel werden gängige Methoden zur Fehlerbehebung für Sicherheit und Zugriffskontrolle in Azure Data Factory- und Synapse Analytics-Pipelines untersucht.

Häufige Fehler und Meldungen

Konnektivitätsprobleme in der Kopieraktivität des Clouddatenspeichers

Symptome

Möglicherweise werden verschiedene Fehlermeldungen zurückgegeben, wenn Konnektivitätsprobleme im Quellen- oder Senkendatenspeicher auftreten.

Ursache

Das Problem wird in der Regel durch einen der folgenden Faktoren verursacht:

• Die Proxyeinstellung im Knoten der selbstgehosteten Integration Runtime (IR), wenn Sie eine selbstgehostete IR verwenden.

• Die Firewalleinstellung im Knoten der selbstgehosteten Integration Runtime (IR), wenn Sie eine selbstgehostete IR verwenden.

• Die Firewalleinstellung im Clouddatenspeicher.

Lösung

• Überprüfen Sie die folgenden Punkte, um sicherzustellen, dass ein Konnektivitätsproblem vorliegt:

  • Der Fehler wird von den Quellen- oder Senkenconnectors ausgelöst.
  • Der Fehler tritt am Anfang der Kopieraktivität auf.
  • Der Fehler ist für Azure IR oder die selbstgehostete IR mit einem Knoten konsistent, da es möglicherweise ein zufälliger Fehler in einer selbstgehosteten IR mit mehreren Knoten ist, wenn das Problem nur bei einigen der Knoten auftritt.

• Wenn Sie eine selbstgehostete IR verwenden, überprüfen Sie Ihre Proxy-, Firewall- und Netzwerkeinstellungen, da eine Verbindung mit dem gleichen Datenspeicher erfolgreich hergestellt werden könnte, wenn Sie eine Azure IR verwenden. Informationen zur Problembehandlung in diesem Szenario finden Sie hier:

  • Ports und Firewalls für die selbstgehostete IR
  • Kopieren von Daten nach und aus Azure Data Lake Storage Gen1 mithilfe von Azure Data Factory

• Wenn Sie eine Azure IR verwenden, versuchen Sie, die Firewalleinstellung des Datenspeichers zu deaktivieren. Diese Vorgehensweise kann die Probleme in den folgenden zwei Situationen beheben:

  • Azure IR-IP-Adressen befinden sich nicht in der Positivliste.
  • Das Feature Vertrauenswürdigen Microsoft-Diensten den Zugriff auf dieses Speicherkonto erlauben ist für Azure Blob Storage und Azure Data Lake Storage Gen 2 deaktiviert.
  • Die Einstellung Zugriff auf Azure-Dienste zulassen ist nicht für Azure Data Lake Storage Gen1 aktiviert.

Wenn keine der vorherigen Methoden funktioniert, wenden Sie sich an Microsoft, um Hilfe zu erhalten.

Ein gelöschter oder abgelehnter privater Endpunkt wird in ADF weiterhin als „Genehmigt“ angezeigt

Problembeschreibung

Sie haben einen verwalteten privaten Endpunkt aus ADF erstellt und einen genehmigten privaten Endpunkt abgerufen. Aber auch nach dem späteren Löschen oder Ablehnen des privaten Endpunkts existiert der verwaltete private Endpunkt in ADF weiterhin und zeigt „Genehmigt“ an.

Ursache

Derzeit beendet ADF das Abrufen des Status des privaten Endpunkts, nachdem er genehmigt wurde. Daher ist der in ADF angezeigte Status veraltet.

Lösung

Sie sollten den verwalteten privaten Endpunkt in ADF löschen, sobald vorhandene private Endpunkte aus Quell-/Senkendatasets abgelehnt/gelöscht werden.

Problem durch ungültigen oder leeren Authentifizierungsschlüssel nach Deaktivierung des Zugriffs über das öffentliche Netzwerk

Symptome

Nachdem Sie den öffentlichen Netzwerkzugriff für den Dienst deaktiviert haben, gibt die selbstgehostete Integration Runtime folgende Fehlermeldung aus: The Authentication key is invalid or empty. oder Cannot connect to the data factory. Please check whether the factory has enabled public network access or the machine is hosted in a approved private endpoint Virtual Network.

Ursache

Das Problem wird wahrscheinlich durch ein Problem bei der Domain Name System-Auflösung (DNS) verursacht, da die Deaktivierung der öffentlichen Konnektivität und das Einrichten eines privaten Endpunkts eine erneute Verbindung verhindert.

Um zu überprüfen, ob der vollständig qualifizierte Domänenname (FQDN) des Dienstes in die öffentliche IP-Adresse aufgelöst wird, gehen Sie wie folgt vor:

1. Vergewissern Sie sich, dass Sie die virtuelle Azure-Maschine (VM) in demselben virtuellen Netzwerk wie der private Endpunkt des Dienstes erstellt haben.

2. Führen Sie PsPing und Ping von der Azure-VM zum FQDN des Dienstes aus:

   psping.exe <dataFactoryName>.<region>.datafactory.azure.net:443 ping <dataFactoryName>.<region>.datafactory.azure.net

   Hinweis

   Sie müssen einen Port für den PsPing-Befehl angeben. Port 443 wird hier angezeigt, ist jedoch nicht erforderlich.

3. Überprüfen Sie, ob beide Befehle in eine öffentliche Azure Data Factory-IP-Adresse aufgelöst werden, die auf einer bestimmten Region basiert. Die IP-Adresse sollte das folgende Format aufweisen: xxx.xxx.xxx.0

Lösung

Gehen Sie zur Lösung des Problems wie folgt vor:

• Als Option möchten wir Ihnen vorschlagen, manuell einen "Virtual Network link" unter der "Private link DNS Zone" für den Dienst hinzuzufügen. Einzelheiten finden Sie im Artikel Azure Private Link. Die Anweisung dient dazu, die private DNS-Zone oder den benutzerdefinierten DNS-Server so zu konfigurieren, dass der FQDN des Dienstes in eine private IP-Adresse aufgelöst wird.

• Wenn Sie die private DNS-Zone oder den benutzerdefinierten DNS-Server jedoch nicht konfigurieren möchten, versuchen Sie es mit der folgenden temporären Lösung:

  1. Ändern Sie die Host-Datei in Windows, und ordnen Sie die private IP (den privaten Endpunkt des Dienstes) dem FQDN des Dienstes zu.

     Wechseln Sie auf dem virtuellen Azure-Computer zu C:\Windows\System32\drivers\etc, und öffnen Sie dann die Datei host im Editor. Fügen Sie die Zeile hinzu, mit der die private IP-Adresse dem FQDN am Ende der Datei zugeordnet wird, und speichern Sie die Änderung.

     

  2. Führen Sie die gleichen Befehle wie in den vorherigen Überprüfungsschritten erneut aus, um die Antwort zu überprüfen, die die private IP-Adresse enthalten sollte.

  3. Registrieren Sie die selbstgehostete Integration Runtime erneut, und das Problem sollte gelöst sein.

IR-Authentifizierungsschlüssel kann aufgrund eines privaten Links nicht auf selbstgehosteten VMs registriert werden

Symptome

Sie können den IR-Authentifizierungsschlüssel nicht auf der selbstgehosteten VM registrieren, da der private Link aktiviert ist. Sie erhalten die folgende Fehlermeldung:

„Fehler beim Abrufen des Diensttokens aus dem ADF-Dienst mit dem Schlüssel *************** und dem Zeitaufwand: 0,1250079 Sekunden, der Fehlercode ist: InvalidGatewayKey, activityId ist: XXXXXXX und die detaillierte Fehlermeldung ist „Die Client-IP-Adresse ist keine gültige private IP-Adresse, weil Data Factory nicht auf das öffentliche Netzwerk zugreifen und deshalb die Cloud nicht erreichen konnte, um die Verbindung herzustellen“.“

Ursache

Das Problem könnte von dem virtuellen Computer verursacht worden sein, in dem Sie die selbstgehostete IR zu installieren versuchen. Um eine Verbindung mit der Cloud herzustellen, stellen Sie sicher, dass öffentlicher Netzwerkzugriff aktiviert ist.

Lösung

Lösung 1

Gehen Sie zur Lösung des Problems wie folgt vor:

1. Wechseln Sie zur Seite Factorys – Update.

2. Wählen Sie oben rechts die Schaltfläche Jetzt testen aus.

3. Geben Sie unter Parameter die erforderlichen Informationen an.

4. Fügen Sie unter Text die folgende Eigenschaft ein:

   { "tags": { "publicNetworkAccess":"Enabled" } }
   

5. Wählen Sie Ausführen aus, um die Funktion auszuführen.

6. Geben Sie unter Parameter die erforderlichen Informationen an.

7. Fügen Sie unter Text die folgende Eigenschaft ein:

   { "tags": { "publicNetworkAccess":"Enabled" } }
   

8. Wählen Sie Ausführen aus, um die Funktion auszuführen.

9. Vergewissern Sie sich, dass Antwortcode: 200 angezeigt wird. Die Eigenschaft, die Sie eingefügt haben, sollte auch in der JSON-Definition angezeigt werden.

10. Fügen Sie den IR-Authentifizierungsschlüssel erneut der Integration Runtime hinzu.

Lösung 2

Um das Problem zu lösen, gehen Sie zu Azure Private Link.

Versuchen Sie, den Zugriff über das öffentliche Netzwerk auf der Benutzeroberfläche zu aktivieren, wie im folgenden Screenshot gezeigt:

Azure Data Factory

Synapse Analytics

Die private DNS-Zone eines Diensts überschreibt die Azure Resource Manager DNS-Auflösung und verursacht den Fehler "Nicht gefunden"

Ursache

Sowohl Azure Resource Manager als auch der Dienst verwenden dieselbe private Zone, wodurch ein potenzieller Konflikt im privaten DNS des Kunden entsteht, wenn in einem Szenario die Azure Resource Manager-Datensätze nicht gefunden werden.

Lösung

1. Suchen Sie im Azure-Portal unter privatelink.azure.com nach privaten DNS-Zonen.
2. Überprüfen Sie, ob ein A-Datensatz mit dem Namen adf vorhanden ist.
3. Navigieren Sie zu VNET-Verknüpfungen, und löschen Sie alle Einträge.
4. Navigieren Sie zu Ihrem Dienst im Azure-Portal und erstellen Sie den privaten Endpunkt für das Portal neu.
5. Kehren Sie zu den privaten DNS-Zonen zurück, und überprüfen Sie, ob eine neue private DNS-Zone privatelink.adf.azure.com vorhanden ist.

Verbindungsfehler beim öffentlichen Endpunkt

Symptome

Beim Kopieren von Daten mit dem öffentlichen Azure Blob Storage-Kontozugriff, schlagen Pipelineausführungen zufällig mit dem folgenden Fehler fehl.

Beispiel: Die Azure Blob Storage-Senke verwendete Azure Integration Runtime (öffentliches, nicht verwaltetes virtuelles Netzwerk), während die Quelle der Azure SQL-Datenbank die Integration Runtime des verwalteten virtuellen Netzwerks verwendete. Oder die Quelle/Senke verwendet die Integration Runtime für das verwaltete virtuelle Netzwerk nur mit öffentlichem Speicherzugriff.

<LogProperties><Text>Invoke callback url with req: "ErrorCode=AzureBlobFailedToCreateContainer,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Unable to create Azure Blob container. Endpoint: XXXXXXX/, Container Name: test.,Source=Microsoft.DataTransfer.ClientLibrary,''Type=Microsoft.WindowsAzure.Storage.StorageException,Message=Unable to connect to the remote server,Source=Microsoft.WindowsAzure.Storage,''Type=System.Net.WebException,Message=Unable to connect to the remote server,Source=System,''Type=System.Net.Sockets.SocketException,Message=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond public ip:443,Source=System,'","Details":null}}</Text></LogProperties>.

Ursache

Der Dienst kann immer noch die Integration Runtime des verwalteten virtuellen Netzwerks verwenden, aber Sie könnten auf diesen Fehler stoßen, weil der öffentliche Endpunkt zu Azure Blob Storage im verwalteten virtuellen Netzwerk basierend auf dem Testergebnis nicht zuverlässig ist und Azure Blob Storage und Azure Data Lake Gen2 nicht unterstützt werden, um über den öffentlichen Endpunkt des verwalteten Virtual Network des Dienstes gemäß Verwaltetes virtuelles Netzwerk und verwaltete private Endpunkte verbunden zu werden.

Lösung

• Aktivieren Sie einen privaten Endpunkt auf der Seite der Quelle und der Senke, wenn Sie die Integration Runtime für das verwaltete virtuelle Netzwerk verwenden.
• Wenn Sie dennoch den öffentlichen Endpunkt verwenden möchten, können Sie stattdessen nur die Integration Runtime für das verwaltete virtuelle Netzwerk für die Quelle und die Senke verwenden. Auch wenn Sie zurück zur öffentlichen Integration Runtime wechseln, verwendet der Dienst möglicherweise weiterhin die Integration Runtime des verwalteten virtuellen Netzwerks, wenn die Integration Runtime des verwalteten virtuellen Netzwerks noch vorhanden ist.

Interner Fehler beim Versuch, eine Datenfabrik oder einen Synapse-Arbeitsbereich mit Customer Managed Key (CMK) und User Assigned Managed Identity (UA-MI) zu löschen

Symptome

{\"error\":{\"code\":\"InternalError\",\"message\":\"Internal error has occurred.\"}}

Ursache

Wenn Sie Vorgänge im Zusammenhang mit CMK durchführen, sollten Sie zuerst alle Vorgänge im Zusammenhang mit dem Dienst abschließen, und dann externe Vorgänge (z. B. Vorgänge für verwaltete Identitäten oder den Key Vault). Wenn Sie z. B. alle Ressourcen löschen möchten, müssen Sie zuerst die Serviceinstanz und dann den Schlüsseltresor löschen. Wenn Sie den Schlüsseltresor zuerst löschen, tritt dieser Fehler auf, da der Dienst die erforderlichen Objekte nicht mehr lesen kann und nicht in der Lage sein wird, zu überprüfen, ob eine Löschung möglich ist oder nicht.

Lösung

Dieses Problem kann auf drei Arten behandelt werden. Dies sind:

• Sie haben dem Dienst den Zugriff auf den Schlüsseltresor entzogen, in dem der CMK-Schlüssel gespeichert war. Sie können den Zugriff auf die folgenden Berechtigungen neu zuweisen: Holen, Schlüssel entpacken und Schlüssel umpacken. Diese Berechtigungen sind erforderlich, um vom Kunden verwaltete Schlüssel zu aktivieren. Siehe Zugang gewähren zu kundenseitig verwalteten Schlüsseln. Sobald die Genehmigung erteilt ist, sollten Sie den Dienst löschen können.

• Der Kunde hat Key Vault / CMK vor der Löschung des Dienstes gelöscht. CMK im Dienst sollte "Soft Delete" und "Purge Protect" aktiviert haben, die eine Standardaufbewahrungsrichtlinie von 90 Tagen haben. Sie können den gelöschten Schlüssel wiederherstellen.
  Überprüfen Sie die Informationen zu Wiederherstellen von gelöschten Schlüsseln und Gelöschter Schlüsselwert

• User Assigned Managed Identity (UA-MI) wurde vor dem Dienst gelöscht. Sie können dies mithilfe von REST-API-Aufrufen wiederherstellen. Sie können dies in einem HTTP-Client Ihrer Wahl in jeder Programmiersprache tun. Wenn Sie die REST-API-Aufrufe mit Azure-Authentifizierung noch nicht eingerichtet haben, ist die einfachste Möglichkeit dafür die Verwendung von Fiddler. Führen Sie die folgenden Schritte aus.

  1. Führen Sie einen GET-Aufruf mit Method: GET Url wie https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01

  2. Sie müssen eine neue benutzerseitig verwaltete Identität mit einem anderen Namen erstellen (der gleiche Name funktioniert möglicherweise, aber es ist sicherer, einen anderen Namen als denjenigen in der GET-Antwort zu verwenden)

  3. Ändern Sie die Encryption.identity-Eigenschaft und identity.userassignedidentities so, dass sie auf die neu erstellte verwaltete Identität verweisen. Entfernen Sie die „clientId“ und „principalId“ aus dem userAssignedIdentity-Objekt.

  4. Führen Sie einen PUT-Aufruf an dieselbe URL durch und übergeben Sie den neuen Body. Es ist wichtig, dass Sie alles übergeben, was Sie in der GET-Antwort erhalten haben und nur die Identität ändern. Andernfalls würden sie andere Einstellungen versehentlich außer Kraft setzen.

  5. Nachdem der Aufruf erfolgreich war, werden Sie die Entitäten erneut sehen und das Löschen erneut versuchen können.

Freigeben der selbstgehosteten Integration Runtime

Die Freigabe der selbstgehosteten Integration Runtime von einem anderen Mandanten wird nicht unterstützt

Problembeschreibung

Möglicherweise bemerken Sie andere Datenfabriken (auf verschiedenen Tenants), wenn Sie versuchen, die selbstgehostete IR von der Benutzeroberfläche aus freizugeben, aber Sie können sie nicht für Datenfabriken freigeben, die sich auf verschiedenen Tenants befinden.

Ursache

Die selbstgehostete Integration Runtime kann nicht mandantenübergreifend freigegeben werden.

Zugehöriger Inhalt

Weitere Hilfe zur Problembehandlung finden Sie in den folgenden Ressourcen:

• Private Link für Data Factory
• Data Factory-Blog
• Data Factory-Funktionsanfragen
• Azure-Videos
• Q&A-Seite von Microsoft
• Stack Overflow-Forum für Data Factory
• Informationen zu Data Factory auf X