Benutzer in Ihrer Organisation können auf lokale Daten zugreifen (für die sie bereits über Zugriffsberechtigungen verfügen). Bevor diese Benutzer jedoch eine Verbindung mit der lokalen Datenquelle herstellen können, muss ein lokales Datengateway installiert und konfiguriert werden. Das Gateway ermöglicht die schnelle und sichere, im Hintergrund ablaufende Kommunikation eines Benutzers in der Cloud mit Ihrer lokalen Datenquelle und zurück in die Cloud.

Das Installieren und Konfigurieren eines Gateways wird normalerweise von einem Administrator vorgenommen. Dazu sind möglicherweise fundierte Kenntnisse Ihrer lokalen Server und in bestimmten Fällen auch Serveradministratorberechtigungen erforderlich.

In diesem Artikel erhalten Sie keine schrittweise Anleitung zum Installieren und Konfigurieren des Gateways. Lesen Sie zu diesem Thema unbedingt den Artikel On-premises Data Gateway. Ziel dieses Artikels ist es, Ihnen einen detaillierten Einblick in die Funktionsweise des Gateways zu vermitteln. Es werden Benutzernamen und Sicherheitsaspekte sowohl bei Azure Active Directory als auch bei Analysis Services etwas erörtert. Außerdem wird besprochen, wie der Clouddienst die für die Anmeldung erforderliche E-Mail-Adresse, das Gateway und Active Directory nutzt, um eine sichere Verbindung mit Ihren lokalen Daten herzustellen und diese sicher abzufragen.

So funktioniert das Gateway

so-funktioniert-on-prem-data-gateway

Sehen wir uns zunächst an, was geschieht, wenn ein Benutzer mit einem Element interagiert, das mit einer lokalen Datenquelle verbunden ist.

Hinweis:

Für Power BI müssen Sie eine Datenquelle für das Gateway konfigurieren.

  1. Eine Abfrage wird vom Clouddienst zusammen mit den verschlüsselten Anmeldeinformationen für die lokale Datenquelle erstellt und an die Warteschlange für die Bearbeitung durch das Gateway gesendet.

  2. Die Abfrage wird daraufhin vom Gatewayclouddienst analysiert und die Anforderung mithilfe von Push an Azure Service Bus übertragen.

  3. Das On-premises data gateway fragt Azure Service Bus für ausstehende Anfragen ab.

  4. Das Gateway ruft die Abfrage ab, entschlüsselt die Anmeldeinformationen und stellt unter Verwendung dieser Anmeldeinformationen eine Verbindung mit der Datenquelle bzw. den Datenquellen her.

  5. Das Gateway sendet die Abfrage zur Ausführung an die Datenquelle.

  6. Die Ergebnisse werden von der Datenquelle zurück an das Gateway und anschließend weiter an den Clouddienst gesendet. Der Dienst verwendet dann die Ergebnisse.

Liste der verfügbaren Datenquellentypen

Datenquelle Live/DirectQuery Benutzerdefinierte manuelle oder geplante Aktualisierung
Analysis Services (tabellarisch) Ja Ja
Analysis Services (mehrdimensional) Ja Ja
SQL Server Ja Ja
SAP HANA Ja Ja
Oracle Ja Ja
Teradata Ja Ja
Datei Nein Ja
Ordner Nein Ja
SharePoint-Liste (lokal) Nein Ja
Web Nein Ja
OData Nein Ja
IBM DB2 Nein Ja
MySQL Nein Ja
Sybase Nein Ja
SAP BW Nein Ja
IBM Informix-Datenbank Nein Ja
ODBC Nein Ja

Das Anmeldekonto

