1. Einführung

Ich habe in den letzten Stunden intensiv damit gehadert, wie man Power BI-Berechtigungen in Microsoft Fabric sauber aufsetzt – sei es für den direkten Zugriff auf Workspaces oder für eingebettete Reports in eigenen Anwendungen. Dabei bin ich über Stolpersteine gestolpert, die selbst erfahrene Admins und Entwickler ins Strudeln bringen:

  • Unterschiedliche Fabric SKUs (F16 vs. F64) mit klar voneinander abweichenden Lizenzanforderungen
  • Die Frage, wann eine Free-Lizenz genügt und wann Pro oder Premium per User (PPU) unabdingbar sind
  • Abhängigkeiten zwischen User Owns Data und App Owns Data im Embedded-Szenario
  • Spezifika bei internen Nutzern versus externen B2B-Gästen – besonders mit oder ohne BYOL (Bring Your Own License)

Nach diesem Artikel weißt du genau, welche Lizenztypen (Free, Pro, PPU) für Power BI in Fabric – je nach Kapazität (F2–F32 vs. F64+) – erforderlich sind, wie du interne Anwender im Workspace korrekt berechtigst und wie du externe B2B-Gäste mit oder ohne Bring-Your-Own-License (BYOL) sauber einbindest. Du lernst die Unterschiede zwischen „User Owns Data“ und „App Owns Data“ bei embedded Reports kennen und erhältst praxisnahe Tipps für Azure Embedded A-SKUs, Premium P-SKUs sowie für Cross-Tenant-Trusts und RLS-Gruppen. So wirst du typische Stolpersteine vermeiden und deinen Nutzern ein reibungsloses Analyse-Erlebnis bieten.

1.1. A/P/F(RI)-SKUs – Verwirrung pur

Willkommen im Lizenzierungs-Albtraum „MS Fabric/Power BI“. Bevor wir ins Detail gehen, hier eine kurze Zusammenfassung: A-SKUs (Azure Power BI Embedded) dienen ausschließlich Embedded-Szenarien und erfordern für das Power BI-Service-Portal weiterhin Pro-/PPU-Lizenzen stackoverflow.com. P-SKUs (Power BI Premium Classic) konnten bis zum 1. Juli 2024 von neuen Kunden abgeschlossen werden, sind aber seither für Neukäufe eingestellt und werden nur von Bestands-EA-Kunden befristet bis Anfang 2025 weitergeführt powerbi.microsoft.commicrosoft.com. F-SKUs (Fabric Gen 2) bieten On-Demand-Abrechnung, flexible Skalierung und alle Fabric-Workloads, während Reserved Instances (RI) lediglich ein Rabattmodell für F-SKUs (bzw. P1≙F64) mit ein- oder dreijährigem Commitment sind microsoft.comlinkedin.com.

1.1.1. Fabric Gen2 (F-SKUs) und Reserved Instances (RI)

Fabric Gen2 nutzt F-SKUs (F2–F2048), die on-demand im Azure-Portal abgerechnet werden, minutengenau skalierbar sind und alle Fabric-Workloads unterstützen – von Data Engineering (Notebooks, Dataflows Gen2) über Warehouses bis hin zu Power BI-Reporting azure.microsoft.comlearn.microsoft.com.

  • Pay-as-you-go: F-SKUs werden ohne langfristige Bindung stunden- oder minutengenau abgerechnet. Sie können Kapazität jederzeit hoch- oder runterskalieren, pausieren und wieder aufnehmen learn.microsoft.com.
  • Reservierung (RI): RI sind kein eigener SKU-Typ, sondern ein Abrechnungsmodell für F-SKUs, bei dem Sie sich für ein- oder dreijährige Commitments auf bestimmte Capacity Units festlegen und bis zu ca. 40 % Rabatt auf die Compute-Kosten erhalten, während die technischen Parameter (v-Cores, RAM) identisch bleiben und Storage-/Netzwerkkosten weiter pay-as-you-go abgerechnet werden learn.microsoft.comazure.microsoft.com.
  • Einsatzfall: Ideal für Kunden, die maximale Flexibilität und Zugriff auf alle Gen2-Features (AutoScale, Multi-Geo, Persistent Cache) benötigen, ohne feste Mindestlaufzeiten learn.microsoft.com.

