Delen via


Problemen met beveiliging en toegangsbeheer van Azure Data Factory en Synapse Analytics oplossen

VAN TOEPASSING OP: Azure Data Factory Azure Synapse Analytics

Tip

Probeer Data Factory uit in Microsoft Fabric, een alles-in-één analyseoplossing voor ondernemingen. Microsoft Fabric omvat alles, van gegevensverplaatsing tot gegevenswetenschap, realtime analyses, business intelligence en rapportage. Meer informatie over het gratis starten van een nieuwe proefversie .

In dit artikel worden algemene probleemoplossingsmethoden voor beveiligings- en toegangsbeheer in Azure Data Factory- en Synapse Analytics-pijplijnen besproken.

Veelvoorkomende fouten en berichten

Connectiviteitsprobleem in de kopieeractiviteit van het cloudgegevensarchief

Symptomen

Er kunnen verschillende foutberichten worden geretourneerd wanneer er verbindingsproblemen optreden in het bron- of sinkgegevensarchief.

Oorzaak

Het probleem wordt meestal veroorzaakt door een van de volgende factoren:

  • De proxyinstelling in het zelf-hostende IR-knooppunt (Integration Runtime) als u een zelf-hostende IR gebruikt.

  • De firewallinstelling in het zelf-hostende IR-knooppunt als u een zelf-hostende IR gebruikt.

  • De firewallinstelling in het cloudgegevensarchief.

Oplossing

  • Controleer de volgende punten om ervoor te zorgen dat dit een verbindingsprobleem is:

    • De fout wordt veroorzaakt door de bron- of sinkconnectors.
    • De fout bevindt zich aan het begin van de kopieeractiviteit.
    • De fout is consistent voor Azure IR of de zelf-hostende IR met één knooppunt, omdat dit een willekeurige fout kan zijn in een zelf-hostende IR met meerdere knooppunten als slechts enkele van de knooppunten het probleem hebben.
  • Als u een zelf-hostende IR gebruikt, controleert u uw proxy, firewall en netwerkinstellingen, omdat het maken van verbinding met hetzelfde gegevensarchief kan slagen als u een Azure IR gebruikt. Als u problemen met dit scenario wilt oplossen, raadpleegt u:

  • Als u een Azure IR gebruikt, probeert u de firewallinstelling van het gegevensarchief uit te schakelen. Deze aanpak kan de problemen in de volgende twee situaties oplossen:

    • IP-adressen van Azure IR staan niet in de acceptatielijst.
    • De functie Vertrouwde Microsoft-services toegang verlenen tot deze functie voor opslagaccounts is uitgeschakeld voor Azure Blob Storage en Azure Data Lake Storage Gen 2.
    • De instelling Toegang tot Azure-services toestaan is niet ingeschakeld voor Azure Data Lake Storage Gen1.

Als geen van de voorgaande methoden werkt, neemt u contact op met Microsoft voor hulp.

Verwijderd of geweigerd privé-eindpunt toont nog steeds Goedgekeurd in ADF

Symptomen

U hebt een beheerd privé-eindpunt gemaakt van ADF en een goedgekeurd privé-eindpunt verkregen. Maar na het verwijderen of afwijzen van het privé-eindpunt blijft het beheerde privé-eindpunt in ADF bestaan en wordt 'Goedgekeurd' weergegeven.

Oorzaak

Op dit moment stopt ADF met het ophalen van de status van het privé-eindpunt nadat deze is goedgekeurd. De status die in ADF wordt weergegeven, is daarom verouderd.

Oplossing

Verwijder het beheerde privé-eindpunt in ADF zodra bestaande privé-eindpunten zijn geweigerd/verwijderd uit bron-/sinkgegevenssets.

Probleem met ongeldige of lege verificatiesleutel nadat openbare netwerktoegang is uitgeschakeld

Symptomen

Nadat u openbare netwerktoegang voor de service hebt uitgeschakeld, genereert de zelf-hostende Integration Runtime de volgende fouten: The Authentication key is invalid or empty.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.

Oorzaak

Het probleem wordt waarschijnlijk veroorzaakt door een DNS-omzettingsprobleem (Domain Name System), omdat het uitschakelen van openbare connectiviteit en het tot stand brengen van een privé-eindpunt voorkomt dat opnieuw verbinding wordt gemaakt.

Ga als volgt te werk om te controleren of de FQDN (Fully Qualified Domain Name) van de service is omgezet in het openbare IP-adres:

  1. Controleer of u de virtuele Azure-machine (VM) hebt gemaakt in hetzelfde virtuele netwerk als het privé-eindpunt van de service.

  2. Voer PsPing en Ping uit vanaf de Virtuele Azure-machine naar de FQDN-service:

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

    Notitie

    U moet een poort opgeven voor de PsPing-opdracht. Poort 443 wordt hier weergegeven, maar is niet vereist.

  3. Controleer of beide opdrachten worden omgezet in een openbaar IP-adres van Azure Data Factory dat is gebaseerd op een opgegeven regio. Het IP-adres moet de volgende indeling hebben: xxx.xxx.xxx.0

