Dela via

Felsöka säkerhets- och åtkomstkontrollproblem i Azure Data Factory och Synapse Analytics

  • Artikel

GÄLLER FÖR: Azure Data Factory Azure Synapse Analytics

Dricks

Prova Data Factory i Microsoft Fabric, en allt-i-ett-analyslösning för företag. Microsoft Fabric omfattar allt från dataflytt till datavetenskap, realtidsanalys, business intelligence och rapportering. Lär dig hur du startar en ny utvärderingsversion kostnadsfritt!

I den här artikeln beskrivs vanliga felsökningsmetoder för säkerhets- och åtkomstkontroll i Azure Data Factory- och Synapse Analytics-pipelines.

Vanliga fel och meddelanden

Anslutningsproblem i kopieringsaktiviteten för molndataarkivet

Symtom

Olika felmeddelanden kan returneras när anslutningsproblem uppstår i käll- eller mottagardatalagringen.

Orsak

Problemet orsakas vanligtvis av någon av följande faktorer:

  • Proxyinställningen i noden lokalt installerad integreringskörning (IR) om du använder en lokalt installerad IR.

  • Brandväggsinställningen i den lokalt installerade IR-noden, om du använder en lokalt installerad IR.

  • Brandväggsinställningen i molndataarkivet.

Åtgärd

  • Kontrollera följande punkter för att säkerställa att det här är ett anslutningsproblem:

    • Felet genereras från käll- eller mottagaranslutningarna.
    • Felet är i början av kopieringsaktiviteten.
    • Felet är konsekvent för Azure IR eller lokalt installerad IR med en nod, eftersom det kan vara ett slumpmässigt fel i en lokalt installerad IR med flera noder om bara några av noderna har problemet.

  • Om du använder en lokalt installerad IR kontrollerar du proxy-, brandväggs- och nätverksinställningarna, eftersom det kan gå att ansluta till samma datalager om du använder en Azure IR. Information om hur du felsöker det här scenariot finns i:

  • Om du använder en Azure IR kan du försöka inaktivera brandväggsinställningen för datalagringen. Den här metoden kan lösa problemen i följande två situationer:

Om ingen av ovanstående metoder fungerar kontaktar du Microsoft om du behöver hjälp.

Borttagen eller avvisad privat slutpunkt visar fortfarande Aprroved i ADF

Symtom

Du skapade en hanterad privat slutpunkt från ADF och fick en godkänd privat slutpunkt. Men efter att ha raderat eller avvisat den privata slutpunkten senare finns den hanterade privata slutpunkten i ADF fortfarande kvar och visar "Godkänd".

Orsak

För närvarande slutar ADF att hämta status för privat slutpunkt när den har godkänts. Därför är statusen som visas i ADF inaktuell.

Åtgärd

Du bör ta bort den hanterade privata slutpunkten i ADF när befintliga privata slutpunkter avvisas/tas bort från käll-/mottagardatauppsättningar.

Ogiltigt eller tomt autentiseringsnyckelproblem när åtkomst till offentligt nätverk har inaktiverats

Symtom

När du har inaktiverat åtkomsten till det offentliga nätverket för tjänsten utlöser den lokalt installerade integrationskörningen följande fel: The Authentication key is invalid or empty. eller 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.

Orsak

Problemet orsakas troligen av ett DNS-lösningsproblem (Domain Name System), eftersom inaktivering av offentlig anslutning och upprättande av en privat slutpunkt förhindrar återanslutning.

Gör följande för att kontrollera om tjänstens fullständigt kvalificerade domännamn (FQDN) matchas till den offentliga IP-adressen:

  1. Bekräfta att du har skapat den virtuella Azure-datorn (VM) i samma virtuella nätverk som tjänstens privata slutpunkt.

  2. Kör PsPing och Pinga från den virtuella Azure-datorn till tjänstens FQDN:

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

    Kommentar

    Du måste ange en port för PsPing-kommandot. Port 443 visas här men krävs inte.

  3. Kontrollera om båda kommandona matchar en offentlig IP-adress för Azure Data Factory som baseras på en angiven region. IP-adressen ska vara i följande format: xxx.xxx.xxx.0

Åtgärd

