Ripristino dell'area di lavoro di Synapse Analytics dopo il trasferimento di una sottoscrizione in una directory di Microsoft Entra diversa (tenant)

Questo articolo descrive come ripristinare l'area di lavoro di Synapse Analytics dopo il trasferimento della sottoscrizione a un'altra directory di Microsoft Entra. L'area di lavoro di Synapse Analytics non sarà accessibile dopo il trasferimento di una sottoscrizione a un'altra directory di Microsoft Entra (tenant).

Quando si tenta di avviare Synapse Studio dopo lo spostamento, verrà visualizzato l'errore: "Failed to load one or more resources due to no access, error code 403" (Impossibile caricare una o più risorse a causa di nessun accesso, codice di errore 403).

Screenshot of Synapse Studio Error 403 after tenant migration.

Seguire la procedura descritta in questo articolo dopo il trasferimento di una sottoscrizione nel tenant per ripristinare l'area di lavoro Synapse Analytics.

Il trasferimento di una sottoscrizione a un'altra directory (tenant) di Microsoft Entra è un processo complesso che deve essere pianificato ed eseguito con attenzione. Azure Synapse Analytics richiede che le entità di sicurezza (identità) funzionino normalmente. Quando una sottoscrizione viene spostata in un tenant diverso, tutti gli ID entità cambiano, le assegnazioni di ruolo vengono eliminate dalla risorsa di Azure e le identità gestite assegnate dal sistema vengono eliminate.

Per comprendere l'impatto del trasferimento di una sottoscrizione a un altro tenant, vedere Trasferire una sottoscrizione di Azure a un'altra directory di Microsoft Entra

Questo articolo illustra i passaggi necessari per il ripristino di un'area di lavoro Synapse Analytics dopo lo spostamento della sottoscrizione tra tenant.

Prerequisiti

  • Per altre informazioni sul servizio o sulle risorse interessate dallo spostamento del tenant, vedere Trasferire una sottoscrizione di Azure a un'altra directory di Microsoft Entra.
  • Salvare tutte le assegnazioni di ruolo per utenti, gruppi e identità gestite di Microsoft Entra. Queste informazioni possono essere usate per assegnare le autorizzazioni necessarie per le risorse di Azure, ad esempio Azure Synapse Analytics e ADLS Gen2 dopo lo spostamento del tenant. Vedere Passaggio 1: Preparare il trasferimento
  • Salvare tutte le autorizzazioni necessarie per gli utenti di Microsoft Entra nel pool SQL dedicato e serverless. Gli utenti di Microsoft Entra verranno eliminati dai pool SQL dedicati e serverless dopo lo spostamento del tenant.

Passaggi per il ripristino dell'area di lavoro Synapse Analytics

Dopo aver trasferito la sottoscrizione a un altro tenant, seguire questa procedura per ripristinare l'area di lavoro di Azure Synapse Analytics.

  1. Disabilitare e riabilitare l'identità gestita assegnata al sistema. Per altre informazioni, leggere questo articolo.
  2. Assegnare le autorizzazioni di controllo degli accessi (RBAC) agli utenti, ai gruppi e alle identità gestite richieste per Microsoft Entra, nell'area di lavoro Synapse Analytics e alle risorse di Azure necessarie.
  3. Impostare l'amministratore SQL Active Directory.
  4. Ricreare utenti e gruppi di Microsoft Entra in base agli utenti e ai gruppi equivalenti nel nuovo tenant di Microsoft Entra per i pool SQL dedicati e serverless.
  5. Assegnare il controllo degli accessi in base al ruolo di Azure agli utenti di Microsoft Entra, i gruppi all'area di lavoro Synapse Analytics. Questo passaggio deve essere il primo passaggio dopo il ripristino dell'area di lavoro. Senza questo passaggio, l'avvio di Synapse Studio genererà 403 messaggi, perché gli utenti di Microsoft Entra non hanno le autorizzazioni per l'area di lavoro:
    {"error":{"code":"Unauthorized","message":"The principal '<subscriptionid>' does not    have the required Synapse RBAC permission to perform this action. Required permission:    Action: Microsoft.Synapse/workspaces/read, Scope: workspaces/tenantmove-ws-1/*."}}
    
  6. Assegnare ruoli controllo degli accessi in base al ruolo di Microsoft Entra a utenti, gruppi e entità servizio a tutte le risorse usate negli artefatti dell'area di lavoro, ad esempio ADLS Gen2. Per maggiori informazioni sul Controllo degli accessi in base al ruolo di Azure in ADLS Gen2, consultare Controllo degli accessi in base al ruolo di Azure (RBAC).
  7. Aggiungere assegnazioni di ruolo controllo degli accessi in base al ruolo di Synapse a utenti e gruppi di Microsoft Entra. Per maggiori informazioni, vedere Come gestire le assegnazioni di ruolo di controllo degli accessi in base al ruolo di Synapse in Synapse Studio
  8. Ricreare tutti gli account di accesso e gli utenti di Microsoft Entra nel pool SQL dedicato e serverless. Per altre informazioni, vedere Autenticazione SQL in Azure Synapse Analytics
  9. Ricreare tutte le identità gestite assegnate dall'utente e assegnare l'identità gestita assegnata dall'utente all'area di lavoro Synapse Analytics. Per altre informazioni, vedere Credenziali in Azure Data Factory e Azure Synapse