Oplossing

Ga als volgt te werk om het probleem op te lossen:

  • Als optie raden we u aan om handmatig een 'Virtual Network-koppeling' toe te voegen onder de 'Private Link DNS-zone' voor de service. Raadpleeg het Artikel over Azure Private Link voor meer informatie. De instructie is voor het configureren van de privé-DNS-zone of aangepaste DNS-server om de service-FQDN om te omzetten in een privé-IP-adres.

  • Als u echter niet de privé-DNS-zone of aangepaste DNS-server wilt configureren, probeert u de volgende tijdelijke oplossing:

    1. Wijzig het hostbestand in Windows en wijs het privé-IP-adres (het privé-eindpunt van de service) toe aan de service-FQDN.

      Ga in de Azure-VM naar C:\Windows\System32\drivers\etcen open het hostbestand in Kladblok. Voeg de regel toe waarmee het privé-IP-adres wordt toegewezen aan de FQDN aan het einde van het bestand en sla de wijziging op.

      Schermopname van het toewijzen van het privé-IP-adres aan de host.

    2. Voer dezelfde opdrachten opnieuw uit als in de voorgaande verificatiestappen om het antwoord te controleren, dat het privé-IP-adres moet bevatten.

    3. Registreer de zelf-hostende Integration Runtime opnieuw en het probleem moet worden opgelost.

Symptomen

U kunt de IR-verificatiesleutel niet registreren op de zelf-hostende VM omdat de privékoppeling is ingeschakeld. Mogelijk wordt het volgende foutbericht weergegeven:

'Kan het servicetoken niet ophalen van de ADF-service met de sleutel *************** en de tijdkosten zijn: 0,1250079 seconde, de foutcode is: InvalidGatewayKey, activityId is: XXXXXXX en gedetailleerd foutbericht is client-IP-adres is geen geldig privé-IP-adres, omdat Data Factory geen toegang heeft tot het openbare netwerk, waardoor de verbinding niet tot de cloud kan worden bereikt.

Oorzaak

Het probleem kan worden veroorzaakt door de VM waarin u de zelf-hostende IR probeert te installeren. Als u verbinding wilt maken met de cloud, moet u ervoor zorgen dat openbare netwerktoegang is ingeschakeld.

Oplossing

Oplossing 1

Ga als volgt te werk om het probleem op te lossen:

  1. Ga naar de pagina Factory's - Bijwerken .

  2. Selecteer rechtsboven de knop Uitproberen .

  3. Vul onder Parameters de vereiste informatie in.

  4. Plak onder Hoofdtekst de volgende eigenschap:

    { "tags": { "publicNetworkAccess":"Enabled" } }
    
  5. Selecteer Uitvoeren om de functie uit te voeren.

  6. Vul onder Parameters de vereiste informatie in.

  7. Plak onder Hoofdtekst de volgende eigenschap:

    { "tags": { "publicNetworkAccess":"Enabled" } }
    
  8. Selecteer Uitvoeren om de functie uit te voeren.

  9. Controleer of antwoordcode 200 wordt weergegeven. De eigenschap die u hebt geplakt, moet ook worden weergegeven in de JSON-definitie.

  10. Voeg de IR-verificatiesleutel opnieuw toe in de integratieruntime.

Oplossing 2

Ga naar Azure Private Link om het probleem op te lossen.

Probeer openbare netwerktoegang in te schakelen op de gebruikersinterface, zoals wordt weergegeven in de volgende schermopname:

Privé-DNS-zone van de service overschrijft DNS-omzetting van Azure Resource Manager die de fout 'Niet gevonden' veroorzaakt

Oorzaak

Zowel Azure Resource Manager als de service maken gebruik van dezelfde privézone die een mogelijk conflict veroorzaakt op de privé-DNS van de klant met een scenario waarin de Azure Resource Manager-records niet worden gevonden.

Oplossing

  1. Zoek Privé-DNS zones privatelink.azure.com in Azure Portal. Schermopname van het zoeken naar Privé-DNS zones.
  2. Controleer of er een A-record adf is. Schermopname van A-record.
  3. Ga naar Koppelingen naar het virtuele netwerk en verwijder alle records. Schermopname van de koppeling naar het virtuele netwerk.
  4. Navigeer naar uw service in Azure Portal en maak het privé-eindpunt voor de portal opnieuw. Schermopname van het opnieuw maken van een privé-eindpunt.
  5. Ga terug naar Privé-DNS zones en controleer of er een nieuwe privé-DNS-zone is privatelink.adf.azure.com. Schermopname van nieuwe DNS-record.

Verbindingsfout in openbaar eindpunt

Symptomen

Bij het kopiëren van gegevens met openbare toegang tot het Azure Blob Storage-account, mislukken pijplijnuitvoeringen willekeurig met de volgende fout.

Bijvoorbeeld: de Azure Blob Storage-sink gebruikte Azure IR (openbaar, niet beheerd virtueel netwerk) en de Azure SQL Database-bron gebruikte de ir van het beheerde virtuele netwerk. Of bron/sink gebruikt beheerde virtuele netwerk-IR alleen met openbare toegang tot opslag.