1.1.2. Power BI Premium Classic (P-SKUs)

P-SKUs (P1–P5) sind das legacy–Modell der Power BI Premium–Kapazität, das auf Jahreslizenz (EA/Volumenvertrag) basiert, dedizierte SLA, hohe Concurrency-Limits und Storage-Entitlements (bis 100 TB) bietet learn.microsoft.comlearn.microsoft.com.

1.1.3. Azure Power BI Embedded (A-SKUs)

A-SKUs (A1–A6) sind Azure Power BI Embedded–Kapazitäten, die speziell für das Einbetten von Reports und Dashboards in eigene Web- oder Mobile-Apps über die REST API entwickelt wurden learn.microsoft.comazure.microsoft.com.

  • Abrechnung & Betrieb: Stundenbasiert, pausierbar, keine Pro- oder PPU-Lizenzen für externe Embedded-User nötig.
  • Service-Portal: Kein Einfluss auf Konsumrechte im Power BI-Service; interne Nutzer, die innerhalb des Portals konsolidierte Reports ansehen, benötigen weiterhin Pro- oder PPU-Lizenzen learn.microsoft.comlearn.microsoft.com.

1.2 Power BI Dashboards vs. Embedded Reports

  • Workspace-Dashboards: Endnutzer melden sich im Power BI Service an (User Owns Data) und interagieren direkt in einem Fabric Workspace.
  • Embedded Reports: Ihr bettet Power BI-Visuals in eigene Web-Apps oder Portale ein (App Owns Data), oft über einen Service Principal oder ein Master-User-Konto.

1.3 Kapitelüberblick

In Kapitel 1 betrachten wir zunächst Power BI Dashboards in einem Workspace. Kapitel 2 widmet sich Embedded Power BI Dashboards – mit den Szenarien User Owns Data und App Owns Data. Danach folgen Best Practices, Checklisten und ein abschließendes Fazit.

1. Power BI Dashboards in einem Workspace

Power BI-Dashboards in einem Workspace sind interaktive Berichts- und Visualisierungsansichten, die direkt im Power BI-Service gehostet werden. Dabei melden sich Nutzer mit ihrem Azure AD-Konto im Workspace an (User Owns Data) und greifen je nach zugewiesener Rolle und Lizenz (Free, Pro, PPU) auf freigegebene Dashboards und Datenmodelle zu. Diese Architektur ermöglicht zentrales Berechtigungs- und Rollenmanagement sowie nahtlose Integration mit Row-Level Security und anderen Fabric-Diensten.

1.1 Interne Nutzer

1.1.1 Kapazitäten kleiner als F64 (F2–F32)

In Fabric-Kapazitäten unter F64 (z. B. F16) benötigt jeder Nutzer, der Berichte oder Dashboards ansehen will, eine Power BI Pro– oder PPU-Lizenz. Free-Lizenzen gewähren hier keinen Konsumzugriff (learn.microsoft.com, stoneridgesoftware.com).

  • Lizenzbedarf: Jede Person, die Berichte oder Dashboards konsumiert, benötigt eine Power BI Pro– oder PPU-Lizenz.
  • Free-Lizenzen bieten in diesen Kapazitäten keinen Zugriff.
SKU-BereichLizenz für Konsum
F2–F32Pro oder PPU

1.1.2 Kapazitäten F64 und größer (bzw. Power BI Premium P1+)

Workspaces auf F64 oder höheren SKUs bieten eine Power BI Premium P1+-Erfahrung. Hier können Nutzer mit einer kostenlosen Fabric-Lizenz und der Zuweisung der Viewer-Rolle berichte und Dashboards konsumieren, ohne Pro/PPU-Lizenz (learn.microsoft.com, omnidata.com).

  • Lizenzbedarf: Nutzer mit Free-Lizenz plus zugewiesener Viewer-Rolle können Berichte und Dashboards konsumieren – ohne Pro/PPU-Lizenz.
SKU-BereichLizenz für Konsum
≥ F64 (P1+)Free + Viewer-Rolle

1.1.3 PPU-Workspaces

In PPU-Workspaces gilt: Jeder Teilnehmer – auch reine Leser – braucht eine PPU-Lizenz, da Premium-Features in Shared Capacity nur so freigeschaltet werden (blog.pinja.com).

1.2 Externe Benutzer

