Power BI (PBI), previously on its own and now as part of Microsoft's Fabric offering, has grown in leaps and bounds and now dominates the Enterprise Business Intelligence (BI) market. Yet one enterprise capability area which requires improvement is tenant administration monitoring and auditing. This is especially true for smaller organisations who have not reached the scale warranting the significant investment needed for dedicated Fabric capacity and thereby more monitoring options. The PBI Centre of Excellence (CoE) teams in those smaller firms still need to have a clear view of the metadata (e.g. number of report, semantic models, user access assignments) and the usage and activity stats of the tenant they are responsible for.
The out of the box tenant monitoring options have major shortcomings and there isn't a sufficiently comprehensive and flexible tool as follows:
The "Admin monitoring" workspace is probably the most flexible and exhaustive option but as the documentation confirms it is primarily intended for Premium/Fabric capacities. It is read-only as well, so its flexibility is only as offered out of the box.
Report specific Usage metrics reports are as the name suggests only for the relevant report, i.e. they do not give a tenant-wide picture, and seem to never be up to date when you decide to see usage data for a given report.
"Usage Metrics" in the Admin portal is a very static view which provides very limited utility for those who would like to filter and drill down the inventory metadata and the usage stats.
So it seems almost inevitable that the typical Power BI CoE would need to build its own set of reports. This post deals with the first step on that journey, i.e. setting up the Service Principal authentication for an Azure Data Factory (ADF) REST API Linked Service. This in turn would enable building the requisite data pipelines to ingest the data for the Admin monitor, store it, and then present it for analysis.
There Is Amazing Advice Out There Already...
For those who want to connect to the Power BI Admin APIs and build their own set of tenant admin monitoring reports, the excellent PBI community as always has made a solid contribution to plugging the gap described above.
The critical step in building such an integration is the security configuration and in particular how the data preparation tool authenticates into the PBI Admin REST API.
In the Microsoft tech stack there are two common options - using a bearer token to authenticate from Power Query, or using a Service Principal to authenticate from ADF. The latter is undoubtedly a more strategic set up as it allows the use of Azure Key Vault to better protect the sensitive credentials data.
The following guides on authenticating into the PBI REST API are very useful, however, they do not make it clear what the correct authentication config is:
Building a Power BI Admin View [Part 2]: Obtaining a Refreshable Access Token (from 7:45 onwards) – This video is focused on automating the Power Query bearer token generation approach but it is not strategic in the way it requires a password to be hardcoded in the Power Query code. However, it does leverage a service principal/application where it configures the access via “Api Permissions”.
How to get Activity Data from Power BI Service with REST APIs – this article takes a strategic approach by using ADF instead of Power Query and configuring a REST API Linked Service to authenticate with a Service Principal/Application. It doesn’t, however, go in any detail as to how to configure the Service Principal before using it in ADF.
Keep it Simple... Review Any Relevant MS Guides.... and Test Them in Practice
From the above guidance it became clear that I needed to dig futher into the App Registration/Service Principal configuration with a focus on PBI Admin REST APIs.
That investigation led me to what seems to be the MS answer to the gaps in the articles above.
"Enable service principal authentication for read-only admin APIs" describes exactly the Service Principal authentication config for PBI Admin REST API. Crucially, it only mentions the need to add the Service Principal as a member of a Microsoft Entra ID Group which is also added to the Read-Only Admin APIs setting in the PBI Admin Portal (screen snippets below).
The question I was left with was if it was still necessary to follow the guidance from the YouTube video above, and assign specific API permissions. The best way was to test that in practice and the latter experiement with a simple REST API Linked Service in ADF confirmed that API permissions do NOT need to be added to the Service Principal, i.e. it is enough to add the Enterprise Application/Service Principal to the Security Group with assigned PBI API access in the PBI Admin Portal.
コメント