Benutzer melden sich entweder mit einem Geschäfts-, Schul- oder Unikonto an. Dies ist das Konto Ihrer Organisation. Wenn Sie sich für ein Office 365-Angebot registriert haben und nicht Ihre tatsächliche geschäftliche E-Mail-Adresse angegeben haben, könnte es wie „nancy@contoso.onmicrosoft.com“ aussehen. Ihr Konto wird innerhalb eines Clouddiensts in einem Mandanten in Azure Active Directory (AAD) gespeichert. In den meisten Fällen entspricht der UPN Ihres AAD-Kontos der E-Mail-Adresse.

Authentifizierung gegenüber lokalen Datenquellen

Für die Verbindung vom Gateway aus zu lokalen Datenquellen, mit Ausnahme von Analysis Services, werden gespeicherte Anmeldeinformationen verwendet. Das Gateway verwendet die gespeicherten Anmeldeinformationen bei allen Benutzern zur Verbindungsherstellung.

Authentifizierung gegenüber einer Analysis Services-Livedatenquelle

Bei jeder Interaktion eines Benutzers mit Analysis Services, wird der effektive Benutzername an das Gateway und von dort aus an Ihren lokalen Analysis Services-Server übergeben. Als effektiver Benutzer wird der Benutzerprinzipalname (user principal name; UPN) – üblicherweise die E-Mail-Adresse, mit der Sie sich in der Cloud anmelden – an Analysis Services übergeben. Der UPN wird in der Verbindungseigenschaft „EffectiveUserName“ übergeben. Diese E-Mail-Adresse muss mit einem in der lokalen Active Directory-Domäne definierten UPN übereinstimmen. Der UPN ist eine Eigenschaft des Active Directory-Kontos. Das Windows-Konto muss dann in einer Analysis Services-Rolle vorhanden sein, um Zugriff auf den Server zu erhalten. Die Anmeldung wird nicht erfolgreich durchgeführt, wenn in Active Directory keine Übereinstimmung gefunden werden kann.

Analysis Services kann darüber hinaus eine Filterfunktion basierend auf diesem Konto bereitstellen. Es kann sowohl auf Grundlage eines rollenbasierten Sicherheitsmodells als auch auf Grundlage eines Sicherheitsmodells auf Zeilenebene gefiltert werden.

Rollenbasierte Sicherheit

Modelle stellen Sicherheit auf der Grundlage von Benutzerrollen bereit. Rollen werden für ein bestimmtes Modellprojekt während der Erstellung in den SQL Server Data Tools – Business Intelligence (SSDT-BI) oder nach der Bereitstellung des Modells mithilfe von SQL Server Management Studio (SSMS) definiert. Rollen enthalten Mitglieder, die anhand ihres Windows-Benutzernamens oder ihrer Windows-Gruppe angegeben sind. Rollen definieren die Berechtigungen eines Benutzers zu Abfragen oder Aktionen im Modell. In der Praxis werden die meisten Benutzer einer Rolle mit Leseberechtigungen angehören. Andere Rollen sind für Administratoren mit der Berechtigung zum Verarbeiten von Elementen, Verwalten von Datenbankfunktionen und Verwalten anderer Rollen vorgesehen.

Sicherheit auf Zeilenebene

Sicherheit auf Zeilenebene ist eine für Analysis Services charakteristische Funktion. Modelle können dynamische Sicherheitseinstellungen auf Zeilenebene bereitstellen. Im Gegensatz zu Rollen, von denen mindestens eine erforderlich ist, die Benutzer enthält, ist dynamische Sicherheit für tabellarische Modelle grundsätzlich nicht erforderlich. Allgemein ausgedrückt definiert dynamische Sicherheit den Lesezugriff eines Benutzers auf Daten bis hinunter zu einer bestimmten Zeile in einer bestimmten Tabelle. Ähnlich wie Rollen beruht dynamische Sicherheit auf Zeilenebene auf den Windows-Benutzernamen von Benutzern.

Die Berechtigung eines Benutzers, Daten des Modells abzufragen und anzuzeigen, wird erstens durch die Rollen bestimmt, deren Mitglied sein Windows-Benutzerkonto ist, und zweitens durch die dynamische Sicherheit auf Zeilenebene, sofern sie konfiguriert ist.

Das Implementieren von rollenbasierter Sicherheit und dynamischer Sicherheit auf Zeilenebene in Modellen würde den Rahmen dieses Artikels sprengen. Weitere Informationen finden Sie unter Rollen (SSAS – tabellarisch) und Sicherheitsrollen (Analysis Services – mehrdimensionale Daten) auf MSDN. Eine besonders fundierte Darstellung der Sicherheit in tabellarischen Modellen finden Sie im Whitepaper Securing the Tabular BI Semantic Model (Sichern des semantischen BI-Tabellenmodells).

Welche Rolle spielt Azure Active Directory?

Die Clouddienste von Microsoft verwenden Azure Active Directory für die Authentifizierung von Benutzern. Azure Active Directory ist der Mandant, der die Benutzernamen und Sicherheitsgruppen enthält. In der Regel entspricht die E-Mail-Adresse, mit der sich ein Benutzer anmeldet, dem UPN des Kontos.

Welcher Rolle gehört mein lokales Active Directory an?

Damit Analysis Services bestimmen kann, ob ein Benutzer, der eine Verbindung mit ihm herstellt, einer Rolle angehört, die über Berechtigungen zum Lesen von Daten verfügt, muss der Server den von AAD an das Gateway und an den Analysis Services-Server übergebenen effektiven Benutzernamen konvertieren. Der Analysis Services-Server übergibt den effektiven Benutzernamen an einen Windows Active Directory-Domänencontroller (DC). Der Active Directory-DC überprüft dann, ob der effektive Benutzername ein gültiger UPN ist, und gibt den Windows-Benutzernamen des betreffenden Benutzers an den Analysis Services-Server zurück.

EffectiveUserName kann nicht auf einem Analysis Services-Server verwendet werden, der nicht mit der Domäne verknüpft ist. Der Analysis Services-Server muss einer Domäne angehören, um Anmeldefehler zu vermeiden.

Woher weiß ich meinen UPN?

Sie kennen möglicherweise nicht Ihren UPN und sind auch kein Domänenadministrator. Sie können den folgenden Befehl von Ihrer Arbeitsstation ausführen, um den UPN für Ihr Konto zu ermitteln.

whoami /upn

Das Ergebnis ähnelt einer E-Mail-Adresse, es handelt sich aber um den UPN für Ihr lokales Domänenkonto. Wenn Sie eine Analysis Services-Datenquelle für Liveverbindungen verwenden, muss diese mit der vom Gateway an EffectiveUserName übergebenen übereinstimmen.

Zuordnen von Benutzernamen zu Analysis Services-Datenquellen

Power BI ermöglicht die Zuordnung von Benutzernamen zu Analysis Services-Datenquellen. Sie können Regeln konfigurieren, um einen in Power BI angemeldeten Benutzernamen einem Namen zuzuordnen, der in EffectiveUserName über die Analysis Services-Verbindung übergeben wird. Diese Funktion zur Zuordnung von Benutzernamen ist eine hervorragende Möglichkeit, das Problem zu umgehen, wenn Ihr Benutzername für AAD nicht mit einem UPN in Ihrem lokalen Active Directory übereinstimmt. Wenn Ihre E-Mail-Adresse beispielsweise nancy@contoso.onmicrsoft.com lautet, könnten Sie diese nancy@contoso.com zuordnen. Dieser Wert würde dann an das Gateway übergeben. Erfahren Sie mehr über das Zuordnen von Benutzernamen.

Synchronisieren eines lokalen Active Directorys mit Azure Active Directory

Ihre lokalen Active Directory-Konten sollten denen in Azure Active Directory entsprechen, wenn Sie planen, Analysis Services-Liveverbindungen zu verwenden. Ebenso wie der UPN der Konten übereinstimmen muss.

Die Clouddienste haben nur Kenntnis von Konten in Azure Active Directory. Es spielt keine Rolle, wenn Sie ein Konto in Ihrem lokalen Active Directory hinzufügen. Wenn es in AAD nicht vorhanden ist, kann es nicht verwendet werden. Es gibt verschiedene Möglichkeiten, Ihre lokalen Active Directory-Konten mit Azure Active Directory abzugleichen.

  1. Sie können Konten in Azure Active Directory manuell hinzufügen.

    Sie können im Azure-Portal oder im Office 365 Admin Portal ein Konto erstellen, bei dem der Kontoname dem UPN des lokalen Active Directory-Kontos entspricht.

  2. Sie können das Azure AD Connect-Tool verwenden, um lokale Konten mit Ihrem Azure Active Directory-Mandanten zu synchronisieren.

    Das Azure AD Connect-Tool stellt Optionen für die Synchronisierung des Verzeichnisses und des Kennworts bereit. Wenn Sie weder ein Mandantenadministrator noch ein lokaler Domänenadministrator sind, müssen Sie sich für diese Konfiguration an Ihren IT-Administrator wenden.

  3. Sie können Active Directory-Verbunddienste (Active Directory Federation Services; AD FS) konfigurieren.

    Sie können den AD FS-Server mithilfe des Azure AD Connect-Tools Ihrem AAD-Mandanten zuordnen. AD FS verwendet die zuvor erwähnte Verzeichnissynchronisierung, erlaubt aber auch das einmalige Anmelden (Single Sign-On; SSO). Wenn Sie sich beispielsweise in Ihrem Arbeitsplatznetzwerk befinden und sich bei einem Clouddienst anmelden möchten, werden Sie möglicherweise nicht dazu aufgefordert, Ihren Benutzernamen oder Ihr Kennwort einzugeben. Sie müssen mit Ihrem IT-Administrator besprechen, ob diese Funktion für Ihre Organisation verfügbar ist.

Mit Azure AD Connect können Sie sicherstellen, dass der UPN Ihres AAD-Kontos und der Ihres lokalen Active Directory-Kontos übereinstimmen.

Hinweis:

Das Synchronisieren von Konten mithilfe des Azure AD Connect-Tools erstellt neue Konten in Ihrem AAD-Mandanten.

Das Gateway

Das Gateway fungiert als Brücke zwischen der Cloud und Ihrem lokalen Server. Die Datenübertragung zwischen der Cloud und dem Gateway ist mithilfe des Azure Service Bus geschützt. Der Service Bus erstellt einen sicheren Kanal zwischen der Cloud und Ihrem lokalen Server über eine ausgehende Verbindung auf dem Gateway. Sie müssen dazu keine eingehenden Verbindungen in Ihrer lokalen Firewall zulassen.

Wenn Sie über eine Analysis Services-Datenquelle verfügen, müssen Sie das Gateway auf einem Computer installieren, der der gleichen Gesamtstruktur oder Domäne wie der Analysis Services-Server angehört.

Je kürzer die Entfernung zwischen Gateway und Server, desto schneller ist die Verbindung. Eine Netzwerklatenz zwischen Gateway und Server lässt sich am besten vermeiden, indem das Gateway auf dem gleichen Server wie die Datenquelle installiert wird.

Nächste Schritte

Nachdem Sie das Gateway installiert haben, sollten Sie die Datenquellen für dieses Gateway erstellen. Sie können Datenquellen im Bildschirm Gateways verwalten hinzufügen. Weitere Informationen finden Sie in den Artikeln zum Verwalten von Datenquellen.

Verwalten Ihrer Datenquelle – Analysis Services
Verwalten Ihrer Datenquelle –SAP HANA
Verwalten Ihrer Datenquelle – SQL Server
Verwalten der Datenquelle – Oracle
Verwalten der Datenquelle – Import/Geplante Aktualisierung

An welchen Stellen etwas schief gehen kann

Manchmal tritt beim Installieren des Gateways ein Fehler auf. Oder aber die Installation des Gateways scheint erfolgreich verlaufen zu sein, und der Dienst kann es trotzdem nicht verwenden. Oft hat das Problem eine ganz einfache Ursache, z. B. das Kennwort für die Anmeldeinformationen, mit denen das Gateway bei der Datenquelle angemeldet wird.

In anderen Fällen können Probleme mit dem E-Mail-Adresstyp auftreten, den Benutzer für die Anmeldung verwenden, oder Analysis Services kann einen effektiven Benutzernamen nicht auflösen. Wenn Sie über mehrere Domänen mit eingerichteten Vertrauensstellungen verfügen und ihr Gateway sich in der einen, Analysis Services sich aber in einer anderen befindet, kann das manchmal zu Problemen führen.

Anstatt hier ausführlich auf die Behandlung von Gatewayproblemen einzugehen, haben wir eine Reihe von Tipps zur Problembehandlung im Artikel Troubleshooting the On-premises Data Gateway (On-premises Data Gateway – Problembehandlung) zusammengestellt. Hoffentlich treten bei Ihnen keine Probleme auf. Falls aber doch, sollte Ihr Verständnis dieser Zusammenhänge in Verbindung mit dem Artikel zur Problembehandlung weiterhelfen.

Das Anmeldekonto

Benutzer melden sich entweder mit einem Geschäfts-, Schul- oder Unikonto an. Dies ist das Konto Ihrer Organisation. Wenn Sie sich für ein Office 365-Angebot registriert haben und nicht Ihre tatsächliche geschäftliche E-Mail-Adresse angegeben haben, könnte es wie „nancy@contoso.onmicrosoft.com“ aussehen. Ihr Konto wird innerhalb eines Clouddiensts in einem Mandanten in Azure Active Directory (AAD) gespeichert. In den meisten Fällen entspricht der UPN Ihres AAD-Kontos der E-Mail-Adresse.

Windows-Dienstkonto

Das On-premises data gateway ist so konfiguriert, dass als Anmeldeinformationen für den Windows-Dienst NT SERVICE\PBIEgwService verwendet wird. Das Gateway hat standardmäßig die Berechtigung „Anmelden als Dienst“. Diese befindet sich im Kontext des Computers, auf dem das Gateway installiert wird.

Hinweis:

Wenn Sie den persönlichen Modus ausgewählt haben, konfigurieren Sie das Windows-Dienstkonto separat.

Dies ist nicht das Konto, das für die Verbindung mit lokalen Datenquellen verwendet wird. Dies ist auch nicht Ihr Geschäfts-, Schul- oder Unikonto, mit dem Sie sich bei Clouddiensten anmelden.

Wenn aufgrund der Authentifizierung Probleme beim Proxyserver auftreten, sollten Sie das Windows-Dienstkonto in ein Domänenbenutzerkonto oder verwaltetes Dienstkonto ändern. Erfahren Sie, wie Sie das Konto in der Proxykonfiguration ändern.

Ports

Das Gateway stellt eine ausgehende Verbindung mit Azure Service Bus her. Die Kommunikation erfolgt über die ausgehenden Ports TCP 443 (Standardwert), 5671, 5672, 9350 bis 9354. Das Gateway benötigt keine eingehenden Ports. Weitere Informationen

Es wird empfohlen, in der Firewall die Blockierung der IP-Adressen für Ihren Datenbereich aufzuheben. Sie können die Liste der Microsoft Azure Datacenter IP-Adressen herunterladen. Diese Liste wird wöchentlich aktualisiert. Das Gateway verwendet für die Kommunikation mit Azure Service Bus die IP-Adresse zusammen mit dem vollständig qualifizierten Domänennamen (Fully Qualified Domain Name, FQDN). Wenn Sie für das Gateway Kommunikation per HTTPS erzwingen, verwendet das Gateway ausschließlich den FQDN, und es erfolgt keine Kommunikation mithilfe von IP-Adressen.