1.2.1 Einrichtung externer Tenant-User

  1. Microsoft Entra B2B Einladung: Im Host-Tenant via Azure AD → External Identities → Cross-Tenant Access Settings Einladungen aktivieren und Gast-Email versenden (azure.microsoft.com).
  2. Redemption-Prozess: Der eingeladene Benutzer klickt auf den Registration-Link, authentifiziert sich bei seinem Home-Tenant und stimmt den Bedingungen zu. Danach wird ein AAD-Gastkonto im Host-Tenant mit UserType “Guest” angelegt (reddit.com).

1.2.2 Exkurs: Begriffserklärungen

  • Microsoft Entra B2B Einladung: Prozess, um externe Benutzer per E-Mail als Gäste einzuladen. Sie durchlaufen einen Redemption-Flow, um ein Gastkonto im Host-Tenant zu erstellen (azure.microsoft.com).
  • AAD-Gastkonten: Gastkonten (UserType “Guest”) haben standardmäßig eingeschränkte Berechtigungen und sehen nur ihre eigenen Verzeichnisobjekte, bis Rechte erweitert werden (azure.microsoft.com, linkedin.com).
  • Tenant: Abgeschlossene Azure AD-Instanz. Host-Tenant versendet Einladungen, Home-Tenant ist der Ursprung des Gäste-Accounts (azure.microsoft.com, blog.pinja.com).

1.2.3 Externe Nutzer mit BYOL (Bring Your Own License)

1.2.3.1 Einleitung

BYOL erlaubt externen Gästen, ihre Pro– oder PPU-Lizenz aus dem Home-Tenant mitzubringen, sofern der Trust korrekt konfiguriert ist. Damit entfällt die Zuweisung einer Lizenz im Host-Tenant (reddit.com, data-mozart.com).

1.2.3.2 Begriffserklärung BYOL

Bring Your Own License (BYOL) bedeutet, dass der Gast seine bestehende Lizenz im Home-Tenant nutzt, statt im Host-Tenant neu lizenziert zu werden (reddit.com).

1.2.3.3 Einrichtung der Cross-Tenant Access Settings

In Azure AD → External Identities → Cross-Tenant Access Settings konfigurieren:

  • Inbound Policies: Erlaube MFA- und Geräte-Claims vom Home-Tenant (azure.microsoft.com).
  • Outbound Policies: Gewähre Zugriff von Host- zu Home-Tenant ohne erneute Authentifizierung (azure.microsoft.com).
  • Cross-Cloud Settings: Beide Clouds (Commercial, Government) aktivieren, falls Multi-Cloud-Szenario besteht (azure.microsoft.com).
  • Cross-Tenant Sync: Automatische Synchronisation von Gast-Benutzer-Objekten und Token-Redemption aktivieren (azure.microsoft.com).
1.2.3.4 Keine Lizenz im Host-Tenant notwendig

Ist BYOL aktiv und der Cross-Tenant-Trust funktioniert, erkennt Power BI die Lizenz des Gastes per Token-Exchange aus dem Home-Tenant – eine Host-Tenant-Lizenz ist nicht erforderlich (reddit.com, data-mozart.com).
Ausnahme: BYOL wird in isolierten Azure-Cloud-Umgebungen wie Azure Government und Azure China nicht unterstützt; in diesen Regionen muss weiterhin eine Power BI Pro- oder PPU-Lizenz im Host-Tenant vorgehalten werden.

1.2.4 Externe Nutzer ohne BYOL

Wenn BYOL nicht möglich ist (z. B. bei isolierten Azure-Cloud-Umgebungen wie Azure Government oder Azure China), müssen externe Gäste unbedingt im Host-Tenant lizenziert werden – ihre Home-Tenant-Lizenzen werden in diesem Szenario nicht herangezogen. Es spielt dabei keine Rolle, ob die Gäste in ihrem Home-Tenant bereits eine Pro- oder PPU-Lizenz haben: ohne Host-Tenant-Lizenz erhalten sie keinen Zugriff.

  1. Power BI Pro oder PPU-Zuweisung im Host-Tenant: Weist dem Gastkonto im Azure AD eures Tenants eine Pro- oder PPU-Lizenz zu (Azure AD → Lizenzen → Zuordnen).
  2. Gruppenbasierte Lizenzierung: Verwendet dieselbe Security-Gruppe, die ihr für RLS/Direct Access einsetzt, als Zuweisungsgruppe für Pro/PPU-Lizenzen. Alle Gastmitglieder dieser Gruppe erhalten so automatisch die erforderliche Lizenz im Host-Tenant.