<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>.

Oorzaak

De service maakt mogelijk nog steeds gebruik van de IR van het beheerde virtuele netwerk, maar u kunt een dergelijke fout tegenkomen omdat het openbare eindpunt naar Azure Blob Storage in het beheerde virtuele netwerk niet betrouwbaar is op basis van het testresultaat, en Azure Blob Storage en Azure Data Lake Gen2 niet worden ondersteund om te worden verbonden via een openbaar eindpunt vanuit het beheerde virtuele netwerk van de service volgens beheerde virtuele netwerken en beheerde privé-eindpunten.

Oplossing

  • Als privé-eindpunt is ingeschakeld voor de bron en ook de sinkzijde bij het gebruik van de IR van het beheerde virtuele netwerk.
  • Als u het openbare eindpunt nog steeds wilt gebruiken, kunt u alleen overschakelen naar openbare IR in plaats van de beheerde virtuele netwerk-IR te gebruiken voor de bron en de sink. Zelfs als u terugschakelt naar een openbare IR, kan de service nog steeds gebruikmaken van de ir van het beheerde virtuele netwerk als de beheerde virtuele netwerk-IR er nog steeds is.

Interne fout bij het verwijderen van een data factory of Synapse-werkruimte met door de klant beheerde sleutel (CMK) en door de gebruiker toegewezen beheerde identiteit (UA-MI)

Symptomen

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

Oorzaak

Als u bewerkingen uitvoert met betrekking tot CMK, moet u eerst alle bewerkingen uitvoeren die betrekking hebben op de service en vervolgens externe bewerkingen (zoals beheerde identiteiten of Key Vault-bewerkingen). Als u bijvoorbeeld alle resources wilt verwijderen, moet u eerst het service-exemplaar verwijderen en vervolgens de sleutelkluis verwijderen. Als u eerst de sleutelkluis verwijdert, treedt deze fout op omdat de service de vereiste objecten niet meer kan lezen en deze niet meer kan valideren of verwijderen mogelijk is.

Oplossing

Er zijn drie mogelijke manieren om het probleem op te lossen. Dit zijn de volgende:

  • U hebt de toegang van de service tot de sleutelkluis ingetrokken waar de CMK-sleutel is opgeslagen. U kunt de toegang opnieuw toewijzen aan de volgende machtigingen: Ophalen, Sleutel uitpakken en Sleutel verpakken. Deze machtigingen zijn vereist om door de klant beheerde sleutels in te schakelen. Raadpleeg Toegang verlenen tot door de klant beheerde sleutels. Zodra de machtiging is opgegeven, moet u de service kunnen verwijderen.

  • De klant heeft Key Vault/CMK verwijderd voordat de service wordt verwijderd. CMK in de service moet 'Voorlopig verwijderen' zijn ingeschakeld en 'Purge Protect' ingeschakeld, waarvoor standaardretentiebeleid van 90 dagen is ingesteld. U kunt de verwijderde sleutel herstellen.
    Herstel verwijderde sleutel en verwijderde sleutelwaarde controleren

  • Door de gebruiker toegewezen beheerde identiteit (UA-MI) is verwijderd vóór de service. U kunt hiervan herstellen met behulp van REST API-aanroepen. U kunt dit doen in een HTTP-client van uw keuze in elke programmeertaal. Als u nog niets hebt ingesteld voor REST API-aanroepen met Azure-verificatie, kunt u dit het eenvoudigst doen met Behulp van Fiddler. Volg de volgende stappen.

    1. Een GET-aanroep maken met behulp van methode: GET-URL zoals https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01

    2. U moet een nieuwe door de gebruiker beheerde identiteit maken met een andere naam (dezelfde naam werkt mogelijk, maar om er zeker van te zijn dat het veiliger is om een andere naam te gebruiken dan de naam in het GET-antwoord)

    3. Wijzig de eigenschap encryption.identity en identity.userassignedidentities zodat deze verwijst naar de zojuist gemaakte beheerde identiteit. Verwijder de clientId en principalId uit het object userAssignedIdentity.

    4. Voer een PUT-aanroep uit naar dezelfde URL die de nieuwe hoofdtekst doorgeeft. Het is belangrijk dat u alles doorgeeft wat u hebt gekregen in het GET-antwoord en alleen de identiteit wijzigt. Anders overschrijven ze onbedoeld andere instellingen.

    5. Nadat de aanroep is geslaagd, kunt u de entiteiten opnieuw zien en opnieuw proberen te verwijderen.

Zelf-hostende Integration Runtime delen

Het delen van een zelf-hostende IR vanuit een andere tenant wordt niet ondersteund

Symptomen

Mogelijk ziet u andere gegevensfactory's (op verschillende tenants) terwijl u de zelf-hostende IR probeert te delen vanuit de gebruikersinterface, maar u kunt deze niet delen tussen gegevensfactory's die zich in verschillende tenants bevinden.

Oorzaak

De zelf-hostende IR kan niet worden gedeeld tussen tenants.

Probeer de volgende bronnen voor meer hulp bij het oplossen van problemen: