Gli utenti dell'organizzazione possono accedere ai dati locali (per i quali hanno già l'autorizzazione di accesso), ma prima che possano connettersi all'origine dati locale, è necessario installare e configurare un gateway di dati locale. Il gateway facilita consente una comunicazione "dietro le quinte" rapida e sicura tra un utente nel cloud e l'origine dati locale e viceversa.

L'installazione e la configurazione di un gateway viene in genere eseguita da un amministratore. Può richiedere conoscenze specializzate dei server locali e in alcuni casi le autorizzazioni di amministratore del server.

Questo articolo non contiene istruzioni dettagliate su come installare e configurare il gateway. A tale scopo, consultare l'articolo Gateway dati locale. Questo articolo mira a fornire una conoscenza approfondita del funzionamento del gateway. Verranno anche fornite alcune informazioni dettagliate sui nomi utente e la sicurezza sia in Azure Active Directory sia in Analysis Services, nonché sul modo in cui il servizio cloud usa l'indirizzo di posta elettronica con cui un utente esegue l'accesso, il gateway e Active Directory per connettersi in modo sicuro ai dati locali ed eseguire query su di essi.

Come funziona il gateway

on-prem-data-gateway-how-it-works

Questa sezione descrive cosa accade quando un utente interagisce con un elemento connesso a un'origine dati locale.

Nota:

Per Power BI è necessario configurare un'origine dati per il gateway.

  1. Verrà creata una query dal servizio cloud, insieme alle credenziali crittografate per l'origine dati locale, che verrà quindi inviata alla coda di elaborazione nel gateway.

  2. Il servizio cloud gateway analizzerà la query e invierà la richiesta al bus di servizio di Azure.

  3. Il gateway dati locale esegue il polling delle richieste in sospeso sul bus di servizio di Azure.

  4. Il gateway riceve la query, decrittografa le credenziali e si connette all'origine o alle origini dati con tali credenziali.

  5. Il gateway invia la query all'origine dati per l'esecuzione.

  6. I risultati vengono inviati dall'origine dati al gateway, quindi al servizio cloud. Il servizio usa quindi i risultati.

Elenco di tipi di origini dati disponibili

Origine dati Dinamico/DirectQuery Aggiornamento pianificato o manuale configurato dall'utente
Analysis Services in modalità tabulare
Analysis Services in modalità multidimensionale
SQL Server
SAP HANA
Oracle
Teradata
File No
Cartella No
Elenco di SharePoint (locale) No
Web No
OData No
IBM DB2 No
MySQL No
Sybase No
SAP BW No
Database Informix IBM No
ODBC No

Account di accesso

Gli utenti eseguiranno l'accesso con un account aziendale o dell'istituto di istruzione. Questo è l'account aziendale. Se è stata effettuata l'iscrizione per un'offerta di Office 365 senza specificare l'indirizzo di posta elettronica dell'ufficio, questo può apparire come nancy@contoso.onmicrosoft.com. All'interno di un servizio cloud, l'account viene archiviato in un tenant di Azure Active Directory (AAD). Nella maggior parte dei casi, l'UPN dell'account AAD corrisponderà all'indirizzo di posta elettronica.

Autenticazione a origini dati locali

Una credenziale archiviata verrà usata per connettersi a origini dati locali dal gateway ad eccezione di Analysis Services. Indipendentemente dal singolo utente, il gateway usa credenziali archiviate per connettersi.

Autenticazione a un'origine dati Analysis Services live

Ogni volta che un utente interagisce con Analysis Services, il nome utente effettivo viene passato al gateway e quindi al server di Analysis Services locale. Il nome dell'entità utente (UPN), che in genere corrisponde all'indirizzo di posta elettronica con cui si accede al cloud, è l'informazione che viene passata ad Analysis Services come utente effettivo. L'UPN viene passato nella proprietà di connessione EffectiveUserName. Questo indirizzo di posta elettronica deve corrispondere a un UPN definito all'interno del dominio di Active Directory locale. L'UPN è una proprietà di un account di Active Directory. Questo account di Windows deve quindi essere presente in un ruolo di Analysis Services per avere accesso al server. Se non viene trovata alcuna corrispondenza in Active Directory, l'accesso non riesce.

Analysis Services può anche fornire filtri basati su questo account. I filtri possono usare la sicurezza basata sui ruoli o la sicurezza a livello di riga.

Sicurezza basata sui ruoli

