Gestire le origini dati di SQL Server Analysis Services
Dopo aver installato un gateway dati locale, è possibile aggiungere origini dati da usare con il gateway. Questo articolo descrive come aggiungere un'origine dati di SQL Server Analysis Services (SSAS) al gateway locale da usare per l'aggiornamento pianificato o per le connessioni dinamiche.
Per altre informazioni su come configurare una connessione dinamica a SSAS, guardare il video Procedura dettagliata di Power BI: Analysis Services Live Connect.
Nota
La documentazione del gateway dati locale è stata suddivisa in contenuto specifico di Power BI e contenuto generale applicabile a tutti i servizi supportati dal gateway. Ci si trova attualmente nel contenuto di Power BI. Per inviare commenti e suggerimenti su questo articolo o sull'esperienza generale relativa alla documentazione sul gateway, scorrere fino alla fine dell'articolo.
Nota
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.
Nota
Il gateway supporta solo l'autenticazione di Windows per Analysis Services.
Aggiungere un'origine dati
Per connettersi a un'origine dati multidimensionale o tabulare di Analysis Services:
Nella schermata Nuova connessione per il gateway dati locale selezionare Analysis Services per Tipo di connessione. Per altre informazioni sull'aggiunta di un'origine dati, vedere Aggiungere un'origine dati.
Immettere le informazioni per l'origine dati, ovvero Server e Database. Il gateway usa le informazioni immesse per Nome utente e Password per connettersi all'istanza di Analysis Services.
Nota
L'account di Windows immesso deve essere un membro del ruolo di amministratore del server nell'istanza di Analysis Services a cui ci si connette. Se la password dell'account è impostata per scadere, gli utenti ricevono un errore di connessione a meno che non si aggiorni la password dell'origine dati. Per altre informazioni sulla modalità di archiviazione delle credenziali, vedere Archiviare le credenziali crittografate nel cloud.
Configurare il Livello di privacy per l'origine dati. Questa impostazione controlla come combinare i dati per l'aggiornamento pianificato. ma non si applica alle connessioni in tempo reale. Per altre informazioni sui livelli di privacy per l'origine dati, vedere Impostazione dei livelli di privacy (Power Query).
Facoltativamente, è possibile configurare ora il mapping dei nomi utente. Per istruzioni, vedere Mapping manuale del nome utente.
Dopo aver completato tutti i campi, selezionare Crea.
È ora possibile usare questa origine dati per l'aggiornamento pianificato o le connessioni dinamiche su un'istanza di Analysis Services locale.
Nomi utente per Analysis Services
Ogni volta che un utente interagisce con un report connesso ad Analysis Services, il nome utente effettivo passa al gateway e quindi passa al server Analysis Services locale. L'indirizzo di posta elettronica usato per accedere a Power BI passa ad Analysis Services come utente effettivo nella proprietà di connessione EffectiveUserName.
Questo indirizzo di posta elettronica deve corrispondere a un nome di entità utente (UPN) definito nel dominio di Active Directory (AD) locale. L'UPN è una proprietà di un account AD. L'account di Windows deve essere presente in un ruolo Analysis Services. Se non è possibile trovare una corrispondenza in Active Directory, l'accesso non riesce. Per altre informazioni su Active Directory e sulla denominazione degli utenti, vedere Attributi di denominazione degli utenti.
Eseguire il mapping dei nomi utente per le origini dati di Analysis Services
Power BI consente il mapping dei nomi utente per le origini dati di Analysis Services. È possibile configurare le regole per eseguire il mapping di un nome utente di accesso di Power BI a un oggetto EffectiveUserName
che passa alla connessione di Analysis Services. Questa funzionalità è un'ottima soluzione alternativa quando il nome utente di Microsoft Entra non corrisponde a un UPN nell'istanza di Active Directory locale. Ad esempio, se l'indirizzo di posta elettronica è meganb@contoso.onmicrosoft.com
, è possibile eseguirne il mapping a meganb@contoso.com
e tale valore passa al gateway.
È possibile eseguire il mapping dei nomi utente per Analysis Services in due modi diversi:
- Modifica manuale del mapping degli utenti in Power BI
- Mapping di ricerca di Active Directory, che usa la ricerca della proprietà AD locale per eseguire nuovamente il mapping dei nomi UPN di Microsoft Entra agli utenti di ACTIVE Directory locali.
È possibile eseguire il mapping manuale usando la ricerca delle proprietà di Active Directory locale, ma richiede molto tempo ed è difficile da gestire, soprattutto quando i criteri di ricerca non sono sufficienti. Ad esempio, i nomi di dominio o i nomi degli account utente potrebbero essere diversi tra Microsoft Entra ID e AD locale. Pertanto, il mapping manuale con il secondo approccio non è consigliato.
Le sezioni seguenti descrivono i due approcci di mapping.
Modifica manuale del mapping degli utenti in Power BI
È possibile configurare regole UPN personalizzate in Power BI per le origini dati di Analysis Services. Le regole personalizzate sono utili se il nome di accesso al servizio Power BI non corrisponde all'UPN della directory locale. Ad esempio, se si accede a Power BI con meganb@contoso.com
ma l'UPN della directory locale è meganb@contoso.local
, è possibile configurare una regola di mapping per passare meganb@contoso.local
ad Analysis Services.
Importante
Il mapping funziona per l'origine dati specifica configurata. e non è un'impostazione globale. Se sono presenti più origini dati di Analysis Services, è necessario eseguire il mapping degli utenti per ogni origine dati.
Per eseguire il mapping UPN manuale, seguire questa procedura:
Sotto l'icona a forma di ingranaggio di Power BI selezionare Gestisci gateway e connessioni.
Selezionare l'origine dati e quindi selezionare Impostazioni dal menu in alto.
Nella schermata Impostazioni, nella casella Mapping dei nomi utente verificare che EffectiveUserName sia selezionato e quindi selezionare Aggiungi nuova regola.
In Mapping dei nomi utente, per ogni nome utente da mappare, immettere i valori per Nome originale e Nuovo nome e quindi selezionare Aggiungi nuova regola. Il valore Replace è l'indirizzo di accesso per Power BI e il valore With è il valore con cui sostituirlo. La sostituzione passa alla proprietà
EffectiveUserName
per la connessione di Analysis Services.Nota
Assicurarsi di non modificare gli utenti che non si intende modificare. Ad esempio, se si sostituisce il Nome originale di
contoso.com
con un Nuovo nome di@contoso.local
, tutti gli accessi utente che contengono@contoso.com
vengono sostituiti con@contoso.local
. Inoltre, se si sostituisce un Nome originale dimeganb@contoso.com
con un Nuovo nome dimeganb@contoso.local
, un accesso div-meganb@contoso.com
viene inviato comev-meganb@contoso.local
.È possibile selezionare un elemento nell'elenco e riordinarlo trascinandolo ed eliminando una voce selezionando l'icona del cestino.
Usare un carattere jolly
È possibile usare un carattere jolly (*) per la stringa Sostituisci (nome originale). È possibile usare solo il carattere jolly in modo autonomo e non con altre parti di stringa. Usare un carattere jolly se si desidera sostituire tutti gli utenti con un singolo valore da passare all'origine dati. Tale approccio è utile quando si desidera che tutti gli utenti in un'organizzazione usino lo stesso nome utente nell'ambiente locale.
Testare la regola di mapping
Per convalidare la sostituzione del nome, immettere un valore per Nome originalee selezionare Regola di test.
Nota
Le regole salvate funzionano immediatamente nel browser. L'uso delle regole salvate richiede alcuni minuti prima che il servizio Power BI inizi a usare le regole salvate.
Mapping con ricerca tramite Active Directory
Questa sezione descrive come eseguire una ricerca di proprietà di Active Directory locale per eseguire il nuovo mapping degli UPN di Microsoft Entra agli utenti di AD. Prima di tutto, esaminare il funzionamento del nuovo mapping.
Ogni query eseguita da un utente di Power BI Microsoft Entra a un server SSAS locale passa lungo una stringa UPN, ad esempio firstName.lastName@contoso.com
.
Il mapping di ricerca in un gateway dati locale con mapping utente personalizzato configurabile segue questa procedura:
- Trovare Active Directory in cui eseguire la ricerca. automatica o configurabile.
- Cercare l'attributo dell'utente di Active Directory, ad esempio Posta elettronica, dal servizio Power BI. Tale attributo è basato su una stringa UPN in ingresso, come
firstName.lastName@contoso.com
. - Se la ricerca di Active Directory non riesce, tenta di passare l'UPN a SSAS come
EffectiveUserName
. - Se la ricerca di Active Directory ha esito positivo, recupera l'oggetto dell'utente
UserPrincipalName
di Active Directory. - Il mapping passa il messaggio di posta elettronica
UserPrincipalName
, ad esempioAlias@corp.on-prem.contoso
, a SSAS comeEffectiveUserName
.
Nota
Tutti i mapping utente UPN manuali definiti nella configurazione del gateway dell'origine dati di Power BI vengono applicati prima di inviare la stringa UPN al gateway dati locale.
Affinché la ricerca di Active Directory funzioni correttamente in fase di esecuzione, è necessario modificare il servizio gateway dati locale per l'esecuzione con un account di dominio anziché con un account del servizio locale.
Assicurarsi di scaricare e installare il gateway più recente.
Nell'app Gateway dati locale nel computer passare a Impostazioni del servizio>Modifica account del servizio. Assicurarsi di avere la chiave di ripristino per il gateway, perché è necessario ripristinarlo nello stesso computer, a meno che non si voglia creare un nuovo gateway. Per rendere effettiva la modifica, è necessario riavviare il servizio gateway.
Passare alla cartella di installazione del gateway, C:\Programmi\gateway dati locale, come amministratore e verificare di disporre delle autorizzazioni di scrittura. Aprire il file Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config.
Modificare i valori
ADUserNameLookupProperty
eADUserNameReplacementProperty
in base alle configurazioni degli attributi di Active Directory per gli utenti di Active Directory. I valori nell'immagine seguente sono esempi. Queste configurazioni fanno distinzione tra maiuscole e minuscole, quindi assicurarsi che corrispondano ai valori in AD.Se il file non fornisce alcun valore per la configurazione di
ADServerPath
, il gateway usa il catalogo globale predefinito. È possibile specificare più valori perADServerPath
. I valori devono essere separati da punto e virgola, come nell'esempio seguente:<setting name="ADServerPath" serializeAs="String"> <value> GC://serverpath1; GC://serverpath2;GC://serverpath3</value> </setting>
Il gateway analizza i valori per
ADServerPath
da sinistra a destra fino a quando non trova una corrispondenza. Se il gateway non trova una corrispondenza, usa l'UPN originale. Assicurarsi che l'account che esegue il servizio gateway, PBIEgwService, disponga delle autorizzazioni di query per tutti i server AD specificati inADServerPath
.Il gateway supporta due tipi di
ADServerPath
:- Per WinNT:
<value="WinNT://usa.domain.corp.contoso.com,computer"/>
- Per il catalogo globale (GC):
<value> GC://USA.domain.com </value>
- Per WinNT:
Riavviare il servizio gateway dati locale per rendere effettiva la modifica della configurazione.
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. L'UPN, che è in genere l'indirizzo di posta elettronica usato per accedere al cloud, viene passato ad Analysis Services come utente effettivo nella proprietà di connessione EffectiveUserName
.
Quando il set di dati è in modalità di importazione, il gateway invierà il valore EffectiveUserName dell'UPN del proprietario del set di dati. Ciò significa che l'UPN del proprietario del set di dati verrà passato ad Analysis Services come utente effettivo 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 AD. Per accedere al server, un account di Windows deve quindi essere presente in un ruolo di Analysis Services. Se in Active Directory non viene rilevata alcuna corrispondenza, non è possibile eseguire l'accesso.
Sicurezza basata su ruoli e a livello di riga
Analysis Services può anche fornire filtri in base all'account di Active Directory. Il filtro può usare la sicurezza basata sui ruoli o la sicurezza a livello di riga. La capacità di un utente di eseguire query e visualizzare i dati del modello dipende dai ruoli a cui appartiene l'account utente di Windows e dalla sicurezza dinamica a livello di riga, se configurata.
Sicurezza basata sui ruoli. I modelli assicurano la sicurezza basata sui ruoli utente. È possibile definire i ruoli per un progetto di modello specifico durante la creazione in strumenti di Business Intelligence di SQL Server Data Tools. Dopo la distribuzione di un modello, è possibile definire i ruoli usando SQL Server Management Studio. I ruoli contengono membri assegnati dal nome utente di Windows o dal gruppo di Windows.
I ruoli definiscono le autorizzazioni che gli utenti devono eseguire query o eseguire azioni sul modello. La maggior parte degli utenti appartiene a un ruolo con autorizzazioni di lettura. Altri ruoli offrono agli amministratori le autorizzazioni per elaborare gli elementi, gestire le funzioni del database e gestire altri ruoli.
Sicurezza a livello di riga. I modelli possono fornire sicurezza dinamica a livello di riga. Qualsiasi sicurezza a livello di riga definita è specifica di Analysis Services. Per la sicurezza basata sui ruoli, ogni utente deve avere almeno un ruolo, ma nessun modello tabulare richiede la sicurezza dinamica a livello di riga.
A livello generale, la sicurezza dinamica definisce l'accesso in lettura di un utente ai dati in determinate righe in determinate tabelle. In modo analogo ai ruoli, la sicurezza dinamica a livello di riga si basa su un nome utente Windows.
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 nei modelli tabulari e Ruoli di sicurezza (Analysis Services - Dati multidimensionali). Per una conoscenza più approfondita della sicurezza nel modello tabulare, scaricare il white paper Protezione del modello semantico BI tabulare.
Autenticazione Microsoft Entra
I servizi cloud Microsoft usano Microsoft Entra ID per autenticare gli utenti. Microsoft Entra ID è il tenant che contiene nomi utente e gruppi di sicurezza. In genere, un utente accede con lo stesso indirizzo di posta elettronica dell'UPN dell'account.
Ruoli nell'istanza di Active Directory locale
Affinché Analysis Services determini se un utente appartiene a un ruolo con autorizzazioni per la lettura dei dati, il server deve convertire il nome utente effettivo passato da Microsoft Entra ID al gateway e al server Analysis Services. Quest'ultimo 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 nome dell'entità utente valido in un account locale Il controller di dominio restituisce il nome utente di Windows dell'utente al server Analysis Services.
Non è possibile usare EffectiveUserName
in un server Analysis Services non aggiunto a un dominio. Per evitare errori di accesso, il server di Analysis Services locale deve appartenere a un dominio.
Identificare l'UPN
È possibile che non si conosca il nome dell'entità utente e che l'utente non sia un amministratore di dominio. È possibile usare il comando seguente dalla workstation per identificare l'UPN dell'account:
whoami /upn
Il risultato è analogo a un indirizzo di posta elettronica, ma si tratta del nome dell'entità utente presente nell'account di dominio. Se si usa un'origine dati di Analysis Services per le connessioni dinamiche e questo UPN non corrisponde all'indirizzo di posta elettronica usato per accedere a Power BI, potrebbe essere necessario eseguire il mapping del nome utente.
Sincronizzare un'istanza locale di AD con Microsoft Entra ID
Se si prevede di usare le connessioni dinamiche di Analysis Services, gli account AD locali devono corrispondere all'ID Microsoft Entra. Il nome dell'entità utente deve corrispondere negli account.
I servizi cloud usano solo gli account all'interno di Microsoft Entra ID. Se si aggiunge un account nell'istanza di AD locale che non esiste nell'ID Microsoft Entra, non è possibile usare l'account. Esistono diversi modi per associare gli account AD locali con Microsoft Entra ID:
Aggiungere manualmente gli account all'ID Microsoft Entra.
Creare un account nel portale di Azure o nell'interfaccia di amministrazione di Microsoft 365 con un nome di account corrispondente all'UPN dell'account AD locale.
Usare Microsoft Entra Connect Sync per sincronizzare gli account locali con il tenant di Microsoft Entra.
Microsoft Entra Connect garantisce che l'UPN corrisponda tra Microsoft Entra ID e l'istanza di AD locale. Lo strumento Microsoft Entra Connect offre opzioni per la sincronizzazione della directory e la configurazione dell'autenticazione. Tali opzioni includono la sincronizzazione dell'hash delle password, l'autenticazione pass-through e la federazione. Se non si è un amministratore o un amministratore del dominio locale, contattare l'amministratore IT per eseguire la configurazione.
Nota
La sincronizzazione degli account con Microsoft Entra Connect Sync crea nuovi account all'interno del tenant di Microsoft Entra.
Usare l'origine dati
Dopo aver aggiunto l'origine dati SSAS, è disponibile per l'uso con connessioni dinamiche o tramite l'aggiornamento pianificato.
Nota
I nomi del server e del database devono corrispondere tra Power BI Desktop e l'origine dati nel gateway dati locale.
Il collegamento tra il set di dati e l'origine dati all'interno del gateway si basa sul nome del server e sul nome del database. Tali nomi devono corrispondere. Se ad esempio si specifica un indirizzo IP per il nome del server all'interno di Power BI Desktop, è necessario usare l'indirizzo IP per l'origine dati nella configurazione del gateway. Se si usa SERVER\INSTANCE in Power BI Desktop, è necessario anche usare SERVER\INSTANCE all'interno dell'origine dati configurata per il gateway. Questo requisito è valido sia per le connessioni dinamiche che per l'aggiornamento pianificato.
Usare l'origine dati con le connessioni dinamiche
È possibile usare una connessione dinamica su istanze tabulari o multidimensionali. Quando ci si connette per la prima volta ai dati, selezionare una connessione dinamica in Power BI Desktop. Verificare che i nomi del server e del database corrispondano in Power BI Desktop e l'origine dati configurata per il gateway. Inoltre, per poter pubblicare set di dati di connessione dinamica, gli utenti devono essere visualizzati in Utenti nell'elenco delle origini dati.
Dopo aver pubblicato i report, da Power BI Desktop o recuperando i dati nel servizio Power BI, la connessione dati dovrebbe iniziare a funzionare. Potrebbero essere necessari alcuni minuti dopo aver creato l'origine dati nel gateway prima di poter usare la connessione.
Uso dell’origine dati con l'aggiornamento pianificato
Se l'utente corrente è presente nella scheda Utenti dell'origine dati configurata all'interno del gateway e i nomi del server e del database corrispondono, il gateway viene visualizzato come un'opzione per l'uso con l'aggiornamento pianificato.
Limitazioni di connessioni dinamiche ad Analysis Services
La formattazione a livello di cella e le funzionalità di conversione non sono supportate.
Azioni e set denominati non sono esposti a Power BI. È comunque possibile connettersi a cubi multidimensionali che contengono azioni o set denominati per creare oggetti visivi e report.
Requisiti dello SKU
Versione del server | SKU necessario |
---|---|
2014 | Business Intelligence e SKU Enterprise |
2016 | SKU standard o versione successiva |
2017 | SKU standard o versione successiva |
2019 | SKU standard o versione successiva |
2022 | SKU standard o versione successiva |
Contenuto correlato
Altre domande? Provare la Community di Power BI.