Hinweis:

Die IP-Adressen in der Liste der Azure-Datacenter-IP-Adressen sind in CIDR-Notation angegeben. Beispielsweise bedeutet „10.0.0.0/24“ nicht „10.0.0.0 bis 10.0.0.24“. Erfahren Sie mehr zur CIDR-Notation.

Es folgt eine Liste der vollqualifizierten Domänennamen, die vom Gateway verwendet werden.

Domänennamen Ausgehende Ports Beschreibung
*.download.microsoft.com 80 Zum Herunterladen des Installationsprogramms wird HTTP verwendet.
*.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 an Service Bus Relay über TCP (erfordert 443 für Bezug des Access Control-Tokens)
*.frontend.clouddatahub.net 443 HTTPS
*.core.windows.net 443 HTTPS
login.microsoftonline.com 443 HTTPS
*. msftncsi.com 443 Wird zum Testen der Internetverbindung verwendet, wenn der Power BI-Dienst das Gateway nicht erreichen kann.
*.microsoftonline-p.com 443 Wird abhängig von der Konfiguration für die Authentifizierung verwendet.
Hinweis:

Datenverkehr von „visualstudio.com“ oder „visualstudioonline.com“ wird für Einblicke in die App benötigt und ist für die Funktion des Gateways nicht erforderlich.

Erzwingen der HTTPS-Kommunikation mit Azure Service Bus

Sie können erzwingen, dass das Gateway zur Kommunikation mit Azure Service Bus anstelle von TCP das HTTPS-Protokoll verwendet. Dies kann die Leistung beeinträchtigen. Ändern Sie zu diesem Zweck die Datei Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config, indem Sie den Wert von AutoDetect in Https ändern, wie im Codeausschnitt direkt nach diesem Abschnitt gezeigt. Diese Datei befindet sich (standardmäßig) unter C:\Programme\Lokales Datengateway.

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

Alternativ können Sie ab der Version von März 2017 mithilfe der Gateway-Benutzeroberfläche dieses Verhalten des Gateways erzwingen. Wählen Sie auf der Gateway-Benutzeroberfläche Netzwerk aus, und wählen Sie dann für Azure Service Bus connectivity mode (Azure Service Bus-Verbindungsmodus) die Option Ein aus.

Wenn Sie nach dem Durchführen der Änderung Übernehmen (eine Schaltfläche, die nur angezeigt wird, wenn Sie eine Änderung vornehmen) auswählen, wird der Windows-Dienst Gateway automatisch neu gestartet, damit die Änderung wirksam werden kann.

In ähnlichen Situationen in der Zukunft können Sie den Windows-Dienst Gateway über das Dialogfeld neu starten, indem Sie Diensteinstellungen und dann Jetzt neu starten auswählen.

Hohe Verfügbarkeit

Optionen für die hohe Verfügbarkeit befinden sich in der Roadmap für das Gateway. Warten Sie auf weitere Updates.

So starten Sie das Gateway neu

Das Gateway wird als Windows-Dienst ausgeführt. Sie können es wie jeden anderen Windows-Dienst starten und beenden. Es gibt mehrere Möglichkeiten, dies zu tun. In der Eingabeforderung müssen Sie daher wie folgt vorgehen:

  1. Starten Sie auf dem Computer, auf dem das Gateway ausgeführt wird, eine Administratoreingabeaufforderung.

  2. Verwenden Sie den folgenden Befehl zum Beenden des Diensts.

    net stop PBIEgwService

  3. Verwenden Sie den folgenden Befehl zum Starten des Diensts.

    net start PBIEgwService

Siehe auch

Lokales Datengateway – Problembehandlung
Azure Service Bus
Azure AD Connect
Weitere Fragen? Wenden Sie sich an die Power BI-Community