I modelli assicurano la sicurezza basata sui ruoli utente. I ruoli vengono definiti per un particolare progetto di modello durante la creazione in SQL Server Data Tools – Business Intelligence (SSDT-BI) oppure dopo la distribuzione di un modello, usando SQL Server Management Studio (SSMS). I ruoli contengono membri in base al nome utente o gruppo di Windows. I ruoli definiscono le autorizzazioni di un utente per eseguire una query o azioni sul modello. La maggior parte degli utenti appartiene a un ruolo con autorizzazioni di lettura. Altri ruoli sono destinati agli amministratori con autorizzazioni di elaborazione degli elementi, gestione delle funzioni di database e di altri ruoli.

Sicurezza a livello di riga

La sicurezza a livello di riga è specifica per la sicurezza a livello di Analysis Services. I modelli possono fornire sicurezza dinamica a livello di riga. Invece di avere almeno un ruolo a cui appartengono gli utenti, la sicurezza dinamica non è richiesta per alcun modello tabulare. A un livello elevato, la sicurezza dinamica definisce l'accesso in lettura di un utente ai dati fino a una specifica riga di una determinata tabella. Analogamente ai ruoli, la sicurezza dinamica a livello di riga si basa su un nome utente Windows.

La possibilità di un utente di eseguire query e visualizzare i dati del modello è prima di tutto determinata dai ruoli di cui è membro il rispettivo account utente di Windows e, in secondo luogo, dalla sicurezza dinamica a livello di riga, se configurata.

L'implementazione della sicurezza basata sui ruoli e della sicurezza dinamica a livello di riga nei modelli esula dall'ambito di questo articolo. Per altre informazioni, vedere Ruoli (SSAS tabulare) e Ruoli di sicurezza (Analysis Services - Dati multidimensionali) in MSDN. Inoltre, per una conoscenza più approfondita della sicurezza del modello tabulare, scaricare e leggere il white paper Protezione del modello semantico BI tabulare.

Ruolo di Azure Active Directory

I servizi cloud Microsoft usano Azure Active Directory per eseguire l'autenticazione degli utenti. Azure Active Directory è il tenant che contiene i nomi utente e i gruppi di sicurezza. In genere, un utente accede con lo stesso indirizzo di posta elettronica dell'UPN dell'account.

Qual è il ruolo di Active Directory locale?

Affinché il server di Analysis Services possa determinare se un utente a esso connesso appartiene a un ruolo con autorizzazioni di lettura dei dati, deve convertire il nome utente effettivo passato da AAD al gateway e quindi al server di Analysis Services. Il server di Analysis Services passa il nome utente effettivo a un controller di dominio di Windows Active Directory. Il controller di dominio di Active Directory verifica quindi che il nome utente effettivo sia un UPN valido, su un account locale, e restituisce un nome utente di Windows al server Analysis Services.

EffectiveUserName non può essere usato in un server di Analysis Services non appartenente al dominio. Per evitare errori di accesso, il server di Analysis Services locale deve appartenere a un dominio.

Come si identifica l'UPN?

È possibile che l'utente non conosca l'UPN e non sia un amministratore di dominio. È possibile usare il comando seguente dalla workstation per identificare l'UPN dell'account.

whoami /upn

Il risultato sarà simile a un indirizzo di posta elettronica, ma si tratta dell'UPN dell'account di dominio locale. Se si usa un'origine dati di Analysis Services per connessioni dinamiche, questa deve corrispondere a ciò che è stato passato a EffectiveUserName dal gateway.

Mapping di nomi utente per le origini dati di Analysis Services

Power BI consente di eseguire il mapping di nomi utente per le origini dati di Analysis Services. È possibile configurare regole per eseguire il mapping di un nome utente che ha eseguito l'accesso a Power BI a un nome che viene passato per EffectiveUserName usando la connessione di Analysis Services. La funzionalità di mapping dei nomi utente rappresenta un'ottima soluzione alternativa quando il nome utente in AAD non corrisponde a un UPN in Active Directory locale. Ad esempio, se l'indirizzo di posta elettronica è nancy@contoso.onmicrsoft.com, è possibile eseguirne il mapping a nancy@contoso.com e tale valore viene passato al gateway. Sono disponibili altre informazioni su come eseguire il mapping dei nomi utente.

Sincronizzare un server di Active Directory locale con Azure Active Directory

È opportuno che gli account Active Directory locali corrispondano ad Azure Active Directory se si intende usare connessioni Analysis Services dinamiche, analogamente al modo in cui l'UPN deve corrispondere tra gli account.