Home-Tenant-Lizenz nicht erforderlich: In diesem Modell genügt die Host-Tenant-Zuweisung, der Gast benötigt keine eigene Lizenz in seinem Home-Tenant. Es ist technisch möglich, dass ein Benutzer nur im Host-Tenant eine Pro/PPU-Lizenz hat und im Home-Tenant keine Power BI-Lizenz besitzt.

1.2.5 Gruppenmitgliedschaft & RLS

  1. Für Row-Level-Security (RLS) und Direct-Access im Workspace empfiehlt es sich:
  2. Eine Assigned Security-Gruppe in Azure AD anlegen (keine M365/Unified-Group) (linkedin.com).
  3. Externe Gäste als Mitglieder hinzufügen (bis zu 60 Minuten Replikationszeit) (linkedin.com).
  4. Dieselbe Gruppe im Semantic Model für RLS und im Power BI Workspace als Direct-Access-Gruppe konfigurieren.

2. Embedded Power BI Dashboards

2.1 Einleitung

Embedded Power BI Dashboards werden in eigene Apps oder Portale integriert – nicht im Power BI Service selbst. Hier unterscheidet man:

  • User Owns Data (Embed for Your Organization)
  • App Owns Data (Embed for Your Customers)

2.2 Beispiel für die Einbettung eines Reports

<div id="reportContainer"></div>
<script>
  // Backend liefert EMBED_TOKEN
  var models = window['powerbi-client'].models;
  var config = {
    type: 'report',
    tokenType: models.TokenType.Embed,
    accessToken: '<EMBED_TOKEN>',
    embedUrl: '<EMBED_URL>',
    id: '<REPORT_ID>',
  };
  powerbi.embed(document.getElementById('reportContainer'), config);
</script>

2.3 Lizenzierung im Embedded-Kontext

Das Thema Lizenzierung im Embedded-Bereich unterscheidet sich in Nuancen sowohl von der direkten Workspace-Nutzung als auch innerhalb der beiden Embedding-Modelle User Owns Data und App Owns Data. Im Folgenden erläutere ich ausführlich, welche Voraussetzungen gelten, welche Kostenfaktoren relevant sind und wie spezifische Azure-Kapazitäten (z. B. A-SKUs vs. P-SKUs) funktionieren.

2.3.1 User Owns Data

2.3.1.1 Einleitung

Beim User Owns Data-Ansatz meldet sich jeder Endnutzer in der eingebetteten Anwendung mit seinem eigenen Azure AD-Konto an. Die App übergibt sein Access-Token direkt an den Power BI-Service, und dieser prüft sowohl die Authentizität als auch seine RLS-Berechtigungen.

Innerhalb des User Owns Data-Szenarios unterscheidet sich der Lizenzbedarf je nach Art der Kapazität und dem Einsatz von dedizierten Embedded- oder Premium-SKUs:

2.3.1.2 Kapazitäten kleiner als F64 ohne dedizierte A-SKU (Shared Capacity)
  • Jeder Endnutzer benötigt eine Power BI Pro– oder Premium per User (PPU)-Lizenz, da Free-Lizenzen in Standard-Shared-Kapazitäten keinen Konsumzugriff erlauben. (wie direkter Service-Zugriff).
  • Die Authentifizierung und Lizenzprüfung erfolgt über das TokenType.Aad des angemeldeten Users.
2.3.1.3 F2–F32 mit dedizierter A-SKU (Azure Embedded)
  • A-SKUs (A1, A2, A3 …) sind stündlich abrechenbare Azure Embedded-Kapazitäten, die primär für App Owns Data-Szenarien entwickelt wurden. Sie bieten:
    • Unbegrenzte Konsumentenzahl: Endnutzer benötigen keine eigenen Pro-/PPU-Lizenzen, analog zum Leserzugriff in Premium-Umgebungen.
    • Flexible Abrechnung: Nutzungsabhängig pro Stunde, ideal für variable oder projektbezogene Lastspitzen.
    • Kern-Embedded-Funktionen: Optimiertes Rendering, Load-Balancing und einfache Skalierung.
  • Lizenzbedarf: Free + Viewer-Rolle reicht (wie direkter Service-Zugriff).
  • Eine A1-SKU (1 vCore) entspricht leistungstechnisch weitgehend der F32 Kapazität. A1 bietet beispielsweise 1 vCore und ist ideal für kleine bis mittlere Deployments (ca. 730 $/Monat bei Dauerbetrieb). Höhere A-SKUs erhöhen vCore-Anzahl und Speicher für rechenintensive Reports.
2.3.1.4 Lizenzbedarf bei ≥ F64 Kapazitäten
  • Workspaces die auf MS Fabric F64 und höher liegen, heben die Pro-/PPU-Pflicht analog zu A/P-SKUs für reine Konsumenten auf.
  • Eine F64 inkludiert somit die Premium P1-SKU.
  • Nutzer mit kostenfreier Fabric-Lizenz und zugewiesener Viewer-Rolle können Berichte und Dashboards ansehen, ohne eine Pro/PPU-Lizenz.
  • Diese Viewer-Rolle muss explizit im Power BI-Service zugewiesen werden und beschränkt Edit-Rechte.

2.3.2 App Owns Data

Im App Owns Data-Modell übernimmt deine Anwendung selbst die gesamte Authentifizierung und Autorisierung gegenüber Power BI. Anders als beim User Owns Data-Ansatz benötigt jeder Endnutzer kein eigenes Power BI-Konto oder eine individuelle Lizenz. Stattdessen ist eine zentrale Identität („Service Principal“) oder ein dedizierter „Master-User“ (Azure AD App Registration mit festgelegten Rollen) für den gesamten Zugriff verantwortlich.

2.3.2.1 Einleitung

Beim App Owns Data-Modell wird das komplette Reporting und Dashboarding über eine serverseitige Komponente gesteuert. Deine Anwendung meldet sich mit dem Service Principal (einer Azure AD-App) oder einem Master-User an und fordert über die Power BI REST API sogenannte Embed-Tokens an.

  • Service Principal vs. Master-User
    • Service Principal: Empfohlen für Produktionsumgebungen, da keine persönlichen Zugangsdaten verwendet werden und Berechtigungen granulär über Azure AD-Rollen vergeben werden können.
    • Master-User: Kombination aus persönlichem Benutzerkonto und globalen Administrator-Rollen; häufig als Übergangslösung eingesetzt, aber weniger sicher und weniger skalierbar.
  • Embed-Tokens
    • Jedes Token kodiert die erlaubten Aktionen (View, Explore, Edit) und den Geltungsbereich (Workspace, Dataset, Report).
    • Tokens haben standardmäßig eine Gültigkeitsdauer von bis zu einer Stunde, können aber auf Wunsch kürzer oder länger konfiguriert werden.
    • Über die REST API kannst du auch Tokens mit Row-Level Security (RLS) versehen, um feingranulare Datensicht zu gewährleisten.

Dadurch erhältst du volle Kontrolle über Sessions, kannst Benutzer-IDs nachverfolgen und Reports nahtlos in deine Web- oder Mobile-Apps integrieren, ohne dass Nutzer ein Power BI-Portal betreten müssen.

2.3.2.2 Kapazitäten kleiner als F64
  • Lizenzbedarf: Keine einzelnen Pro- oder PPU-Lizenzen für Endnutzer erforderlich.
  • Erforderliche SKU: Immer eine A- oder P-Kapazität (A1–A6, P1–P3), da der Nutzer selbst keine Power BI-Lizenz besitzt.
  • Warum A-SKU notwendig?
    • Im App Owns Data-Szenario entfallen Endnutzer-Lizenzen, doch die Infrastruktur muss über eine gemietete Kapazität abgedeckt werden.
    • A-SKUs (Azure-basiert) sind ideal für Entwicklung, Test und kleinere Produktionsumgebungen (A1–A3).
  • Begrenzungen
    • Concurrency: Kleinere SKUs erlauben weniger gleichzeitige Query-Threads. (Bsp.: A1 ≈ 100 Concurrency-Einheiten, A3 ≈ 300)
    • Speicher: Max. 25 GB pro Dataset bei A4/A5, anschließend kostenpflichtig erweiterbar.
  • Kostenüberblick
    • A-Kapazitäten starten ab ca. 1 USD pro Stunde (A1), P1 ab etwa 3.75 USD/Stunde.
2.3.2.3 Kapazitäten größer als F64
  • Lizenzbedarf: Ebenfalls keine Pro-/PPU-Lizenzen pro Endnutzer nötig.
  • Erforderliche SKU: Premium-Kapazitäten ab F64 (bzw. P4/P5 im klassischen Modell), da hier sämtliche Enterprise-Features (P1+) bereits enthalten sind.
  • Integrierter Leistungsumfang
    • Automatische Skalierung (AutoScale) und höhere Concurrency-Limits (bis zu 1.000 gleichzeitige Abfragen).
    • Erweiterte Speicherlimits (bis zu 400 GB pro Dataset) und dedizierte Hardware-Isolierung.
    • Zusätzliche Funktionen wie Advanced AI, Deployment Pipelines, Multi-Geo und Persistent MIDI Cache.
  • Vorteile für große Umgebungen
    • Höhere Stabilität unter Last durch Lastverteilung auf mehrere Nodes.
    • Bessere Latenz dank dedizierter Ressourcen und optimierter In-Memory-Engines.
    • Erweiterte SLA (bis zu 99,9 % Verfügbarkeit) im Vergleich zu A-SKUs.
  • Kosteneffizienz
    • Trotz höherer Grundkosten (F64 ≈ 32 v-Cores, entsprechende Preisstaffel ab ~6.445 USD/Monat) kann die Pro-Endnutzer-Kalkulation niedriger liegen, da keine individuellen Lizenzen nötig sind und die Kapazität auf beliebig viele Nutzer skaliert werden kann.
2.3.2.4 Technischer Ablauf
  1. Service Principal / Master-User: Ihr registriert eine Azure AD App (Service Principal) oder nutzt ein dediziertes Master-User-Konto mit den Power BI REST API-Berechtigungen (Report.Read.All, Dataset.Read.All).
  2. Azure AD Token: Eure Applikation holt sich serverseitig ein Azure AD Access-Token für die Power BI API.
  3. Embed-Token generieren: Mit dem Access-Token ruft ihr per REST API (GenerateToken) ein Embed-Token ab, das die spezifischen Zugriffsrechte und optional RLS-Informationen (CustomData oder EffectiveIdentity) enthält.
  4. Client-Einbettung: Das Embed-Token wird an den Browser-Client (z. B. JavaScript SDK) übergeben und ermöglicht das Rendern des Berichts innerhalb eurer App ohne weitere Authentifizierungsschritte für den Endnutzer.
  5. Dieses Modell ist ideal, wenn ihr Berichte für anonyme oder externe Zielgruppen bereitstellen wollt, bei denen ihr keine oder nur eingeschränkte Kontrolle über individuelle Lizenzzuweisungen habt. Durch den zentralen Token-Flow behaltet ihr alle Zugriffsrechte und Nutzungsmetriken in eurer Hand und könnt gleichzeitig Lizenzkosten für eure Nutzergruppe drastisch reduzieren.

Oben siehst du das offizielle Flussdiagramm aus der Microsoft-Dokumentation zur Embed-for-Your-Customers-Lösung:

  1. Der Web-App-User meldet sich in deiner Anwendung an.
  2. Deine Web-App authentifiziert sich per Service Principal oder Master-User beim Microsoft Entra ID (Azure AD) und erhält ein Entra-ID-Token.
  3. Mit diesem Token ruft deine App die Power BI REST-API auf (GenerateToken) und fordert ein Embed-Token an.
  4. Die API gibt das Embed-Token zurück.
  5. Deine Web-App leitet das Embed-Token an den Browser des Users weiter.
  6. Der Browser-Client (z. B. Power BI JavaScript SDK) verwendet das Embed-Token, um den Report zu rendern.
  7. Der Endnutzer sieht und interagiert mit dem eingebetteten Power BI-Content, ganz ohne eigene Pro-/PPU-Lizenz.

Dieses Diagramm deckt den typischen Embed-Token-Flow ab und lässt sich als Vorlage für eure Embedded-Implementierung übernehmen.

2.3.2.5 Service Principal vs. Master-User-Konto

In Embedded-Szenarien könnt ihr Embed-Tokens entweder über eine Service Principal (App Registration) oder ein Master-User-Konto (normales Azure AD-Benutzerkonto) generieren. Beide Methoden ermöglichen den Token-Flow, unterscheiden sich jedoch in Sicherheit, Wartbarkeit und Lizenzanforderungen:

2.3.2.5.1 Anlage und Konfiguration
  • Service Principal (App Registration)
    1. Azure Portal → Azure Active Directory → App Registrations → Neue Registrierung erstellen.
    2. Unter API Permissions die Power BI Service-Berechtigungen (Dataset.Read.All, Report.Read.All etc.) hinzufügen und Admin Consent erteilen.
    3. Unter Certificates & secrets ein Client Secret oder Zertifikat anlegen.
    4. Im Power BI Admin-Portal → Tenant Settings → Allow service principals to use read-only admin APIs aktivieren und gegebenenfalls Workspaces für den Service Principal freischalten.
  • Master-User-Konto
    1. Azure AD → Users → New user: Erstellt einen dedizierten User, z. B. powerbi-embed@yourtenant.onmicrosoft.com.
    2. Weist diesem Konto eine Power BI Pro oder PPU-Lizenz zu.
    3. Vergebt im Power BI-Service die benötigten Workspace-Rechte (Admin oder Member), damit das Konto Embed-Tokens erzeugen kann.
2.3.2.5.2 Unterschiede im Betrieb
AspektService PrincipalMaster-User-Konto
LizenzbedarfKeine Pro/PPU-Lizenz, da die Capacity (A-SKU) genügtPro/PPU-Lizenz nötig für Token-Erzeugung
SicherheitZertifikats- oder Secret-basierte AuthentifizierungPasswortbasiert, potenziell weniger sicher
RollenkonzeptFeingranular über App-Rollen und Azure AD PoliciesArbeitet wie ein normaler User mit festen Rechten
Wartbarkeit & RotationSecrets/Zertifikate leicht automatisiert rotierbarPasswortwechsel erfordert ggf. manuelle Token-Refreshs
Audit & ComplianceKlar tracebar als App-Identity in LogsMix aus User- und Service-Logging
2.3.2.5.3 Wann welches Modell?
  • Service Principal ist die empfohlene Option für produktive oder kundenorientierte Embedded-Umgebungen, da sie sicherer, automatisierbar und wartbar ist.
  • Master-User-Konto eignet sich für schnelle Prototypen oder Legacy-Szenarien, in denen keine App Registration möglich ist.

2.5 Praxistipps

  • Kostenoptimierung: Nutze Auto-scale für A-SKUs außerhalb der Geschäftszeiten.
  • RLS im App Owns Data: Übergib User-Informationen im Embed-Token (CustomData) für Security-Filters.
  • Multi-Tenant: Für ISVs eigene Workspaces und Capacities pro Kunde betreiben.

3. Best Practices & Tipps

  • Kapazität vs. Lizenz: Bei vielen Nutzern (≥50) ist ein Upgrade auf F64+ oft günstiger als Pro-/PPU-Käufe.
  • Automatisierte Lizenzvergabe: Gruppenbasierte Zuweisung in Azure AD nutzen.
  • Einstellungen überwachen: Regelmäßig External Collaboration & Cross-Tenant Access Policies prüfen.
  • Zugriffsmonitoring: Power BI Admin-Portal und Cross-Tenant Access Workbook verwenden.

4. Fazit

Ob direkter Workspace-Zugriff oder embedded Szenario – die richtige Kombination aus Fabric-SKU, Lizenzmodell und Tenant-Settings entscheidet über reibungslosen Zugriff. Interne Nutzer folgen klaren Pro/Free-Regeln je nach Kapazität, externe B2B-Gäste profitieren bei BYOL von Home-Tenant-Lizenzen. In allen Fällen sorgt eine sorgfältige Konfiguration von RLS, Gruppen und Cross-Tenant Policies dafür, dass ihr 401-Fehler vermeidet und euren Anwendern optimale Analyse-Erlebnisse bietet.

Related posts:

Default ThumbnailMS Fabric – Data Pipeline / Azure Data Factory Default ThumbnailDie Welt der Urheberrechte: CC, Copyleft und Proprietäre Lizenzen Default ThumbnailPower Automate & Azure Functions Default ThumbnailExcel & SSAS: Live-Verbindung und Import-Modus meistern