Nota

Verificare che i passaggi seguenti vengano eseguiti solo dopo aver verificato che la sottoscrizione sia stata spostata correttamente in un altro tenant.

Disabilitare e riabilitare l'identità gestita assegnata dal sistema per l'area di lavoro Synapse Analytics

Questa sezione illustra come usare l'interfaccia della riga di comando di Azure o Azure PowerShell per disabilitare e riabilitare l'identità gestita assegnata dal sistema per l'area di lavoro di Azure Synapse Analytics. Considerare i passaggi seguenti nell'interfaccia della riga di comando di Azure o in Azure PowerShell.

$resourceGroupName="Provide the Resource group name"
$workspaceName="Provide the workspace name"
$subscriptionId="Provide the subscription Id"

$url = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Synapse/workspaces/$workspaceName\?api-version=2021-06-01"

Questo esempio successivo disabilita l'identità gestita assegnata dal sistema per l'area di lavoro.

az rest --method patch --headers  Content-Type=application/json   `
--url  $url `
--body '{ \"identity\":{\"type\":\"None\"}}'

L'area di lavoro provisioningState deve essere Succeeded e il tipo di identità deve essere none dopo l'esecuzione del comando precedente. Se si esegue il comando seguente, il valore provisioningState potrebbe essere visualizzato come Provisioning e richiederà alcuni minuti per modificare lo stato su Succeeded. Il valore di provisioningState deve essere Succeeded prima di riabilitare l'identità gestita assegnata dal sistema per l'area di lavoro.

Per ottenere lo stato dell'area di lavoro e quindi lo stato del provisioning e il tipo di identità, usare il frammento di codice seguente:

az rest --method GET --uri $uri

Il codice JSON risultante dovrebbe essere simile al seguente:

   {
  "id": "/subscriptions/<subscriptionid>/resourceGroups/TenantMove-RG/providers/Microsoft Synapse/workspaces/tenantmove-ws",
  "identity": {
    "type": "None"
  },
  "location": "eastus",
  "name": "tenantmove-ws",
  "properties": {
    "connectivityEndpoints": {
      "dev": "https://tenantmove-ws.dev.azuresynapse.net",
      "sql": "tenantmove-ws.sql.azuresynapse.net",
      "sqlOnDemand": "tenantmove-ws-ondemand.sql.azuresynapse.net",
      "web": "https://web.azuresynapse.net?workspace=%2fsubscriptions%2<subscriptionid>b%2fresourceGroups%2fTenantMove-RG%2fproviders%2fMicrosoft.Synapse%2fworkspaces%2ftenantmove-ws"
    },
    "cspWorkspaceAdminProperties": {
      "initialWorkspaceAdminObjectId": "<object id>"
    },
    "defaultDataLakeStorage": {
      "accountUrl": "https://tenantmovedemowsstorage.dfs.core.windows.net",
      "filesystem": "demo",
      "resourceId": "/subscriptions/<subscriptionid>/resourceGroups/TenantMove-RG/providers/Microsoft.Storage/storageAccounts/tenantmovedemowsstorage"
    },
    "encryption": {
      "doubleEncryptionEnabled": false
    },
    "extraProperties": {
      "WorkspaceType": "Normal"
    },
    "managedResourceGroupName": "tenantmove-ws-managed-rg",
    "privateEndpointConnections": [],
    "provisioningState": "Succeeded",
    "publicNetworkAccess": "Enabled",
    "sqlAdministratorLogin": "sqladminuser",
    "trustedServiceBypassEnabled": false,
    "workspaceUID": "<workspace UID>"
  },
  "resourceGroup": "TenantMove-RG",
  "tags": {},
  "type": "Microsoft.Synapse/workspaces"
}

Il comando successivo riabiliterà l'identità gestita assegnata dal sistema per l'area di lavoro:

az rest --method patch --headers  Content-Type=application/json   `
--url  $url `
--body '{ \"identity\":{\"type\":\"SystemAssigned\"}}'

Il comando successivo otterrà lo stato dell'area di lavoro. Il valore provisioningState deve essere Succeeded. Il valore provisioningState passerà da Provisioning a Succeeded. Il tipo di identità verrà modificato in SystemAssigned.

az rest --method GET --uri $uri

Passaggi successivi