I servizi cloud rilevano solo gli account in Azure Active Directory. Anche se è stato aggiunto un account in Active Directory locale, se non esiste in AAD, non può essere usato. Esistono diversi modi in cui è possibile associare gli account Active Directory locali con Azure Active Directory.

  1. È possibile aggiungere manualmente account in Azure Active Directory.

    È possibile creare un account nel portale di Azure o nel portale di amministrazione di Office 365 e il nome dell'account corrisponde l'UPN dell'account Active Directory locale.

  2. È possibile usare lo strumento Azure AD Connect per sincronizzare gli account locali al tenant di Azure Active Directory.

    Lo strumento Azure AD Connect offre opzioni per la sincronizzazione della directory e della password. Se non si è un amministratore tenant o un amministratore di dominio locale, è necessario contattare l'amministratore IT per ottenere questa configurazione.

  3. È possibile configurare Active Directory Federation Services (ADFS).

    È possibile associare il server ADFS al tenant AAD con lo strumento Azure AD Connect. ADFS usa la sincronizzazione della directory descritta in precedenza, ma consente il Single Sign-On (SSO). Ad esempio, se si è all'interno della rete aziendale, durante l'uso di un servizio cloud e passare all'accesso, potrebbe non essere richiesto di immettere un nome utente o password. È necessario rivolgersi all'amministratore IT per sapere se questa opzione è disponibile per l'organizzazione.

L'uso di Azure AD Connect garantisce la corrispondenza tra l'UPN e AAD e Active Directory locale.

Nota:

La sincronizzazione degli account con lo strumento Azure AD Connect creerà nuovi account nel tenant di AAD.

A questo punto, è possibile usare il gateway

Il gateway funge da ponte tra il cloud e il server locale. Il trasferimento dei dati tra il cloud e il gateway viene protetto con il bus di servizio di Azure. Il bus di servizio crea un canale sicuro tra il cloud e il server locale attraverso una connessione in uscita sul gateway. Non sono presenti connessioni in ingresso che è necessario aprire nel firewall locale.

Se si dispone di un'origine dati di Analysis Services, è necessario installare il gateway in un computer appartenente allo stesso insieme di strutture o dominio del server Analysis Services.

Quanto più il gateway è vicino al server, tanto più veloce sarà la connessione. È preferibile che il gateway si trovi nello stesso server dell’origine dati, per evitare la latenza di rete tra il gateway e il server.

Azioni successive

Dopo averlo installato, è consigliabile creare origini dati per il gateway. È possibile aggiungere origini dati all'interno della schermata Gestisci gateway. Per altre informazioni vedere gli articoli sulla gestione delle origini dati.

Gestire l'origine dati - Analysis Services
Gestire l'origine dati - SAP HANA
Gestire l'origine dati - SQL Server
Gestire l'origine dati - Oracle
Gestire l'origine dati - Importazione/aggiornamento pianificato

Possibili esiti negativi

In alcuni casi l'installazione del gateway non riesce. In altri casi, il gateway sembra essere installato correttamente, ma il servizio non riesce comunque a usarlo. In molti casi, si tratta di un problema semplice, ad esempio la password per le credenziali che il gateway usa per accedere all'origine dati.

In altri casi, potrebbero esserci problemi con il tipo di indirizzo di posta elettronica con cui gli utenti eseguono l'accesso oppure con l'impossibilità di risolvere un nome utente effettivo in Analysis Services. Se si hanno più domini con trust reciproci e il gateway si trova in uno di essi e Analysis Services nell'altro, in alcuni casi potrebbero verificarsi dei problemi.

Invece di analizzare la risoluzione dei problemi del gateway in questo articolo, è stata inclusa una serie di passaggi di risoluzione dei problemi in un altro articolo, Risoluzione dei problemi del gateway dati locale. Probabilmente non si verificherà alcun problema, ma in tal caso, la conoscenza del funzionamento generale e l'articolo sulla risoluzione dei problemi dovrebbero essere d'aiuto.

Account di accesso

Gli utenti eseguiranno l'accesso con un account aziendale o dell'istituto di istruzione. Questo è l'account aziendale. Se è stata effettuata l'iscrizione per un'offerta di Office 365 senza specificare l'indirizzo di posta elettronica dell'ufficio, questo può apparire come nancy@contoso.onmicrosoft.com. All'interno di un servizio cloud, l'account viene archiviato in un tenant di Azure Active Directory (AAD). Nella maggior parte dei casi, l'UPN dell'account AAD corrisponderà all'indirizzo di posta elettronica.

Account del Servizio di Windows

Il gateway dati locale è configurato in modo da usare NT SERVICE\PBIEgwService per il servizio Windows di Registro credenziali. Per impostazione predefinita, ha il diritto Accedi come servizio a seconda del contesto del computer su cui si sta installando il gateway.

Nota:

Se è stata selezionata la modalità personale, configurare separatamente l'account del servizio di Windows.

Questo non è l'account usato per connettersi alle origini dati locali. Non si tratta neanche dell'account aziendale o dell'istituto di istruzione con cui si accede ai servizi cloud.

Se si verificano problemi di autenticazione con il server proxy, è possibile modificare l'account del servizio Windows in un account utente di dominio o in un account del servizio gestito. Per informazioni su come modificare l'account, vedere la configurazione proxy.

Porte

Il gateway crea una connessione in uscita al Bus di servizio di Azure. Esso comunica su porte in uscita: TCP 443 (predefinita), 5671, 5672, 9350 a 9354. Il gateway non richiede porte in entrata. Altre informazioni

È consigliabile aggiungere all'elenco elementi consentiti nel firewall gli indirizzi IP per l'area dati. È possibile scaricare l'elenco di IP del data center di Microsoft Azure. Questo elenco viene aggiornato ogni settimana. Il gateway comunicherà con un Bus di servizio di Azure usando l'indirizzo IP insieme al nome di dominio completo (FQDN). Se si impone al gateway di comunicare tramite HTTPS, verrà usato esclusivamente il nome di dominio completo e non avrà luogo alcuna comunicazione usando gli indirizzi IP.

Nota:

Gli indirizzi IP elencati nell'elenco di IP del data center di Azure sono in notazione CIDR. Ad esempio, 10.0.0.0/24 non significa da 10.0.0.0 a 10.0.0.24. Altre informazioni sulla notazione CIDR.

Di seguito è riportato un elenco dei nomi di dominio completi usati dal gateway.

Nomi di dominio Porte in uscita Descrizione
*.download.microsoft.com 80 Protocollo HTTP usato per scaricare il programma di installazione.
*.powerbi.com 443 HTTPS
*.analysis.windows.net 443 HTTPS
*.login.windows.net 443 HTTPS
*.servicebus.windows.net 5671-5672 Advanced Message Queuing Protocol (AMQP)
*.servicebus.windows.net 443, 9350-9354 Listener in Inoltro del bus di servizio su TCP (è richiesta la porta 443 per l'acquisizione del token di Controllo di accesso)
*.frontend.clouddatahub.net 443 HTTPS
*.core.windows.net 443 HTTPS
login.microsoftonline.com 443 HTTPS
*.msftncsi.com 443 Usato per testare la connettività a internet se il gateway non è raggiungibile dal servizio Power BI.
*.microsoftonline-p.com 443 Usato per l'autenticazione a seconda della configurazione.
Nota:

Il traffico destinato a visualstudio.com o a visualstudioonline.com riguarda le informazioni dettagliate sull'app e non è richiesto per il funzionamento del gateway.

Forzare la comunicazione HTTPS con il bus di servizio di Azure

È possibile imporre al gateway di comunicare con il bus di servizio di Azure tramite HTTPS anziché TCP diretto. Ciò può avere un impatto sulle prestazioni. A questo scopo, modificare il file Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config cambiando il valore da AutoDetect a Https, come mostrato nel frammento di codice riportato subito dopo questo paragrafo. Per impostazione predefinita, il file si trova in C:\Programmi\Gateway dati locale.

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

In alternativa, è possibile imporre al gateway di adottare questo comportamento usando l'interfaccia utente del gateway, a partire dalla versione di marzo 2017. Nell'interfaccia utente del gateway selezionare Rete, quindi impostare Modalità di connettività del bus di servizio di Azure su Attiva.

Una volta modificato, quando si seleziona Applica (un pulsante che viene visualizzato solo quando si apporta una modifica), il gateway del servizio Windows viene riavviato automaticamente, in modo che le modifiche abbiano effetto.

Per riferimento futuro, è possibile riavviare il servizio Windows del gateway nella finestra di dialogo dell'interfaccia utente, selezionando Impostazioni servizio e quindi Riavvia adesso.

Come riavviare il gateway

Il gateway viene eseguito come servizio di Windows. È possibile avviarlo e arrestarlo come qualsiasi servizio di Windows. A questo scopo è possibile procedere in diversi modi. Ecco come farlo dal prompt dei comandi.

  1. Sul computer in cui è in esecuzione il gateway, avviare un prompt dei comandi come amministratore.

  2. Usare il comando seguente per arrestare il servizio.

    net stop PBIEgwService

  3. Usare il comando seguente per avviare il servizio.

    net start PBIEgwService

Vedere anche

Risoluzione dei problemi del gateway dati locale
Bus di servizio di Azure
Azure AD Connect
Altre domande? Provare la community di Power BI