This blog post is related to one of the issues that I came across while working with Power BI REST API using Service principal (Certificate type) authentication. I had posted my question on Stackoverflow here and even raised a ticket with Microsoft. In the end, with the help of MS product team, I was finally able to unlock the issue so thought to share my findings. In this blog post series, I will cover end – to – end implementation of invoking Power BI REST API in Powershell script using Service principal authentication..
I was using Powershell and invoking Power BI REST API to update refresh schedule for a Power BI dataset. The issue I encountered was error code 403 i.e., Forbidden or perms issue. The main reason for this issue was that Service principal was not the dataset owner. It was having admin access on the dataset but not the dataset owner while running the script. This means the dataset needs to be taken over by the Service Principal account before invoking any other REST API calls. But hang-on the story does not ends here, after solving that 403-error code issue I encountered error code 400 with little to no information on the Fiddler. After some research and digging, I found out that the second error code was related to the Service principal. I thought I will put together steps required for successful working of Powershell with Power BI REST API using Service Principal. As there are multiple steps, I will be dividing it into three categories: Service principal settings, Power BI web portal settings and Sample Powershell script invoking Power BI REST API.
Service Principal settings
1. Service Principal can be created by following steps mentioned in Microsoft documentation here. Once the Service principal is created, then you will need to configure the permissions. Click “API permissions” under “Manage” section, then click “Add a permission”. A window will pop-up with different API options to set-up. Select “Power BI Service” as we will be using Power BI REST APIs.
2. Select “Application permissions” and check “Tenant.Read.All” (will be required if using “GET” method APIs) and “Tenant.ReadWrite.All” (will be required if using “GET”, “POST”,”PATCH” and “DELETE” methods APIs).
3. The last step is to grant admin consent to activate the permissions.
That’s it for Service principal settings but stay tuned for more. In the next blog post, we will see Power Bi web portal settings for using Service principal.
Keep up the good work!
Pingback: Power BI REST API using Service Principal – Part 2 – DataUnlock
Pingback: How to implement Source control and CI/ CD for Power BI? – DataUnlock
Thanks for posting this. I am in the same situation as you once were but still getting 403.
I’m connecting to the PS module with my service principal, then creating a new workspace in PS script which works fine. I then use the Invoke API cmdlet to take over the data set which I get a 200 response from.
Yet when I try anything else like UpdateParams or even a GET request to view the dataset I get 403? I have the Application API permission as the post describes as well. Any ideas? This process seems so flakey!
That sounds a little odd. I agree the process is too convoluted when using Service Principal. Please check the following settings
– Service Principal is an admin of Workspace. (I believe you are creating Workspace using Service principal and same Service Principal is used for setting dataset)
– Service Principal is the dataset owner (i.e. using Takeover dataset)
– Service Principal has access to the data source. If you are using Gateway then the Service Principal should be added to users of the data source. There is another blog post by me for this one.
– In Power BI admin settings (Admin portal > Tenant Settings > Developer Settings) you have enabled “Allow service principals to use Power BI APIs”
Thanks for your blog, nice to read. Do not stop.