Lös problemet genom att göra följande:

  • Som alternativ vill vi föreslå att du lägger till en "virtuell nätverkslänk" manuellt under "Private link DNS Zone" för tjänsten. Mer information finns i artikeln Azure Private Link . Instruktionen är att konfigurera den privata DNS-zonen eller den anpassade DNS-servern för att matcha tjänstens FQDN till en privat IP-adress.

  • Men om du inte vill konfigurera den privata DNS-zonen eller den anpassade DNS-servern kan du prova följande tillfälliga lösning:

    1. Ändra värdfilen i Windows och mappa den privata IP-adressen (tjänstens privata slutpunkt) till tjänstens fullständiga domännamn.

      På den virtuella Azure-datorn går du till C:\Windows\System32\drivers\etcoch öppnar sedan värdfilen i Anteckningar. Lägg till raden som mappar den privata IP-adressen till det fullständiga domännamnet i slutet av filen och spara ändringen.

      Skärmbild av mappning av den privata IP-adressen till värden.

    2. Kör samma kommandon igen som i föregående verifieringssteg för att kontrollera svaret, som ska innehålla den privata IP-adressen.

    3. Registrera om den lokalt installerade integrationskörningen och problemet bör lösas.

Symtom

Du kan inte registrera IR-autentiseringsnyckeln på den lokala virtuella datorn eftersom den privata länken är aktiverad. Du får följande felmeddelande:

"Det gick inte att hämta tjänsttoken från ADF-tjänsten med nyckel *************** och tidskostnaden är: 0,1250079 sekund, felkoden är: InvalidGatewayKey, activityId är: XXXXXXX och det detaljerade felmeddelandet är Klientens IP-adress är inte giltig privat ip Orsak Data factory kunde inte komma åt det offentliga nätverket och därmed inte kunna nå ut till molnet för att göra den lyckade anslutningen."

Orsak

Problemet kan orsakas av den virtuella dator där du försöker installera den lokalt installerade IR:n. Om du vill ansluta till molnet kontrollerar du att åtkomsten till det offentliga nätverket är aktiverad.

Åtgärd

Lösning 1

Lös problemet genom att göra följande:

  1. Gå till sidan Fabriker – Uppdatera .

  2. Välj knappen Prova längst upp till höger.

  3. Under Parametrar fyller du i nödvändig information.

  4. Under Brödtext klistrar du in följande egenskap:

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

  5. Välj Kör för att köra funktionen.

  6. Under Parametrar fyller du i nödvändig information.

  7. Under Brödtext klistrar du in följande egenskap:

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

  8. Välj Kör för att köra funktionen.

  9. Bekräfta att svarskoden: 200 visas. Egenskapen som du klistrade in bör också visas i JSON-definitionen.

  10. Lägg till IR-autentiseringsnyckeln igen i integrationskörningen.

Lösning 2

Lös problemet genom att gå till Azure Private Link.

Försök att aktivera åtkomst till offentligt nätverk i användargränssnittet, enligt följande skärmbild:

Tjänstens privata DNS-zon åsidosätter DNS-matchning i Azure Resource Manager som orsakar felet "Hittades inte"

Orsak

Både Azure Resource Manager och tjänsten använder samma privata zon och skapar en potentiell konflikt på kundens privata DNS med ett scenario där Azure Resource Manager-posterna inte hittas.

Åtgärd

  1. Hitta privata DNS-zoner privatelink.azure.com i Azure-portalen. Skärmbild av att hitta privata DNS-zoner.
  2. Kontrollera om det finns en A-post-adf. Skärmbild av en post.
  3. Gå till Länkar för virtuellt nätverk och ta bort alla poster. Skärmbild av länken för virtuellt nätverk.
  4. Navigera till din tjänst i Azure-portalen och återskapa den privata slutpunkten för portalen. Skärmbild av återskapande av privat slutpunkt.
  5. Gå tillbaka till Privata DNS-zoner och kontrollera om det finns en ny privat DNS-zon privatelink.adf.azure.com. Skärmbild av ny DNS-post.

Anslutningsfel i offentlig slutpunkt

Symtom

När du kopierar data med offentlig åtkomst för Azure Blob Storage-kontot misslyckas pipelinen slumpmässigt med följande fel.

Till exempel: Azure Blob Storage-mottagaren använde Azure IR (offentligt, inte hanterat VNet) och Azure SQL Database-källan använde IR för hanterat VNet. Eller källa/mottagare använder endast hanterad VNet-IR med offentlig lagringsåtkomst.

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

Orsak

Tjänsten kan fortfarande använda IR för hanterat virtuellt nätverk, men du kan stöta på ett sådant fel eftersom den offentliga slutpunkten till Azure Blob Storage i hanterat virtuellt nätverk inte är tillförlitlig baserat på testresultatet, och Azure Blob Storage och Azure Data Lake Gen2 inte stöds för att anslutas via offentlig slutpunkt från tjänstens hanterade virtuella nätverk enligt hanterade virtuella nätverk och hanterade privata slutpunkter.

Åtgärd

  • Att ha en privat slutpunkt aktiverad på källan och även mottagarsidan när du använder IR för hanterat virtuellt nätverk.
  • Om du fortfarande vill använda den offentliga slutpunkten kan du bara växla till offentlig IR i stället för att använda IR för det hanterade virtuella nätverket för källan och mottagaren. Även om du växlar tillbaka till offentlig IR kan tjänsten fortfarande använda IR för hanterade virtuella nätverk om IR för hanterade virtuella nätverk fortfarande finns kvar.

Internt fel vid försök att ta bort en datafabrik eller Synapse-arbetsyta med kundhanterad nyckel (CMK) och användartilldelad hanterad identitet (UA-MI)

Symtom

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

Orsak

Om du utför åtgärder som rör CMK bör du slutföra alla åtgärder som är relaterade till tjänsten först och sedan externa åtgärder (till exempel hanterade identiteter eller Key Vault-åtgärder). Om du till exempel vill ta bort alla resurser måste du först ta bort tjänstinstansen och sedan ta bort nyckelvalvet. Om du tar bort nyckelvalvet först uppstår det här felet eftersom tjänsten inte längre kan läsa de objekt som krävs och inte kan verifiera om borttagning är möjligt eller inte.

Åtgärd

Det finns tre möjliga sätt att lösa problemet. De är följande:

  • Du återkallade tjänstens åtkomst till Nyckelvalvet där CMK-nyckeln lagrades. Du kan omtilldela åtkomst till följande behörigheter: Hämta, Packa upp nyckel och Radbryt nyckel. Dessa behörigheter krävs för att aktivera kundhanterade nycklar. Se Bevilja åtkomst till kundhanterade nycklar. När behörigheten har angetts bör du kunna ta bort tjänsten.

  • Kunden tog bort Key Vault/CMK innan tjänsten togs bort. CMK i tjänsten ska ha "Mjuk borttagning" aktiverat och "Rensa skydda" aktiverat som har en standardkvarhållningsprincip på 90 dagar. Du kan återställa den borttagna nyckeln.
    Granska Återställ borttagen nyckel och borttaget nyckelvärde

  • Användartilldelad hanterad identitet (UA-MI) togs bort före tjänsten. Du kan återställa från detta med hjälp av REST API-anrop, du kan göra detta i en http-klient som du väljer i valfritt programmeringsspråk. Om du inte redan har konfigurerat något för REST API-anrop med Azure-autentisering är det enklaste sättet att göra detta genom att använda POSTMAN/Fiddler. Följ följande steg.

    1. Gör ett GET-anrop med hjälp av metoden GET URL like https://management.azure.com/subscriptions/YourSubscription/resourcegroups/YourResourceGroup/providers/Microsoft.DataFactory/factories/YourFactoryName?api-version=2018-06-01

    2. Du måste skapa en ny användarhanterad identitet med ett annat namn (samma namn kan fungera, men för att vara säker är det säkrare att använda ett annat namn än det i GET-svaret)

    3. Ändra egenskapen encryption.identity och identity.userassignedidentities så att de pekar på den nyligen skapade hanterade identiteten. Ta bort clientId och principalId från userAssignedIdentity-objektet.

    4. Gör ett PUT-anrop till samma URL som skickar den nya brödtexten. Det är mycket viktigt att du skickar det du fick i GET-svaret och bara ändrar identiteten. Annars skulle de åsidosätta andra inställningar oavsiktligt.

    5. När anropet har slutförts kan du se entiteterna igen och försöka ta bort dem igen.

Dela lokalt installerad integrationskörning

Det går inte att dela en lokalt installerad IR från en annan klientorganisation

Symtom

Du kanske märker andra datafabriker (på olika klientorganisationer) när du försöker dela den lokalt installerade IR:en från användargränssnittet, men du kan inte dela den mellan datafabriker som finns i olika klientorganisationer.

Orsak

Lokalt installerad IR kan inte delas mellan klienter.

Relaterat innehåll

Om du vill ha mer hjälp med felsökning kan du prova följande resurser: